Key Concept:

Sequential Programming

A sequential program explicitly waits in-line, for the expected events in various places in the execution path. This explicit waiting for events is implemented either by busy-polling or blocking on a time-delay, a semaphore or other such mechanism of a traditional Real-Time Operating System (RTOS).

share on: 
Share on reddit
Share on linkedin
Share on twitter
Share on email

Traditional Approach: Sequential Programming

Most embedded systems are traditionally programmed in a sequential manner, where the expected event sequences are hard-coded in the various blocking (or busy-polling) calls in the execution path.

An example of the basic sequential code is the traditional “Blink” implementation. This could be either a “superloop” or one of the treads in a RTOS-based design.

Arduino UNO with external blinking LED
				
					while (1) { /* "superloop" or a thread of an RTOS */
    BSP_ledOn();  /* turn the LED on  (computation) */
    delay(1000);  /* wait for 1000 ms (POLLING / BLOCKING) */
    BSP_ledOff(); /* turn the LED off (computation) */
    delay(1000);  /* wait for 1000 ms (POLLING / BLOCKING) */
}
				
			

Sequential programs (“superloop” or threads of a traditional RTOS) work well for sequential problems, where the expected sequence of events can be hard-coded in the sequential manner.

What's Wrong with the Sequential Paradigm?

Trouble is that most real-life systems are not sequential, meaning that the system must handle many, equally valid event sequences. The fundamental problem is that while a sequential program is waiting for one kind of event (e.g., timeout event after a time delay) it is not doing anything else and is not responsive to other events (e.g., a button press). The hard-coded event sequences are simply not flexible enough for most real-life problems.