Table of Contents
In this post, I will discuss the tradeoffs of using the Round Robin, Round Robin with Interrupts, and Function Queue Scheduling approaches when building an embedded system. Let’s consider that we will use an Arduino to perform tasks such as capturing sensor data and downloading to a host machine (e.g. your personal laptop computer).
Round Robin
Definition
The Round Robin architecture is the easiest architecture for embedded systems. The main method consists of a loop that runs again and again, checking each of the I/O devices at each turn in order to see if they need service. No fancy interrupts, no fear of shared data…just a plain single execution thread that gets executed again and again.
Pros
- Simplest of all the architectures
- No interrupts
- No shared data
- No latency concerns
- No tight response requirements
Cons
- A sensor connected to the Arduino that urgently needs service must wait its turn.
- Fragile. Only as strong as the weakest link. If a sensor breaks or something else breaks, everything breaks.
- Response time has low stability in the event of changes to the code
Round Robin with Interrupts
Definition
This Round Robin with Interrupts architecture is similar to the Round Robin architecture, except it has interrupts. When an interrupt is triggered, the main program is put on hold and control shifts to the interrupt service routine. Code that is inside the interrupt service routines has a higher priority than the task code.
Pros
- Greater control over the priority levels
- Flexible
- Fast response time to I/O signals
- Great for managing sensors that need to be read at prespecified time intervals
Cons
- Shared data
- All interrupts could fire off concurrently
Function Queue Scheduling
Definition
In the Function Queue Scheduling architecture, interrupt routines add function pointers to a queue of function pointers. The main program calls the function pointers one at a time based on their priority in the queue.
Pros
- Great control over priority
- Reduces the worst-case response for the high-priority task code
- Response time has good stability in the event of changes to the code
Cons
- Shared data
- Low priority tasks might never execute (a.k.a. starving)