Best task schedule strategies in embedded applications - c

Question

I am trying to find a better way to organize sub-tasks for embedded applications. I am more interested in Power Electronics applications. I am not a software engineer, but a Power Electronics Engineer. However, in most cases I need to develop the code.
In those applications, the main will stay in a infinite loop, and the control algorithm will run in a ISR (Interrupt Service Routine). However, in some applications extra low-priority sub-tasks are necessary (e.g. communication, alarm handling). Those sub-tasks cannot run in the ISR routine due to time limitation (the control algorithm has the higher priority). I would like to know the best ways to handle task schedule for embedded applications.
One simple way, in code snippet below, is just put all the sub-tasks inside the infinite loop (if all have the same priority). The application will run the ISR routine periodically (each switching period, for example) and use the left time to run the subtasks in a Round Robin approach. However, in this method all the subtasks will run in a unknown period. Consequently I will not be able to add timer routines (increment and check) inside those tasks. Also, if the software stays trapped (due to some bad code) in a low-priority task, the other tasks will not be executed (or the watchdog timer will be activated).
void main(void)
{
Init();
for(;;) /* There is a ISR routine with the control Algorithm*/
{
SubTask1();
SubTask2();
SubTask3();
}
}
It is possible to use other ISR routines (controlled for timer modules, for example) and control the interrupt priority to run one specific task. However, this method will demand a more careful study of the device, in order to set all the interrupt priorities correctly.
Do you know a better method? What schedule tasking methods are the most efficient for embedded applications?

Answer 1

The question hits on some general principals in embedded software.
1) Limit what you do in ISRs to the bare minimum
2) Coordinate different activities by using an RTOS
3) Improve performance by designing the software as event driven
The way to efficiently implement the sub-tasks is to move them from a polled loop to being event driven. If they are an alarm condition you want to check for periodically, use your RTOS to call that code from a timer. For communications, have that code do a blocking wait for an event, like the arrival of a message. Event driven code is much more efficient because it doesn't have to spin through all the polling looking for the events to handle.
The tools of an event driven design (threads, timers, blocking, etc) are provided by an RTOS, point 3) leads to point 2). An RTOS also solves your issues with the sub-tasks running at unknown times and for unknown durations, if there are remaining tasks that are not event driven.
Finally, there are a variety of reasons to limit how much you do in an ISR. It's harder to debug ISR code. It's harder to synchronize what the ISR does with the rest to the tasks. The alternative is to doing the same thing as a high priority task that waits for an event from the ISR.
But the biggest reason is future flexibility. Running the control algorithm in the ISR makes it hard to add another high priority task. Or maybe there will be a new requirement for the control algorithm to report status or write to a disk. Moving the code out of the ISR give you more options.