Round-Robin vs Function-Queue-Scheduling | Embedded Software Architecture

Bus_Queue

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

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

Return to Table of Contents

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

Return to Table of Contents

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)

Return to Table of Contents