Part 1: Cooperative Multitasking

Small microcontrollers are often required to handle several tasks, sometimes with overlapping phases. This paper will lead you through the creation of a small operating system which can be implemented on a tiny microcontroller, without the fancy time-slicing that is offered by sophisticated operating systems like Linux and FreeRTos.

The core of this technique is covered in Part 1 of this paper. If you just want to see how it all comes together, jump to Final Implementation.

Part 2 contains enhancements and variations, probably useful reading if you decide to adopt this programming technique in your projects.

Intro

Abstract

This paper will take you through the creation of a tiny operating system that can be implemented on a small microcontroller.

Audience

These techniques can be applied by anyone with experience in C, Python, Rust or any modern computer language. It helps to have a passing knowledge of how to connect a transducer (button, LED, buzzer, etc) to a microcontroller.

The Reality Check dropdowns in this article provide extra, often practical supplementary reading.

The Problem

Let’s suppose we want to flash an LED at 1 flash/2 sec, and independently, respond to a push button by operating a different LED for 1.5 seconds. Both operations must operate separately. How do we structure the code for the microcontroller to make this happen?

First Page

Let’s look at the pseudocode overview of what we want to do:

void initialize(void) {
  setup_hardware();
  setup_interrupts();
}

INTERRUPT void irq(void) {
  create_event();
  acknowledge_interrupt();
}

void main(void) {
  initialize();

  while (1) {
    if (event) {
      flashLedTask(event);
      respondToButtonTask(event);
    }
  }
}

That’s about it.

Of course, we will need to write the code for setup_hardware() and setup_interrupts(). And flashLedTask() and respondToButtonTask(). And create the magic that allows event information to flow. All this will be laid out in the following pages.

If you’re concerned with complexity, feel free to jump ahead about 10 pages to the final implementation page to see real, tested, code.

Between here and there, I’ll walk you step-by-step through building the structure and implementation.

This paper continues after that though, to show you how to expand upon a build as the project-definition changes. There are also several examples of state machines, and some discussion of practical matters, refactoring and project structure.

Interrupts

In order to have a responsive system, it would make sense to use the interrupt capabilities of these small micrcontrollers.

In the task described, we need to respond to a button press. So let’s connect the button to an input pin and enable it to respond to a button press with interrupt code.

We also need to keep track of time…..so let’s hook up a system timer to another interrupt.

Each interrupt causes the execution of interrupt handler code. For this project, it might look something like this:

enum {EVT_NONE=0, EVT_TICK, EVT_BUTTON};

INTERRUPT timer_isr(void) {
  newEvent(EVT_TICK);
}

INTERRUPT button_isr(void) {
  newEvent(EVT_BUTTON);  // see notes about button bounce and acknowledgement
}

The interrupt handlers are both very simple. They just create a unique event and let the system know about it. Next, let’s talk about events.

Events

An event in this context is a small bit of information that appears asynchronously in the system. Implemented, it can be a byte, or an int or an even larger structure. But in these small microcontrollers, let’s use a byte.

volatile uchar event;

These events will be created in interrupt level of the code, and processed at the main level. We use the event object to send information between these levels, so we have to mark it volatile.

In this paper, the words event and message are equivalent. Event has the sense of “something external just happened” and message has the sense of “a bit of communication from another part of the program” At this point in the design, they both mean the same thing.

By convention, let’s use zero to indicate the absence of an event/message, and non-zero to represent an event/message.

volatile uchar event;
enum {EVT_NONE=0, EVT_TICK, EVT_BUTTON}; // 0,1,2

So now we start to get an idea of what kind of information the interrupt handler code generates. Now let’s look at how that information gets sent to the rest of the code: newEvent().

newEvent()

Here’s a block diagram of the message flow

How do we send the information (events/messages) from the interrupt service routine to the main() code? We used shared memory.

One way would be to have a global volatile uchar location into which we drop the event information. But having only one socket for that would be a bit naive; what happens if a timer tick and a button press happen very close in time? What happens if the timer tick events start to stack up?

It makes more sense to have an array: volatile uchar events[NUM_EVENTS] where NUM_EVENTS is on the order of 5..10. That would give us 50-100msec to catch up in case there’s a pileup of events/messages.

At the beginning, before anything happens, we need to make sure the events[] is full of zeros (EVT_NONE), indicating that it’s empty.

The newEvent(evt) routine simply adds the evt to the array events[].

Something like this might work:

void newEvent(uchar evt) {
  static uchar nextEvent;
  events[nextEvent++] = evt;
  if (nextEvent == NUM_EVENTS)
    nextEvent = 0;
}

void newEvent(char evt) {
  static uchar nextEvent;           // keep track of where we are in queue
  disable_irq();                    // critical section
  events[nextEvent++] = evt;        // insert event into queue
  if (nextEvent == NUM_EVENTS)      // loop back to the start of queue
    nextEvent = 0;
  enable_irq();                     // end critical section, probably <100us of blockage
}

In the next section, we’ll show how the main() code pulls the events out of the array, and leaves an EVT_NONE in its place.

Dispatch

The main() code can simply watch the events[] to see when an entry goes non-zero (!=EVT_NONE). When that happens, main() will pull out the event/message from the array, and call the task subroutines. In this case, flashLedTask() and respondToButtonTask().

To see the real code for the dispatcher, jump ahead.

Tasks

In this environment, the code that implements a task is simply a subroutine that accepts an event/message.

void taskCode(uchar event) {
  ... process the event information ...
}

The subroutine should be designed to flow-through as quickly as possible, without any pauses/waits/delays.

If the problem that you’re trying to solve involves the passage of time, or any delay, then you must break down the actions into individual items, and build a state machine.

State Machine

A state machine in this environment is a subroutine which can be called many times, and it remembers in which state it was left from the previous call. Some invocations of this subroutine may cause it to change state, which can be represented in a net diagram.

Here’s a state diagram for the task which reacts to a button press by flashing an LED.

How does the state code remember what state it’s in between invocations? We can use a static variable. A static is stored in main memory (not on the stack), persists between calls and is initialized to zero.

The above diagram can be implemented in this code:

enum {RTB_IDLE, RTB_ON};          // RTB_IDLE=0, RTB_ON=1
static uchar  rtbState      = RTB_IDLE;
static uint16 rtbTimerCount = 0;
const  uint16 TIMER_LIMIT   = 150;

void respondToButtonTask(uchar evt) {
  switch(rtbState) {
    case RTB_IDLE:
      if (evt == EVT_BUTTON) {
        rtbState = RTB_ON;
        rtbTimerCount = TIMER_LIMIT;
        gpio_set(LED, ON);
      }
      break;
    case RTB_ON:
      if (evt == EVT_TICK) {
        if (--rtbTimerCount == 0) {
          gpio_set(LED, OFF);
          rtbState = RTB_IDLE;
        }
      }
      break;
    }
}

Each time this routine is called, it first forks, depending on the current state. Then it checks the event that it was given, and sometimes processes it. And sometimes it changes state.

Here’s a few things to notice:

• The code flows through. It does not stop or wait for anything.
• Each arrow in the net diagram corresponds to a phrase in the code. The tail of the arrow corresponds to an if statement
• The code ignores events that are not relevant.

Another State Machine

The other task of this project simply flashes the LED on and off.

The code for this might be:

enum {LED_ON, LED_OFF};
static uchar ledState       = LED_OFF;
static uint16 ledTimerCount = 0;
const  uint16 LED_ON_TIME   = 100;
const  uint16 LED_OFF_TIME  = 100;

void ledTask(uchar evt) {
  switch(ledState) {
    case LED_OFF:
      if (evt == EVT_TICK) {
        if (--ledTimerCount == 0) {
          gpio_set(LED, ON);
          ledTimerCount = LED_ON_TIME;
          ledState = LED_ON;
        }
      }
      break;
    case LED_ON:
      if (evt == EVT_TICK) {
        if (--ledTimerCount == 0) {
          gpio_set(LED, OFF);
          ledTimerCount = LED_OFF_TIME;
          ledState = LED_OFF;
        }
      }
      break;
    }
}

Discussion

Perhaps a more accurate state diagram might be:

As you build the code from the diagram, I strongly suggest that you use a switch(currentState) ....case STATE_1 approach to the task routine. If you try and code it with multiple if(currentState==STATE_1), you will find yourself in a tangle of spaghetti; and if you forget a critical else, nothing will work as you expect.

if (state==1) {
  if (event = EVT_1) {
    P3OUT = 27; // turn on some hardware
    state = 2;  // and change state
  }
} 
if (state==2) { // <<<----- BAD BAD
  P3OUT = 14;
  state = 3;    // <<<--- dont' change state twice in the same event
}
...

rather

switch(state) {
  case 1:
    if (event = EVT_1) {
      P3OUT = 27;   // turn on some hardware
      state = 2;
    }
    break;
  case 2:
    P3OUT = 14;
    state = 3;
  }
  ...
}

As a general rule, try to avoid changing states more than once per event; this kind of discipline will help with debugging a complex project.

Dispatcher Details

The last piece of the puzzle is the main() code which observes the events[] array and calls the tasks.

The events[] array is designed so that a 0 means ‘no event’, and the non-zero events are dropped into the array in order…so pulling them out is pretty straight forward.

void main() {
  initialize();

  while(1) {
    int i;
    for (i=0; i<NUM_EVENTS; i++) {
      while (events[i]==EVT_NONE)
        {}
      ledTask(events[i]);
      respondToButtonTask(events[i]);
      events[i] = EVT_NONE;
    }
  }
}

Each non-zero event is “sent” to each task…..by means of a subroutine call. Once all the tasks have been invoked, the event is thrown away and its slot in the array is set to zero.

Final Implementation

Let’s put all of the above together, for an SMT32F Cortex M0, in C code.

/***** declarations ****/
#define NUM_EVENTS 10
volatile uchar events[NUM_EVENTS];

void newEvent(uchar e);
void ledTask(uchar evt);
void respondToButtonTask(uchar evt);

/********** interrupts **************/

void timer_isr(void) {
  newEvent(EVT_TICK);
  // this interrupt is auto-ack'd
}

void button_isr(void) {
  newEvent(EVT_BUTTON);
  EXTI->PR |= KEY_IRQ_ACK_MASK;    // the hardware requires that we acknowledge 
}

/** newEvent
 * add the event to the event queue
 * wrapped in critical section
 * 
 * @param the event
 */
void newEvent(uchar e) {
  static uchar nextEvent;
  dint(); // critical section
  events[nextEvent++] = e;
  if (nextEvent==NUM_EVENTS)
    nextEvent = 0;
  eint();
}

/****** main() and dispatcher *********/
void main(void) {

  eint();

  // dispatcher loop
  while(1) {
    int j;
    for (j=0; j<NUM_EVENTS; j++) {
       while (events[j]==EVT_NONE)
         {}
       ledTask(events[j]);
       respondToButtonTask(events[j]);
       events[j] = EVT_NONE;
    }
  }
}

/*********** task code, with states ************/
enum {LED_ON, LED_OFF};
enum {RTB_IDLE, RTB_ON};    // states
static uchar  rtbState      = RTB_IDLE;
static uint16 rtbTimerCount = 0;
const  uint16 LED_ON_TIME   = 150;

void respondToButtonTask(uchar evt) {
  switch(rtbState) {
    case RTB_IDLE:
      if (evt == EVT_BUTTON) {
        rtbTimerCount = 0;
        rtbState      = RTB_ON;
        gpio_set(LED, LED_ON);
      }
      break;
    case RTB_ON:
      if (evt == EVT_TICK) {
        if (++rtbTimerCount > LED_ON_TIME) {
          gpio_set(LED, LED_OFF);
          rtbState = RTB_IDLE;
        }
      }
      break;
    }
}

const  uint16 LED_ON_TIME   = 150;
const  uint16 LED_OFF_TIME  = 50;
static uchar ledState       = LED_OFF;
static uint16 ledTimerCount = 0;

void ledTask(uchar evt) {
  switch(ledState) {
    case LED_OFF:
      if (evt == EVT_TICK) {
        if (++ledTimerCount > LED_OFF_TIME) {
          gpio_set(LED2, LED_ON);
          ledTimerCount = 0;
          ledState      = LED_ON;
        }
      }
      break;
    case LED_ON:
      if (evt == EVT_TICK) {
        if (++ledTimerCount > LED_ON_TIME) {
          gpio_set(LED2, LED_OFF);
          ledTimerCount = 0;
          ledState      = LED_OFF;
        }
      }
      break;
    }
}

This is the end of the main presentation. With the above techniques, you can make a tiny microprocessor appear to multitask.

For further tips, read the next section. The interesting topics are:

• more state code examples
  • with implementation
• how to initialize a state machine
• inter-task communication
• unified timers

Part 2

Variations

Now that the infrastructure is in place, it’s easy to expand or modify the code for changes in the project definition.

For example, suppose we want the respondToButtonTask() to restart the LED timer on each key press:

void rtbTask(uchar event) {
  switch(rtbState) {
    case RTB_IDLE:
      if (event == EVT_BUTTON) {
        gpio_set(LED, LED_ON);
        rtbState = RTB_ON;
        rtbTimer = RTB_TIMEOUT;
      }
      break;
    case RTB_ON:
      if (event == EVT_BUTTON) { 
        rtbTimer = RTB_TIMEOUT;
      }
      if (event == EVT_TICK) {
        if (--rtbTimer == 0) {
          gpio_set(LED, LED_OFF);
          rtbState = RTB_IDLE;
        }
      }
      break;
  }
}

Or have a 2nd press of the button cause the LED to extinguish early:

void rtbTask(uchar event) {
  switch(rtbState) {
    case RTB_IDLE:
      if (event == EVT_BUTTON) {
        gpio_set(LED, LED_ON);
        rtbState = RTB_ON;
        rtbTimer = RTB_TIMEOUT;
      }
      break;
    case RTB_ON:
      if (event == EVT_BUTTON) { 
        gpio_set(LED, LED_OFF);
        rtbState = RTB_IDLE;
      }
      if (event == EVT_TICK) {
        if (--rtbTimer == 0) {
          gpio_set(LED, LED_OFF);
          rtbState = RTB_IDLE;
        }
      }
      break;
  }
}

How about have the button start a flash sequence, and a 2nd press stops it: (see also substates)

void rtbTask(uchar event) {
  switch(rtbState) {
    case RTB_IDLE:
      if (event == EVT_BUTTON) {
        gpio_set(LED, LED_ON);
        rtbState = RTB_ON;
        rtbTimer = RTB_TIMEOUT;
      }
      break;
    case RTB_ON:
      if (event == EVT_BUTTON) { 
        gpio_set(LED, LED_OFF);
        rtbState = RTB_IDLE;
      }
      if (event == EVT_TICK) {
        if (--rtbTimer == 0) {
          gpio_set(LED, LED_OFF);
          rtbTimer = RTB_FLASH_TIME;
          rtbState = RTB_OFF;
        }
      }
      break;
    case RTB_OFF:
      if (event == EVT_BUTTON) { 
        gpio_set(LED, LED_OFF);
        rtbState = RTB_IDLE;
      }
      if (event == EVT_TICK) {
        if (--rtbTimer == 0) {
          gpio_set(LED, LED_ON);
          rtbTimer = RTB_FLASH_TIME;
          rtbState = RTB_ON;
        }
      }
      break;
  }
}

Each of these diagrams corresponds to trivial changes in the state code.

Working with Arduino

If you’re from the Arduino world, you have no doubt seen the similarity between this OS plan and the Arduino infrastructure.

setup() 
  {}    // initialize and start up the devices and services

loop()
  {}    // code for continuous operation

You can certainly merge this paper’s operating system into the Arduino architecture:

char events[];

interrupt_service_routines() {
  newEvent(evt); // insert events/messages into events[]
}   

static int nextEvent;
void newEvent(char evt) 
  {} // same as above; put evt into the events[]

setup()
  {}

loop() {
  static int nextTaskEvent;
  if (events[nextTaskEvent]!=EVT_NONE) {        // check for non-zero events[],
    task1(events[nextTaskEvent]);     // and call the task routines
    task2(events[nextTaskEvent]);
    events[nextTaskEvent) = EVT_NONE; // free the slot, fill with 0
    if (++nextTaskEvent > NUM_EVENTS)
      nextTaskEvent = 0;              // and loop through the array
  }
}  

void task1(char evt) {}
void task2(char evt) {}
    

Tasks

The fundamental guideline for tasks is that they do not stop. Control flows through and out the bottom, returning to the dispatcher quickly.

State Machine Examples

Car Window

Suppose we want to control the power window on a car? For this problem, we have an up/down button, a motor to drive the window up or down, and a motor-overload sensor to detect when the motor is straining. So the buttons & overload sensor are inputs, and the motor drive is outputs.

When the user presses the “up” button, we should start the motor moving upward. When the overload sensor detects a strain, then either the window is all the way up….or it has encountered a finger or hand; in either case, we need to turn the motor drive off.

Here’s a possible state diagram.

And here’s the matching code. Note the correspondence between the diagram and the code: arrows leaving a state correspond to an if() phrase.

enum {WINDOW_IDLE, WINDOW_UP, WINDOW_DOWN};
static uchar windowState = WINDOW_IDLE;

void windowTask(uchar evt) {
  switch(windowState) {
    case WINDOW_IDLE:
      if (evt == EVT_BUTTON_UP) {
        gpio_set(MOTOR, UP);
        windowState = WINDOW_UP;
      }
      if (evt == EVT_BUTTON_DOWN) {
        gpio_set(MOTOR, DOWN);
        windowState = WINDOW_DOWN;
      }
      break;
    case WINDOW_UP:
      if (evt == EVT_MOTOR_SENSE || 
          evt == EVT_BUTTON_RELEASE) {
        gpio_set(MOTOR, OFF);
        windowState = WINDOW_IDLE;
      }
      break;
    case WINDOW_DOWN:
      if (evt == EVT_MOTOR_SENSE || 
          evt == EVT_BUTTON_RELEASE) {
        gpio_set(MOTOR, OFF);
        windowState = WINDOW_IDLE;
      }
  }
}

Now, suppose the problem definition is changed: if the user presses the “up” button, the motor should only operate while the button is pressed; stop on release. But if the user presses the “up” button a second time within 1 second of the first release, the motor should drive the window all the way up (auto-close).

Here is a possible state diagram. Notice the significant re-use of code from the previous version.

void main(void) {
  eint();
  while(1) {
    for (i=0; i<NUM_EVENTS; i++) {
      while (events[i]==EVT_NONE)
        {}
      taskWindow(events[i],0);
      taskWindow(events[i],1);
      // ...
      taskWindow(events[i],NUM_WINDOWS-1);
      events[i] = EVT_NONE;
    }
  }
}

// window management task
int windowState[NUM_WINDOWS];
void taskWindow(char event, int windowIndex) {
  // find the state from the windowState[windowIndex] 
  // run through the state machine
  // any I/O will require an array of I/O addresses, use 'windowIndex'

  switch(windowState[windowIndex]) {
    case WS_IDLE:
      ...
      ...
  }
}

Fridge Door

A simple state machine can control the interior light of a fridge. Here’s the use-case:

The problem has one input (door open) and two outputs (light and audible alarm). If the door is open, turn on the light and start a timer for 90 seconds. If the door is still open at the end of the 90 seconds, start an audible alarm. If the door closes, stop the timer and turn off the light and alarm. And if the door closes during the 90 seconds, turn off the light.

Here is the state diagram.

And here is the corresponding code.

enum {FRIDGE_CLOSED, FRIDGE_OPEN, FRIDGE_BEEPING};
uchar  fridgeState;
uint16 fridgeTimer;
const uint16 FRIDGE_OPEN_LIMIT = 9000; // 90 seconds at 10msec tick
void fridgeTask(char event) {
  switch(fridgeState) {
    case FRIDGE_CLOSED:
      if (event == EVT_OPEN) {
        set_io(LIGHT, ON);
        fridgeTimer = FRIDGE_OPEN_LIMIT;
        fridgeState = FRIDGE_OPEN;
      }
      break;
    case FRIDGE_OPEN:
      if (event == EVT_CLOSE) {
        set_io(LIGHT, OFF);
        fridgeState = FRIDGE_CLOSED;
      }
      if (evt == EVT_TICK) {
        if (--fridgeTimer == 0) {
          set_io(ALARM, ON);
          fridgeState = FRIDGE_BEEPING;
        }
      }
      break;
    case FRIDGE_BEEPING:
      if (event == EVT_CLOSE) {
        set_io(ALARM, OFF);
        set_io(LIGHT, OFF);
        fridgeState = FRIDGE_CLOSED;
      }
    break;
  }
}

Refactor for changeState()

Notice on the state diagram, the arrows heads and tails cluster, and similar actions happen for multiple arrows. Perhaps we should write a function that just deals with all the actions required when leaving or entering a state. Then the task code would only have to manage the arrows of the state diagram. Like this:

// this outer code deals with the arrows on the state diagram
void fridgeTask(char event) {
  switch (fridgeState) {
    case FRIDGE_CLOSED:
      if (event == EVT_OPEN) changeFridgeState(FRIDGE_OPEN);
      break;
    case FRIDGE_OPEN:
      if (event == EVT_CLOSE) changeFridgeState(FRIDGE_CLOSED);
      if (event == EVT_FRIDGE_TIMEOUT) changeFridgeState(FRIDGE_BEEPING);
      break;
    case FRIDGE_BEEPING:
      if (event == EVT_CLOSE) changeFridgeState(FRIDGE_CLOSED);
      break;
  }
}

while the inner code deals with the actions required for entry and exit from each state

void changeFridgeState(char newState) {
  static char oldState = FRIDGE_CLOSED;
  // do all the state-leaving actions
  switch(oldState) {
    case FRIDGE_CLOSED:
      set_io(LIGHT, ON);
      setTimer(FRIDGE_TIMER, FRIDGE_OPEN_LIMIT);
      break;
    case FRIDGE_OPEN:
      break;
    case FRIDGE_BEEPING:
      set_io(ALARM, OFF);
      break;
  }
  // change state
  fridgeState = oldState = newState;
  // and do the state-entry code
  switch(newState) {
    case FRIDGE_CLOSED:
      set_io(LIGHT, OFF);
      setTimer(FRIDGE_TIMER, 0);
      break;
    case FRIDGE_OPEN:
      break;
    case FRIDGE_BEEPING:
      set_io(ALARM, ON);
      break;
  }
}

Door Opener

Suppose we have a power lock on a door, using a solenoid, and an RFID tag detector on the “outside” and a push button on the “inside”. There is also a WiFi connection to a server, by which we report door openings. When the RFID tag sends us a message, it will contain a serial number. If the number matches a known record, then operate the door-opener solenoid for 4 seconds. If the “inside” button is pushed, operate the door-opener for 4 seconds; if the “inside” button is pressed during the 4 seconds, restart the 4 second timer.

After the door is locked, send a report to the master control via the WiFi.

Here’s the state diagram:

Suppose now that the serial number needs to be verified by a central service. So when an RFID tag is detected, send a request to the master control and wait for an ACK or NAK response. In the case of an ACK, open the door solenoid for 4 seconds. The rest of the problem is as stated above.

I use EVT_ type events to indicate that they originate in hardware, probably at the interrupt level; and MSG_ type events to indicate they come from a software source, perhaps a sibling task.

Here’s the modified state diagram:

Beer Vat

Suppose we have to move a servo motor to lift the lid from a brewing vat, to release excess pressure.

Inputs: pressure valve, manual operation button Outputs: servo, LED, beeper

If high pressure is detected, flash the LED for 10 seconds, then operate the beeper for 5 seconds, then operate servo; hold it open for 5 seconds and return the servo, LED and beeper to idle.

If the manual operation button is pressed, go directly to “operate servo” as above.

If the manual button is pressed while the lid is open, close immediately.

Vending Machine

When idle, wait for payment tap. If selection button is pressed before payment, display cost to inform the user for 3 seconds.

After payment tap, request the user select item.

Operate dispense motor.

Wait for object to be removed from output bin.

Events

In all the above, events were implemented as a simple unsigned char, allowing 255 different event types.

There’s no reason we couldn’t use an unsigned short or even an int. Further, a 16 bit event number could be designed to be 8 bits of event type, and 8 bits of supplementary event information:

typedef struct Event {
  unsigned char type;
  unsigned char info;
} Event;

Event e = {MSG_KEYPRESS, KEY_A};

In the old Windows system, events/messages were realized as a 16 bit number, with extra 16 and 32 bit numbers glued to it for extra information.

typedef struct MSG {
  UINT   message;
  WPARAM wParam;
  LPARAM lParam;
};    // some extra detail removed

Timers

The simplest state timer is made with a static variable associated with the state code.

To start the timer, simply initialize the static variable. On timer ticks, decrement (or increment if you prefer) this variable until it hits a limit, and then make a state change.

For instance, to create a timer that waits 100 timer ticks, you could use:

static int state;
static int stateTimer;
void stateCode(char event) {
  switch(state) {
    case STATE_IDLE:
      if (event = EVENT_TRIGGER) {
        stateTimer = 100;
        state = STATE_DELAY;
      }
      break;
    case STATE_DELAY:
      if (event = EVENT_TICK) {
        if (--stateTimer == 0) {
          // the timer is finished
          state = STATE_NEXT;
        }
      }
      break;
    // ....
  }
}

In the above example, you could equally well have set the timer to start at zero and increment until it hits the desired limit (100 in this case).

In a moderate sized project, timers like this will proliferate throughout the code, making it awkward to read. One solution to this is to centralize the timers.

In all the above examples, the timer_isr() code is trivial, just newEvent(EVT_TICK). Suppose we add code to the timer_isr() so that it can process timer counting on behalf of the tasks……

Timers as a Resource

Let’s create a centralized service called setTimer(timer_index, timer_count).

A task can call this service with a unique timer_index and a requested count. The timer_isr() uses a pool of timer registers, and will count out the ticks on behalf of the task, and when the tick count is finished, the timer_isr() code can generate a unique event, perhaps EVT_TIMER_n.

So the state code can then look something like this:

static int state;
void stateCode(char event) {
  switch(state) {
    case STATE_IDLE:
      if (event = EVENT_TRIGGER) {
        setTimer(TIMER_1,100);
        state = STATE_DELAY;
      }
      break;
    case STATE_DELAY:
      if (event = EVENT_TIMER_1) {
          // the timer is finished
          state = STATE_NEXT;
        }
      }
      break;
    // ....
  }
}

This makes the state code simpler to read, hiding all the increments/decrements and limit testing.

The overhead for this ends up in the timer_isr() code, and might look something like this:

static uint16 timers[NUM_TIMERS];
#define EVT_TIMER_OFFSET 100
enum {EVENT_TIMER_1=EVT_TIMER_OFFSET, EVENT_TIMER_2, EVENT_TIMER_3}; // 100, 101...
enum {TIMER_1, TIMER_2, TIMER_3};   // 0,1,2,....

void timer_isr() {
  newEvent(EVT_TICK);           // the main tick, fires every time
  for (i=0; i<NUM_TIMERS) {     // the system timers, fires on completion
    if (timers[i]>0) {
      if (--timers[i]==0)
        newEvent(i + EVT_TIMER_OFFSET);
    }
  }
}

/* common service, available to all tasks */
void setTimer(int timerIndex, unsigned int timerCount) {
  timers[timerIndex] = timerCount;
}

volatile int timer;         // on most microcontrollers, access to an int
                            // will be atomic
INTERRUPT timer_isr(void) {
  timer++;
  newEvent(EVT_TICK);
}

// .... state code ...
static int targetTime;
void stateCode(uchar event) {
  switch(state) {
    case STATE1:
      //..... set a target
      targetTimer = time + DELAY_TIME;
      state = state2;
      //.....
    case STATE2:
      if (event == EVT_TICK) {
        if (time == targetTimer) {
          //.... we've waited long enough
        }
      }
    //...
  }
}

Real Code

Here is an example of a complete and tested project on a small STM32F030 board. Open all the little arrows to see the complete code.

#include "stm32f030.h"

/****** project hardware ******/
// on this demo board, there is a push button on PB13 and
// an LED on PA4 and PF5

#define LED  0x10 // port A bit 4  these LED are LOW=lit-up
#define LED2 0x50020 // port F bit 5
GPIO_TypeDef * GROUP[] = {GPIOA, GPIOB, GPIOC, GPIOD, 0, GPIOF};  // 0,0x10000,0x20000, etc
void gpio_set(uint32 bitPosition, bool value) {
  vu32* group = &((GROUP[bitPosition >> 16])->ODR);
  bitPosition &= 0xFFFF;
  if (value)
    *group |= bitPosition;
  else
    *group &= ~bitPosition;
}

/***** events ****/
#define NUM_EVENTS 10
volatile uchar events[NUM_EVENTS];
enum { EVT_NONE,
      EVT_TICK,
      EVT_BUTTON};
void newEvent(uchar e);

/********** tasks ***********/
void ledTask(uchar evt);
void respondToButtonTask(uchar evt);

/********** interrupts **************/
volatile uint32 tick;   // increasing at 100 ticks/sec
                        // takes a year to roll-over

void timer_isr(void) {
  tick++;
  newEvent(EVT_TICK);
  // this interrupt is auto-ack'd
}

void button_isr(void) {
  newEvent(EVT_BUTTON);
  EXTI->PR |= 0x3001;    // ack it 
}

/** newEvent
 * add the event to the event queue
 * wrapped in critical section
 * 
 * @param the event
 */
void newEvent(char e) {
        static uint nextEvent;
        dint(); // critical section
        events[nextEvent++] = e;
        if (nextEvent==NUM_EVENTS)
                nextEvent = 0;
        eint();
}

/***** init ******/
/* called by newlib startup */
void _init(void) {
  // startup code

  // use default clocks
  // turn on all the GPIO's
  RCC->AHBENR  = 0x005e0014;
  // enable SysCfg
  RCC->APB2ENR = 0x00004801;


  // enable the two LEDs as outputs
  GPIOA->MODER = (GPIOA->MODER & 0xFFFFFCFF) | 0x00000100; // port A bit 4
  GPIOF->MODER = (GPIOF->MODER & 0xFFFFF3FF) | 0x00000400; // port F bit 5
  // and the push button as input + pulldown
  GPIOB->PUPDR = (GPIOB->PUPDR & 0xF3FFFFFF) | 0x08000000; // pulldown on 13

  // keep the clocking system simple: just use the 8MHz HSI everywhere
  SysTick->LOAD = 10000;                // 10 msec
  SysTick->VAL  = 0;
  SysTick->CTRL = 3;                    // count at 1usec, use interrupts
 
  /* to configure an interrupt on the stm32f0xx,
    - enable the EXTI->IMR for the pin
    - set EXTI->RTSR for select rising edge
    - set the SYSCFG->EXTICRx pin to route it 
    - enable the gating bit in the NVIC register 
    - don't forget to ack each interrupt at EXTI->PR
  */
  EXTI->IMR         = 0x2000;        // enable interrupt from line 13
  EXTI->RTSR        = 0x2000;        // interrupt on rising edge
  SYSCFG->EXTICR[3] = 0x0010;   // select prot B for exti-13
  NVIC->ISER[0]     = 0x00E1;        // enable in NVIC: gpio & watchdog
}

void main(void) {

  eint();

  // dispatcher loop
  while(1) {
    int j;
    for (j=0; j<NUM_EVENTS; j++) {
       while (events[j]==EVT_NONE)
         {}
       ledTask(events[j]);
       respondToButtonTask(events[j]);
       events[j] = EVT_NONE;
    }
  }
}

/*********** task code, with states ************/
enum {LED_ON, LED_OFF};
enum {RTB_IDLE, RTB_ON};    // states
static uchar rtbState            = RTB_IDLE;
static uint16 rtbTimerCount      = 0;
const  uint16 BUTTON_LED_ON_TIME = 150;

void respondToButtonTask(uchar evt) {
  switch(rtbState) {
    case RTB_IDLE:
      if (evt == EVT_BUTTON) {
        rtbState      = RTB_ON;
        rtbTimerCount = BUTTON_LED_ON_TIME;
        gpio_set(LED, LED_ON);
      }
      break;
    case RTB_ON:
      if (evt == EVT_TICK) {
        if (--rtbTimerCount == 0) {
          gpio_set(LED, LED_OFF);
          rtbState = RTB_IDLE;
        }
      }
      break;
    }
}

const int LED_ON_TIME  = 150;
const int LED_OFF_TIME = 50;
static uchar  ledState      = LED_OFF;
static uint16 ledTimerCount = 0;

void ledTask(uchar evt) {
  switch(ledState) {
    case LED_OFF:
      if (evt == EVT_TICK) {
        if (++ledTimerCount > LED_OFF_TIME) {
          gpio_set(LED2, LED_ON);
          ledTimerCount = LED_ON_TIME;
          ledState      = LED_ON;
        }
      }
      break;
    case LED_ON:
      if (evt == EVT_TICK) {
        if (--ledTimerCount == 0) {
          gpio_set(LED2, LED_OFF);
          ledTimerCount = 0;
          ledState      = LED_OFF;
        }
      }
      break;
    }
}

/* vector table */
#define STACK_TOP 0x20002000
void default_isr(void) {}
extern void _start(void);

void (*myvectors[])(void) __attribute__ ((section(".vectors")))= {
    (void(*)(void)) STACK_TOP,     // stack pointer
    _start,        // code entry point
    default_isr,   // handle non-maskable interrupts
    default_isr, // handle hard faults
    0,0,0,0,                /* 10...1f */
    0,0,0,0,                /* 20...2f */
    0,0,0,timer_isr,        /* 30...3f */
    0,0,0,0,
    0,button_isr,button_isr,button_isr, /* 50...5f */
    0,0,0,0,                /* 60...6f */
    0,0,0,0,                /* 70...7f */
    0,0,0,0,                /* 80...8f */
    0,0,0,0,                /* 90...9f */
    0,0,0,0,                /* a0...af */
    0,0,0,0,                /* b0...bf */
    0,0,0,0,                /* c0...cf */
    0,0,0,0,                /* d0...df */
    0,0,0,0,                /* e0...ef */
    0,0,0,0,                /* f0...ff */
    0,0,0,0,                /* 100.10f */
    0,0,0,0                 /* 110.11f */
};

Substates

For things like flashing LED’s, you could create two states, and toggle between them, like this:

Or, you could simply have an internal (static, not-on-the-stack) variable which can keep track of the LED toggle. The state diagram then simplifies:

uchar rtbState = RTB_IDLE;              // major state, RTB_IDLE/RTB_FLASHING
uchar rtbSubState = RTB_FLASH_OFF;      // minor state, toggles LED on/off

Alternatively, you could use the timer counter variable, and make changes at the half-way point through the count. This simplifies the substate design to this:

const uint16 FLASH_CYCLE_TIME 150;
const uint16 FLASH_ON_TIME 40;
uchar rtbState = STATE_IDLE;
void rtbTaskCode(char event) {
  static uint16 flashCount=0;

  switch(taskState) {
    case RTB_IDLE:
      if (event == EVT_BUTTON) {
        rtbState = STATE_FLASHING;
        flashCount = FLASH_CYCLE_TIME;
      }
      break;
    case STATE_FLASHING:
      // count down flashCount, toggle LED halfway through
      // effectively creating a substate
      if (event == EVT_TICK) {
        if (--flashCount == 0) {
          setLED(OFF);
          flashCount = FLASH_CYCLE_TIME;
        } else if (flashCount == FLASH_ON_TIME) {
          setLED(ON);
        }
      // ... make sure to turn LED off when leaving this state
      if (event == EVT_BUTTON) {
        setLED(OFF);
        rtbState = RTB_IDLE;
      } 
      break;
    }
  }
}

State Machine Initialization

Notice that there’s no initialization of states in this code. It would be very handy if we knew when to initialize all the lights and buzzers and match up the various states. Perhaps the main() code could add a single event into the event queue at power-up, perhaps EVT_INIT. It might be added like this:

void main(void) {
  newEvent(EVT_INIT);  // early, before interrupts, so we know it's first in line
  eint();
  while(1) {
      ... dispatcher code ...
  }
}

Then, in the state code, you can catch that event and set up whatever might be required

uchar myState;
void stateCode(uchar event) {
  if (event==EVT_INIT) {
    // ... do setup code
    myState = FIRST_STATE;
    return;
  }
  // ... regular state machine code
}

Messages

Now that we have an event/dispatcher system, we can also also use it to send information asychronously between tasks. For example, if a keyboard processing task needs to inform its siblings, it can create messages which can be injected into the event queue.

Notice the change of terminology, where message indicates that the entry was created by code procesing, rather than an interrupt.

PostMessage()

We need a service routine to add messages to the event queue: postMessage(). This call is very smimilar newEvent() which should only be called from interrupts.

void postMessage(uchar message);

Notice that postMessage can’t return any information, because it’s not processed immediately; the message is added to the event queue to be processed at a later time.

SendMessage()

In some cases we may want the sibling task to process the information immediately. This means:

• we can be assured that the sibling task has fully processed the information
• does not involve the dispatcher
• requires extra room on the stack, since we’re calling within a call
• we could get a return value from the sibling task; since it’s implemented as a subroutine, it’s allowed to return a value

To return a value means that the prototype for task functions would change from

void taskCode(uchar event);
to
uchar taskCode(uchar event);

The service routine to send a message like this would look like:

uchar SendMessage(int8 taskPointer(uchar), uchar message) {
  return taskPointer(message);
}

Usage

Why might one want to send a message between tasks?

PostMessage() Suppose you have a rotary encoder, which sends quadrant signals, which need to be interpreted as clockwise and counter clockwise. You could have one task devoted to determining the direction of the knob (and debouncing), and have it send (or post) clean EVT_CW and EVT_CCW messages to its sibgling tasks.

Another possible use of messages is to create alternate souces of input. For example, a device which has a temperature set by “up/down” buttons on a front panel could receive the same controls from an infra-red remote, or even a serial port (perhaps for testing).

SendMessage() Perhaps you need to have a sibling task change states, or process information before you continue in your task. Imagine there is a slave WiFi chip that needs to be powered up before you send it a request….you could use sendMessage() to activate the power, and then continue, knowing that your peripheral is available.

Ideas for Tasks

I taught this coding technique at the college level, and a typical end-of-term assignment was to code up a simulated automobile entertainment system, which included about 6-10 concurrent tasks:

• task blue light to show bluetooth connectivity
• volume up/down sense and display
• radio channel select buttons
  • step single the radio frequency, or high-speed scan
• power on/off management
• remote control of volume/radio-select from the steering wheel (uart link)
• backlight for night-time viewing (auto sense from a light sensor)
• service-required LED, flashing
• a beeper to confirm keypresses (30ms) and alarm (700ms/100ms)
• a clock up/down set button
  • 3 buttons: “set min/hr” and “+” and “-”

Each list item above corresponds to one task. My students were able to code this up with about 35k of source, which compiles to about 8k of code and 256B of RAM (on an STM32)

More State Machines

Radio Tuner

Suppose we have a + and - button for tuning a radio. A press of either will move the radio frequency by one step. If the button is held for more than 0.5 seconds, the radio should change to a rapid scroll through all available frequencies.

Suppose we have events coming at 100msec, and that the radio frequencies are 88.7 up to 107.9, with steps at 0.1. And finally, suppose there are 5 available events:

enum {EVT_NONE, EVT_TICK, EVT_UP_PRESS, EVT_UP_RELEASE, EVT_DN_PRESS, EVT_DN_RELEASE};

const float MIN_FREQ=88.7, MAX_FREQ=107.9, INC_FREQ=0.1;
float radioFreq = MIN_FREQ;
uint16 radioTimer = 0;
const uint16 radioTimeout = 5;  // 0.5 seconds

enum {IDLE, FREQ_UP, FREQ_UP_FAST, FREQ_DN, FREQ_DN_FAST};
uchar state = IDLE;
void radioTask(uchar event) {
  switch(state) {
    case IDLE:
      if (event == EVT_UP_PRESS) {
        radioFreq += INC_FREQ;
        checkRadioFreq();
        radioTimer = radioTimeout;
        state = FREQ_UP;
      }
      if (event == EVT_DN_PRESS) {
        radioFreq -= INC_FREQ;
        checkRadioFreq();
        radioTimer = radioTimeout;
        state = FREQ_DN;
      }
      break;
    case FREQ_UP:
      if (event == EVT_UP_RELEASE) 
        state = IDLE;
      if (event == EVT_TICK) {
        if (--radioTimer == 0) 
          state = FREQ_UP_FAST;
      }
      break;
    case FREQ_UP_FAST:
      if (event == EVT_TICK) {
        radioFreq += INC_FREQ;
        checkRadioFreq();
      }
      if (event == EVT_UP_RELEASE) 
        state = IDLE;
      break;
    // and the same for FREQ_DN and FREQ_DN_FAST
  }
}

// manage rollover
void checkRadioFreq() {
  if (radioFreq > MAX_FREQ)
    radioFreq = MIN_FREQ;
  if (radioFreq < MIN_FREQ)
    radioFreq = MAX_FREQ;
}

This may seem like a lot of code, but it compiles to something quite small. It is non-blocking, and easily maintained and modified. And it works.

Temperature Control

Another example would be a user interface that had two buttons, marked “up” and “down”, an LED marked “setting”, some sort of numeric display, and some output device which needs to be controlled, such as a heater element, a motor on a mixer or even a volume setting on a sound system.

The user presses the “up” or “down” button, and the “setting: LED lights, to inform the user. Further presses of”up” or “down” modify the numeric display, but don’t yet affect the device which is being controlled.

When the users pauses for 1.5 seconds, the LED is extinguished and the new setting is used to control the output device.

The state diagram might look something like

UART Manager

It’s pretty common for these small microprocessors to have a UART service builtin. And it’s also pretty common for these small micros to be used as a slave to a more sophisticated master computer.

So I have written a UART streaming service as a task which fits into this Cooperative Multitasking (event driven) operating system.