To lay the groundwork for his new article series about the open-source FreeRTOS, Bob provides a history of early multi-tasking real time operating systems (RTOS) that allowed several tasks to run “simultaneously.” He explains how a multi-tasking RTOS works and the basic components of an RTOS, using FreeRTOS as an example.
In 2019, as the world prepared to celebrate the 50th anniversary of the 1969 lunar landing, I listened to a BBC Podcast with my grandkids entitled: 13 Minutes to the Moon (Figure 1) [1]. I highly recommend it for parents and grandparents as well as interested adults. I had a stake in NASA’s Apollo program because I worked for the company that made the back-up guidance system for the Lunar Module (LM). Initially called the BUGS (Back-Up Guidance System), it later became known as the Lunar Module Abort Guidance System (AGS). The AGS got its claim to fame in providing the guidance system for getting Apollo 13 back to earth [2]. I wanted my two youngest grandkids to get a taste of what it was like to be part of this momentous project, so this podcast was a great entry for them.
One of the points of drama in the podcast was the occurrence of errors in the LM guidance computer called the “1201 Alarm (Executive Overflow – No Core Sets)” and the “1202 Alarm (Executive Overflow – No VAC Area).” I will talk about Core Sets and VAC areas in just a minute. The crew had not prepared for these alarms. Interestingly, Mission Control did not abort the landing even though the flight computer reported these alarms five times during a four-minute time frame just before landing. And these were not just false alarms, nor did the designers consider them harmless. They were so serious that the guidance computer rebooted every time they happened!
MULTIPLE TASKS
Let me briefly mention the tasks of the guidance computer. It had to know the position of the LM as well as its trajectory. It used this information to maintain proper attitude as well as controlling altitude with the thrusters. It also needed to keep a running set of parameters (the abort trajectory) to get the LM back in lunar orbit should they need to abort at any moment. That’s quite a bit of math for the 16-bit computer running at 2MHz with slightly more than 32KB of program memory and 2KB of data memory. And in spite of what folklore and movies have told us, the LM could not be landed without the guidance computer. Figure 2 shows the LM Guidance Computer interface.
To handle all of this information and control the spacecraft, the guidance computer had a multi-tasking real-time operating system (RTOS) that allowed several tasks to run “simultaneously.” Of course, with a single core processor, nothing actually ran simultaneously. But this is one of the jobs of a multi-tasking RTOS—to allow several separate functions to be designed and run as if they were the only task running, sharing resources as needed between the functions. For example, calculating the necessary trajectories for an abort is one function that must be performed periodically.
Another function would be to control the thrusters based on inputs from the pilot and other sources. The LM guidance computer allowed for seven tasks to be running “simultaneously” and thus there were seven Core Sets. Each Core Set (much like a modern-day Task Control Block) contained the starting address of the task, the priority of the task, various flags, a pointer to the Vector Accumulator (VAC) and other task-specific data. The VAC was additional storage that a task could use—somewhat analogous to today’s dynamic heap. But there were more than seven tasks that the guidance computer had to perform. So, when a task was complete, it had to relinquish its Core Set and VAC for other tasks to use [3]. It was designed to never run out of Core Sets or VACs.
But, during the lunar landing, the guidance computer did run out of Core Sets (1201 Alarm) and Vector Accumulators (1202 Alarm) because there were more tasks that needed to run than the design allowed. There is a lot written about these alarms and, if you’re interested, you can look at the references I have provided in RESOURCES at the end of this article, as well as searching on your own. The topic makes for fascinating reading.
— ADVERTISMENT—
—Advertise Here—
This month I am launching a new series on FreeRTOS. This operating system has been around for over 15 years and provided the basics of an RTOS for limited resource microcontrollers (Figure 3). If you wanted simple tasking, multiple software timers and semaphore control with a quality scheduler, FreeRTOS was the place to go. But if you wanted networking, sophisticated memory management and built-in security, that was another story. Because my company was involved very early on in the Internet of Things (IoT) revolution, we needed far more sophistication than FreeRTOS provided. But in 2017, Amazon took stewardship of FreeRTOS and I knew that the FreeRTOS situation was all about to change. But I am getting ahead of myself. This month, we have to define some basic terms: What is a multi-tasking Operating System? What is a multi-tasking RTOS? What is a hard deadline RTOS? And, what are the basic components of an RTOS?
WHAT IS A MULTI-TASKING OS?
The word “multi-tasking” deserves some scrutiny. All modern operating systems allow multiple tasks. These are software functions that have their own stack and are, in varying degrees, independent of other tasks. In good OSes they even have their own memory space. Each task ideally should look like it has complete control of the processor.
But to define this further, let’s go back to the guidance computer on the LM. That will provide a good starting point at defining an operating system and the other questions as well. There are many pretty bogus definitions and some pretty misleading statements on the web. Let me entertain you with just a few:
“Without an operating system, a computer is useless.” [4]—This of course ignores the tens of thousands of “useful” computer systems that function without an operating system—sometimes called bare metal designs [5].
“An operating system, or “OS” is software that communicates with the hardware and allows other programs to run. It is comprised of system software, or the fundamental files your computer needs to boot up and function.” [6]—Okay. We are getting closer, but this is still fundamentally flawed. Many an OS doesn’t require files. And an OS does much more than “allow other programs to run.”
Let’s not be-labor this point and go right to Wikipedia:
“An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs.” [7] Not good English but if by “computer programs” we mean tasks (or threads) we can go with this.
If we apply this to the LM guidance computer, we see that the operating system managed the various elements of computer hardware: the RAM, the ROM, the various I/O ports (Inertial Measurement Unit, the Rendezvous radar, the Landing Radar, the Telemetry receiver, the display/keyboard, the hand controller and other interfaces). It managed the software resources like those we mentioned: Core Sets and VACs. And it provided common services for the various tasks—some of which we have already mentioned.
Modern day examples of operating systems are Windows, Linux, Android, macOS and a host of others. So, given that we have a good working definition of an operating system, the next question is:
— ADVERTISMENT—
—Advertise Here—
WHAT IS A MULTI-TASKING RTOS?
An RTOS is an operating system where temporal correctness is as important as logical correctness in interfacing with hardware and software resources at the application or task level—or what I will call the macro level. Most operating systems can provide temporal correctness for some hardware and software resources at the micro level—usually done at the interrupt level. For example, Windows or Linux (without real-time extensions) can service an A/D interrupt with temporal correctness as required by the hardware. Thus, you can create some pretty amazing and responsive systems with a non-real time OS.
But an RTOS must allow tasks to be temporally correct within some criteria. For example, if it was critical for a task to read a sensor every millisecond so as to not miss and respond to some sequential data, then the RTOS must guarantee that the task will be available to read and respond to the data before the next millisecond. The Left Ventricular Assist Device (LVAD) heart pump [8] that our company designed had this requirement. In the design, we were required to detect the R-Wave in the ECG signal, and start the heart pump (which augmented the heart’s pumping action) no later than 1 millisecond after the R-Wave (Figure 4). For a variety of reasons, it was not practical to perform this operation at the interrupt level (micro level real-time). So, we needed an RTOS so that we could have macro level real-time correctness at the task level. In our case we used Linux with real-time extensions. It worked flawlessly.
There are two different kinds of RTOSes: Hard deadline and Soft deadline RTOS. There is a lot of gray in this, but a simple definition is as follows: In a hard deadline RTOS people die or devices fail if the deadline is missed. All others are soft deadline RTOSes. The LM guidance computer was a hard deadline RTOS. If important tasks did not run on-time, the LM would crash or the mission aborted.
Examples of systems that use a hard-deadline RTOS abound: cars, airplanes and motion-controlled machinery are some that are obvious. Others, like cell phones or entertainment systems, are not so obvious. For example, a cell tower, by specification, requires the cell phone to respond within a fixed period of time. Missing these deadlines won’t kill anyone, but will make the device unreliable. We once tried to design a MIDI player with a Bluetooth interface to the Synthesizer. Music is a real-time and unforgiving activity. We found that the underlying RTOS in the Bluetooth module was not real time, and so the project never got off the ground.
BASIC RTOS COMPONENTS
Now let’s step through various components of an RTOS (Figure 5), using FreeRTOS as our focus.
The Kernel: The FreeRTOS site defines the kernel of an RTOS as the scheduler [9]. And that makes sense from a minimalist perspective. Think of the kernel of an RTOS as the software that is always running when nothing else is happening. That’s when you need to schedule any tasks that need to run or to just be idle.
The FreeRTOS source code provides the following definition of the kernel: “The kernel is contained within these three files”: list.c, queue.c and tasks.c. This is in keeping with their minimalist definition of the kernel being just the scheduler and the necessary components (lists and queues) to implement the scheduler. Other operating systems have a more expansive definition of the kernel.
The Scheduler: This software decides which task should run and for how long. There are many different scheduling algorithms available across the various RTOSes [10]. When I first started using UNIX (from which Linux was derived), it used a round robin scheduler or time-slice scheduler. This is where each task is assigned a time-slice of equal duration and the tasks are executed in a circular fashion with no priorities. I once changed a hard deadline Linux scheduler from a pre-emptive real time algorithm to round robin and was surprised how “real-time” it remained.
Linux allows you to use multiple scheduling algorithms in one design based on the nature of the task. Some can be pre-emptive, some can be round-robin and so on. A pre-emptive scheduler allows a task to be pre-empted while running by a task with a higher priority. FreeRTOS allows for either a pre-emptive scheduler or a time-slice/round-robin scheduler for the entire system.
The Inter-process communications (IPCs): I have extensively covered the inter-process communications tools available in Linux [11]. FreeRTOS supports queues, MUTEXs and semaphores.
Interrupts: Interrupt support is always dependent upon the specific port for the specific processor. FreeRTOS’ interrupt support is based on the port for a specific microprocessor architecture.
Timers: Although somewhat dependent upon the specific microprocessor port, most RTOSes support an array of software timers. FreeRTOS provides a good array of options for applications to use software timers (that are tied to the hardware).
The Hardware interfaces: This is a giant topic and includes memory, memory management and network interfaces (serial ports, Bluetooth, Wi-Fi, Ethernet and so on).
Security: Windows is often faulted because security was added on and not built in. But, from a minimalist perspective, security is not essential to an RTOS. We don’t see it in the three files that make up the minimal FreeRTOS. We will talk more about where security fits in RTOSes in general and FreeRTOS in particular in a later article.
CONCLUSION
This is a large bit to bite off in a thin slice. Next time we will look in more detail into each of the components of FreeRTOS. But of course, only in thin slices.
— ADVERTISMENT—
—Advertise Here—
RESOURCES
References:
[1] https://www.bbc.co.uk/programmes/p083t547
[2] https://www.innovationhartford.com/hal-taylors-innovative-work-with-utc-and-nasa/ This article provides some background about the LM AGS.
[3] https://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html For more details about the 1201 and 1202 alarms
[4] https://edu.gcfglobal.org/en/computerbasics/understanding-operating-systems/1/
[5] Wikipedia provides some useful definitions and examples of “bare metal” systems https://en.wikipedia.org/wiki/Bare_machine
[6] https://techterms.com/definition/operating_system
[7] https://en.wikipedia.org/wiki/Operating_system August 24th, 2020
[8] https://en.wikipedia.org/wiki/Ventricular_assist_device for a good definition
[9] “FreeRTOS is a real-time kernel (or real-time scheduler) on top of which embedded applications can be built to meet their hard real-time requirements.” from https://www.freertos.org/wp-content/uploads/2018/07/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf
[10] Wikipedia gives a good general summary of each of the scheduling algorithms https://en.wikipedia.org/wiki/Real-time_operating_system#Algorithms
[11] See Circuit Cellar articles – Issue 271 February 2013 Concurrency in Embedded Systems and Issue 273 April 2013 Introducing Linux Concurrency
FreeRTOS | www.freertos.org
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2020 #365 – Get a PDF of the issue
Sponsor this Article
Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org
