I’m just starting out porting some code I have developed for controlling a robot into FreeRTOS. We got away with a fair amount of complexity with ground-up coding, but it’s at the level now where a real RTOS will help manage current and future system complexity. And it’s a good learning exercise. This is all for an academic research application, too.
I’m a little uncertain what to do about interrupts that “need” to stay in the code, like for example, the _DMA0Interrupt that is being used to copy values from DMA RAM to some named variables, to be accessed by other code with getter function. This is done to have high-speed ADC sampling (triggered automatically by the PWM hardware generator), and thus give a zeroth-order-hold of the sampled sources to other code modules.
The current interrupt code is simple: http://pastebin.com/8n9sH1gR
So, the code doesn’t call any FreeRTOS functions, so nothing will be blocking waiting on the result of this function. If I understand correctly, this means that it can not cause a context switch?
What I’m not sure of it, do I have to worry about other hardware interrupts potentially firing during this interrupt? A higher priority interrupt, like the radio pin interrupt, might fire at any time and cause a complex task that would involved OS API functions and task blocking/unblocking to happen.
Similarly, will the existence on non-API-using hardware interrupts like this have a bearing on how I will need to design the ISR’s that do use API functions, and their dependent tasks?
Any input on this topic would be greatly appreciated.