Keywords

Embedded computing; real-time computing; open source; Linux; general public license

What is Embedded?

When I wrote the first edition of this book back in 2002, the notion of embedded computing devices was not widely appreciated. Back then many homes had at least a VCR and/or a DVD player and maybe a Tivo, all of which have at least one embedded processor. Most other appliances of the era were still basically electromechanical.

These days, virtually every appliance has an embedded computer in it. People are much more used to digital user interfaces, and while they may still not fully appreciate the nature of embedded computing, they are at least vaguely aware that they are surrounded by computers 24/7.

When I have to explain what I do for a living, I usually start by saying that an embedded system is a device that has a computer inside it, but the user of the device doesn’t necessarily know, or care, that the computer is there. It is hidden. The example I usually give is the engine control computer in your car. You don’t drive the car any differently because the engine happens to be controlled by a computer. Oh, and there’s a computer that controls the antilock brakes, another to decide when to deploy the airbags, and any number of additional computers that keep you entertained and informed as you sit in the morning’s bumper-to-bumper traffic.

I go on to point out that there are a lot more embedded computers out in the world than there are PCs. In fact, recent market data shows that PCs account for only about 2% of the microprocessor chips sold every year. The average house contains at least a couple dozen computers, even if it does not have a PC.

Is an Android smartphone an embedded system? It is small, self-contained, and has limited input/output capabilities. Nevertheless, you can personalize it and download “apps” to your heart’s content. In that sense, it’s really more of a general purpose computing appliance. So I would say no, an Android phone is not an embedded system.

From the viewpoint of programming, embedded systems show a number of significant differences from conventional “desktop” applications. For example, most desktop applications deal with a fairly predictable set of I/O devices—a disk, graphic display, a keyboard, mouse, sound card, and network interface. And these devices are generally well supported by the operating system. The application programmer doesn’t need to pay much attention to them.

Embedded systems, on the other hand, often incorporate a much wider variety of input/output (I/O) devices than typical desktop computers. A typical system may include user I/O in the form of switches, pushbuttons, and various types of displays often augmented with touchscreens. It may have one or more communication channels, either asynchronous serial, USB, and/or network ports. It may implement data acquisition and control in the form of analog-to-digital (A/D) and digital-to-analog (D/A) converters. These devices seldom have the kind of operating system support that application programmers are accustomed to. Therefore, the embedded systems programmer often has to deal directly with the hardware.

Embedded devices are often severely resource-constrained. Whereas a typical PC now has eight or more GB of RAM, and maybe a terabyte of disk, embedded devices often get by with a few MB of RAM and nonvolatile storage. This too requires creativity on the part of the programmer.

What is Real-Time?

Real-time is even harder to explain. The basic idea behind real-time is that we expect the computer to respond to its environment in time. But what does “in time” mean? Many people assume that real-time means really fast. Not true. Real-time simply means fast enough in the context in which the system is operating. If we’re talking about the computer that runs your car’s engine, that’s fast! That guy has to make decisions—about fuel flow, spark timing—every time the engine makes a revolution.

On the other hand, consider a chemical refinery controlled by one or more computers. The computer system is responsible for controlling the process and detecting potentially destructive malfunctions. But chemical processes have a time constant in the range of seconds-to-minutes at the very least. So we would assume that the computer system should be able to respond to any malfunction in sufficient time to avoid a catastrophe.

But suppose the computer were in the midst of printing an extensive report about last week’s production, or running payroll when the malfunction occurred. How soon would it be able to respond to the potential emergency?

The essence of real-time computing is not only that the computer responds to its environment fast enough, but that it responds reliably fast enough. The engine control computer must be able to adjust fuel flow and spark timing every time the engine turns over. If it’s late, the engine doesn’t perform right. The controller of a chemical plant must be able to detect and respond to abnormal conditions in sufficient time to avoid a catastrophe. If it doesn’t, it has failed.

I think this quote says it best:

So, the art of real-time programming is designing systems that reliably meet timing constraints in the midst of random asynchronous events. Not surprisingly, this is easier said than done and there is an extensive body of literature and development work devoted to the theory of real-time systems.

How and Why Does Linux Fit in?

Linux developed as a general-purpose operating system in the model of Unix, whose basic architecture it emulates. No one would suggest that Unix is suitable as an embedded or real-time operating system. It’s big, it’s a resource hog, and its scheduler is based on “fairness” rather than priority. In short, it’s the exact antithesis of an embedded operating system.

But Linux has several things going for it that earlier versions of Unix lack. It’s “free,”¹ and you get the source code. There is a large and enthusiastic community of Linux developers and users. There’s a good chance that someone else either is working or has worked on the same problem you’re facing. It’s all out there on the web. The trick is finding it.

Where is Linux Embedded?

Just about everywhere. A 2015 report from VDC Research claimed that in 2012 Linux powered 56.2% of embedded device unit shipments worldwide. That is expected to grow to 64.7% by 2017. Products incorporating Linux range from cell phones, personal digital assistants, and other handheld devices through to routers and gateways, thin clients, multimedia devices, and TV set-top boxes, to robots and even ruggedized VME chassis suitable for military command and control applications.

One of the first, and perhaps best known, home entertainment devices to embed Linux is the TiVo Personal Video Recorder that created a revolution in television viewing when it was first introduced in 2000. The TiVo is based on a Power PC processor and runs a “home grown” embedded Linux port that uses a graphics rendering chip for generating video.

Half the fun of having a device that runs Linux is making it do something more, or different, than the original manufacturer intended. There are a number of websites and books devoted to hacking the TiVo. Increasing the storage capacity is perhaps the most obvious hack. Other popular hacks include displaying weather, sports scores, or stock quotes, and setting up a web server.

Applications for embedded Linux are not limited to consumer products. It is found in point of sale terminals, video surveillance systems, robots, and even in outer space. NASA’s Goddard Space Flight Center developed a version of Linux called FlightLinux to address the unique problems of spacecraft onboard computers. On the International Space Station, Linux-based devices control the rendezvous and docking operations for unmanned servicing spacecraft called Automatic Transfer Vehicles.

Historically, telecommunications carriers and service providers have relied on specialized, proprietary platforms to meet the availability, reliability, performance, and service response time requirements of telecommunication networks. Today, carriers and service providers are embracing “open architecture” and moving to COTS (commercial off-the-shelf) hardware and software in an effort to drive down costs while still maintaining carrier class performance.

Linux plays a major role in the move to open, standards-based network infrastructure. In 2002, the Open Source Development Lab (OSDL) set up a working group to define “Carrier Grade Linux” (CGL) in an effort to meet the higher availability, serviceability, and scalability requirements of the telecom industry. The objective of CGL is to achieve a level of reliability known as “five nines,” meaning the system is operational 99.999% of the time. That translates into no more than about 5 minutes of downtime in a year.

Open Source Licensing

Most End User License Agreements for software are specifically designed to restrict what you are allowed to do with the software covered by the license. Typical restrictions prevent you from making copies or otherwise redistributing it. You are often admonished not to attempt to “reverse-engineer” the software.

By contrast, an Open Source license is intended to guarantee your rights to use, modify, and copy the subject software as much as you like. Along with the rights comes an obligation. If you modify and subsequently distribute software covered by an Open Source license, you are obligated to make available the modified source code under the same terms. The changes become a “derivative work,” which is also subject to the terms of the license. This allows other users to understand the software better, and to make further changes if they wish.

Open Source licenses are called “copyleft” licenses, a play on the word copyright intended to convey the idea of using copyright law as a way of enhancing access to intellectual property like software, rather than restricting it. Whereas copyright is normally used by an author to prevent others from reproducing, adapting, or distributing a work, copyleft explicitly allows such adaption and redistribution provided the resulting work is released under the same license terms. Copyleft thus allows you to benefit from the work of others, but any modifications you make must be released under similar terms.

Arguably, the best-known, and most widely used, Open Source license is the Gnu general public license (GPL) first released by the FSF in 1989. The Linux kernel is licensed under the GPL. But the GPL has a problem that makes it unworkable in many commercial situations. Software that makes use of, or relies upon, other software released under the GPL, even just linking to a library, is considered a “derivative work,” and is therefore subject to the terms of the GPL and must be made available in source code form.

To get around this, and thus promote the development of Open Source libraries, the FSF came up with the “Library GPL.” The distinction is that a program linked to a library covered by the LGPL is not considered a derivative work, and so there is no requirement to distribute the source, although you must still make the source available to the library itself.

Subsequently, the LGPL became known as the “Lesser GPL,” because it offers less freedom to the user. So while the LGPL makes it possible to develop proprietary products using Open Source software, the FSF encourages developers to place their libraries under the GPL in the interest of maximizing openness.

At the other end of the scale is the Berkeley Software Distribution (BSD) license, which predates the GPL by some 12 years. It “suggests,” but does not require, that source code modifications be returned to the developer community, and it specifically allows derived products to use other licenses, including proprietary ones.

Other licenses—and there are quite a few—fall somewhere between these two poles. The Mozilla Public License e.g., developed in 1998 when Netscape made its browser open-source, contains more requirements for derivative works than the BSD license, but fewer than the GPL or LGPL. The Open Source Initiative (OSI), a nonprofit group that certifies licenses meeting its definition of Open Source, lists 89 certified licenses on its website as of October 2016.

Most software released under the GPL, including the Linux kernel, is covered by version 2 of the license, which was released in 1991, coincidentally the same year that Linux was born. FSF released version 3 of the GPL in June of 2007. One of the motivations for version 3 was to address the problem of “tivoization,” a term coined by Richard Stallman. It turns out that Tivo will only run code with an authorized digital signature. So, even though Tivo makes the source code available in compliance with the GPL, modifications to that code won’t run.

Stallman considers this circumventing the spirit of the GPL. Other developers, including Linus Torvalds, see digital signatures as a useful security tool, and wouldn’t want to ban them outright. The debate continues. In any case, the kernel itself is unlikely to move up to version 3 any time soon, as it would require the agreement of literally thousands of developers.

Alternatives to Linux

Linux isn’t the solution to every problem. There are many devices that are simply too resource constrained to run Linux. A majority of the 50,000,000,000 devices expected to connect to the Internet of Things will likely be too small to run Linux. Nevertheless, these devices can benefit from running an operating system. Whereas Linux is a full-blown operating system with a kernel, device driver model, file systems, network stack, and a large collection of utilities, many alternatives are really just the kernel that handles scheduling, synchronization, and interrupts, and perhaps manages memory.

There are a great many operating systems out there, both open source and proprietary, but two stand out in my mind as being worth discussing.