Read an Excerpt
Linux for Embedded and Real-Time Applications
By Doug Abbott
Newnes
Copyright © 2013 Elsevier Inc.
All right reserved. ISBN: 978-0-12-391433-0
Chapter One
The Embedded and Real-Time Space
If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system.
Linus Torvalds
What Is Embedded?
You're at a party when an attractive member of the opposite sex approaches and asks you what you do. You could be flip and say something like "as little as possible," but eventually the conversation will get around to the fact that you write software for embedded systems. Before your new acquaintance starts scanning around the room for a lawyer or doctor to talk to, you'd better come up with a captivating explanation of just what the heck embedded systems are.
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's 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. In fact, the typical car today has more raw computing power than the Lunar Lander of the 1970s. Heck, your cell phone probably has more computing power than the Lunar Lander.
You can then go on to point out that there are a lot more embedded computers out in the world than there are personal computers (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 doesn't have a PC.
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 input/output (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 (OS). 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 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 touch screens. It may have one or more communication channels, either asynchronous serial, Universal Serial Bus (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 OS 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. Although a typical PC now has 4 GB of RAM and several hundred gigabytes of disk, embedded devices often get by with a few megabytes of RAM and non-volatile 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 real 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 also 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:
A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.
Donald Gillies in the Real-Time Computing FAQ
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 OS in the model of Unix whose basic architecture it emulates. No one would suggest that Unix is suitable as an embedded or real-time OS (RTOS). 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 OS.
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.
Open Source
Linux has been developed under the philosophy of Open Source software pioneered by the Free Software Foundation (FSF). Quite simply, Open Source is based on the notion that software should be freely available: to use, to modify, and to copy. The idea has been around for some 20 years in the technical culture that built the Internet and the World Wide Web and in recent years has spread to the commercial world.
There are a number of misconceptions about the nature of Open Source software. Perhaps the best way to explain what it is, is to start by talking about what it isn't.
• Open Source is not shareware. A precondition for the use of shareware is that you pay the copyright holder a fee. Shareware is often distributed in a free form that is either time- or feature-limited. To get the full package, you have to pay. By contrast, Open Source code is freely available and there is no obligation to pay for it.
• Open Source is not public domain. Public domain code, by definition, is not copyrighted. Open Source code is copyrighted by its author who has released it under the terms of an Open Source software license. The copyright owner thus gives you the right to use the code provided you adhere to the terms of the license. But if you don't comply with the terms of the license, the copyright owner can demand that you stop using the code.
• Open Source is not necessarily free of charge. Having said that there's no obligation to pay for Open Source software doesn't preclude you from charging a fee to package and distribute it. A number of companies are in the specific business of selling packaged "distributions" of Linux.
Why would you pay someone for something you can get for free? Presumably, because everything is in one place and you can get some support from the vendor. Of course, the quality of support greatly depends on the vendor.
So "free" refers to freedom to use the code and not necessarily zero cost. Think "free speech," not "free beer."
Open Source code is:
• Subject to the terms of an Open Source license, in many cases the GNU General Public License (GPL) (see below).
• Subject to critical peer review. As an Open Source programmer, your code is out there for everyone to see and the Open Source community tends to be a very critical group. Open Source code is subject to extensive testing and peer review. It's a Darwinian process in which only the best code survives. "Best" of course is a subjective term. It may be the best technical solution but it may also be completely unreadable.
• Highly subversive. The Open Source movement subverts the dominant paradigm, which says that intellectual property such as software must be jealously guarded so you can make a lot of money off of it. In contrast, the Open Source philosophy is that software should be freely available to everyone for the maximum benefit of society. And if you can make some money off of it, that's great, but it's not the primary motivation. Richard Stallman, founder of the FSF, is particularly vocal in advocating that software should not have owners (see Appendix C).
Not surprisingly, Microsoft sees Open Source as a serious threat to its business model. Microsoft representatives have gone so far as to characterize Open Source as "un-American." On the other hand, many leading vendors of Open Source software give their programmers and engineers company time to contribute to the Open Source community. And it's not just charity, it's good business!
Portable and Scalable
Linux was originally developed for the Intel x86 family of processors and most of the ongoing kernel development work continues to be on x86s. Nevertheless, the design of the Linux kernel makes a clear distinction between processor-dependent code, which must be modified for each different architecture, and code that can be ported to a new processor simply by recompiling it. Consequently, Linux has been ported to a wide range of 32-bit, and more recently 64-bit, processor architectures including:
• Motorola 68k and its many variants
• Alpha
• Power PC
• Advanced RISC Machines (ARM)
• Sparc
• MIPS
to name a few of the more popular. So whatever 32-bit architecture you're considering for your embedded project, chances are there's a Linux port available for it and a community of developers supporting it.
A typical desktop Linux installation runs into 10–20 GB of disk space and requires a gigabyte of RAM to execute decently. By contrast, embedded targets are often limited to 64 MB or less of RAM and perhaps 128 MB of flash ROM for storage. Fortunately, Linux is highly modular. Much of that 10 GB represents documentation, desktop utilities, and options like games that simply aren't necessary in an embedded target. It is not difficult to produce a fully functional, if limited, Linux system occupying no more than 2 MB of flash memory.
The kernel itself is highly configurable and includes reasonably user-friendly tools that allow you to remove kernel functionality not required in your application.
Where Is Linux Embedded?
Just about everywhere. As of July 2005, the web site LinuxDevices.com listed a little over 300 commercially available products running Linux. They range from cell phones, Personal Digital Assistant (PDAs), and other handheld devices through routers and gateways, thin clients, multimedia devices, and TV set-top boxes to robots and even ruggedized VMEbus, chassis suitable for military command and control applications. And these are just the products the LinuxDevices editors happen to know about.
One of the first and perhaps the 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 what the original manufacturer intended. There are a number of web sites 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.
(Continues...)
Excerpted from Linux for Embedded and Real-Time Applications by Doug Abbott Copyright © 2013 by Elsevier Inc. . Excerpted by permission of Newnes. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
