How should fromISR be used?
Posted by Ozzy Smith
on November 27, 2012
After getting my IRQ_Handler working with Timer Interrupt and the OS running correctly, I need to add checks for the other system Interrupt sources, like buttons, I/O, DMA, etc.
Can I call another Handler routine that will do these functions from the IRQ handler using C function calls, or must I use "fromISR" calls to do this.
I get a an interrupt for a button press, and that event requires an action of some type. Do I perform that action within the context of the IRQ or do I wait to return from the IRQ to begin that action? Do I send a message to that task to signal to it that an action needs to take place?
What is the best method?
RE: How should fromISR be used?
Posted by Richard
on November 27, 2012
I am working on a similar design including DMA and buttons etc. I prefer to post messages from the ISR using FromISR and then handle that in task space. The interrupt handlers are virtually empty.
You really want to spend minimal time in interrupt space as the longer you spend the larger the potential latency in processing other interrupts.
The only time you would normally perform processing in ISR context is when you have very low latency processing requirements. Something like a button press is relatively slow and can easily be done in task space - it won't matter if it takes 100usec to get processed or 5msec - the user won't see it. Something like reloading a PCM output register while streaming audio may have a much tighter latency requirement, in which case do the absolute minimum and get out.
If you want to immediately process the results of an interrupt (if your RTOS tick rate is slow compared to your interrupt rate then you don't want to wait for the next RTOS tick otherwise you stand to add an additional whole RTOS tick delay in interrupt latency), you can post the message to the front of the Q (xQueueSendToFrontFromISR) and use the portEND_SWITCHING_ISR (TRUE) macro (or whatever your port uses).
Doing it this way has many advantages (such as message serialization and avoiding data corruption) and it also has the advantage of being able to simulate messages to your tasks without actually having the hardware in place.
Hope that helps
Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd..
See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.