Program structure and real time
This series of articles is about embedded systems – specifically the software that runs in an embedded system. It is worth starting by making sure that we are all on the same page and have our terminology straight. So, what is an embedded system? When I first wrote a book on this topic – back in 1986 – the word “embedded” did not occur in the title or anywhere in the text. This was simply because the term had not yet been coined. We were very much at a loss to give a handle to the systems we worked on, using terms like “dedicated systems” or “microsystems”, none of which were very satisfactory. A few years later, the word “embedded” started to be used and was rapidly adopted by everyone in the field.
So, back to my question: what is an embedded system? Having had a lot of practice at explaining to friends and family about what I work on, I tend to say something like “any electronic device that contains a microprocessor (CPU) that would not normally be described as a computer”.
An operating system (OS) is always used on a computer; the use of an operating system of some kind on modern embedded systems is common. Although prevalent in high-end (32- and 64-bit mainly) systems, there may be benefits from using a kernel in lower power devices. Operating systems are very much the focus of this series, with lots of detail in the articles to come in future months – firstly about operating systems in general, then taking a look at a specific implementation in depth.
Why Use an Operating System?
Having established that the key topic of this series is operating systems in embedded applications, it is worth just checking why they are employed. There are various explanations, some of which have got as much to do with human nature as they have technical requirements. I am reminded of a story. In one of our offices that I used to visit, there was a kitchen where one could prepare coffee. On the door was a sign which said “Please do not close this door.” Underneath, someone had written “Why not?” To that, someone else had responded: “Cuz.” This is, of course, an abbreviation for “Because”, which, in turn, is short for “Because we are telling you to behave in this way.” This is why an OS is employed on some systems – just because that is what is done: cuz.
Another explanation comes from looking at desktop applications. If you are going to write some software for a PC or a Mac, where do you start? Having got the computer, you switch it on and it starts up in Windows/Linux or macOS and you start programming. The OS is a given and provides useful services. It is very unlikely that you would consider starting from scratch, programming “bare” hardware. So, it is not surprising that an engineer, who has some software experience but is new to embedded software, would expect the “safety blanket” of an OS on their embedded system.
It is worth noting that the key aspect of a desktop OS, that users are aware of, is the user interface (UI). Ask someone what Windows is all about and they will mention windows, menus, dialogs and icons, but are less likely to talk about file systems and inter-program communication and interoperability. This is a fundamental difference between a desktop and an embedded system: an embedded device might not even have a UI – if it does, it may be quite simplistic. This is the first of many key differences that become apparent with a little thought:
An embedded system normally runs a single software application from the moment it is switched on until it is shut down.
Embedded systems have limited resources. Memory space may be large enough, but it is unlikely to be extensible; the CPU is probably just powerful enough, but with no extra capacity to spare.
Many embedded applications are “real time”. We will consider more carefully what this means later in this article.
Embedded software development tools are quite specialized and run on a “host” computer (like a PC), not on the final (“target”) system.
The updating of embedded software in service is challenging. Although with connected devices, possibilities are beginning to emerge; in-field updates are still not the norm (compared with the regular updates and patches applied to desktop software).
As we will see, an embedded OS provides a useful programming model to the developer, which can make its use very attractive.