travfrog wrote on Tuesday, 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