This entry is part 3 of 3 in the series RTOS Alternatives.
In an earlier article we looked at the design and implementation of a time-triggered scheduler, but we didn’t consider the implications of actually using it. This can take some getting used to if you have never used such a system before. Imagine that we wanted to create a simple traffic light system… in a more traditional event-triggered design, it might look something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | typedef enum { LIGHT_RED, LIGHT_RED_AMBER, LIGHT_GREEN, LIGHT_AMBER } traffic_light_state; // Event triggered RTOS version. void Traffic_Light_Controller(void *parameters) { while (1) { Set_Lights(LIGHT_RED); Delay(15000); // wait 15 seconds Set_Lights(LIGHT_RED_AMBER); Delay(2000); // wait 2 seconds Set_Lights(LIGHT_GREEN); Delay(15000); Set_Lights(LIGHT_AMBER); Delay(2000); } } |
In a typical RTOS, calling the Delay function will cause the task to become blocked for the given duration (it is often hard to tell from the documentation if the delay is up to or at least the value — I have seen both). Blocking a task involves removing it from the list of tasks that the scheduler can execute (the ready list) and using a context switch to resume another task instead. Obviously this functionality is not available in our simple scheduler, as we do not have the ability to save and restore contexts (which generally requires platform-specific assembly code).
