The thread subject says it all. If there is a function that may get called both by user-code, and also from within an interrupt, is there any way to detect whether it's been called from the interrupt or not?
I don't know, but if you need a function to do something that doesn't have to be synchronous, you could have a server process and make the function signal it to do the task in question...
I don't know, but if you need a function to do something that doesn't have to be synchronous, you could have a server process and make the function signal it to do the task in question...
What you're describing is just basic interrupt handling.
I have some code that might be called by a reset handler, and it's not practical to create a separate version for that purpose. Multitasking/interrupts are disabled during the reset handler. A simple method of detecting when this is the case from within the function would be helpful; otherwise I could always create a global flag that could be flicked on and off (yuck) to indicate what mode it's in.
Come to think of it, I assumed that a reset handler is called from within an interrupt, but this may or may not be true.
It's been long enough since I've seen Amiga nterrupt code t forget things exactly, I've been doing some ARM stuff at work to have some thoughts that may or may not work. You mentioned that interrupts are disabled in the reset handler.
In an interrupt handler, I'd think you'd be looking somewhere to see which of a possible set of events triggered an interrupt, to determine exactly what the handler needs to do each time in. For ARM, we use the AIC peripheral to enable/disable interrupts for each other peripheral block (usart, spi, usb controller, etc). Could you check that the Radeon interrupt in Amiga's interrupt controller is enabled or disabled, and if disabled then assume the reset brought us here, if enabled then interrupt brought us here? That'd use the interrupt controller itself as your global flag, though you'd want some assurance that an interrupt event would always look on and a reset event would always look off for that.
This would check the whole system interrupt controller status for Radeon interrupt enable, not checking inside the Radeon's own interrupt status values for which particular Radeon event triggered a Radeon interrupt.