Read an Excerpt
Linux for Embedded and Real-Time Applications
By Doug Abbott
Newnes
Copyright © 2006 Elsevier Inc.
All right reserved.
ISBN: 978-0-08-049615-3
Chapter One
The Embedded and Real-Time Space "Software is like sex, it's better when it's free." —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 embedded systems.
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 anti-lock 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.
You can then 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 perhaps 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. 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. It may have one or more communication channels, either asynchronous serial 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.
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 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.
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?
By now just about everyone in the computer business knows the history of Linux; how Linus Torvalds started it all back in 1991 as a simple hobby project to which he invited other interested hackers to contribute. Back then no one could have predicted that this amorphous consortium of volunteer programmers and "the occasional loon," connected only by the Internet, would produce a credible operating system to compete with even the Borg of Redmond.
Of course, 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.
Open Source
Linux has been developed under the philosophy of Open Source software pioneered by the Free Software Foundation. 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. Open Source code is freely available and there is no obligation to pay for it.
* Open Source code 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.
* 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 Public License (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. Richard Stallman, founder of the Free Software Foundation, 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
* 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 a couple of gigabytes of disk space and requires 256 Mbytes or more of random access memory (RAM) to execute decently. By contrast, embedded targets are often limited to 64 Mbytes or less of RAM and perhaps 128 Mbytes of flash read-only memory (ROM) for storage. Fortunately, Linux is highly modular. Much of that couple of gigabytes 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 Mbytes 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 website LinuxDevices.com listed a little over 300 commercially available products running Linux. They range from cell phones, personal digital assistants (PDAs) and other handheld devices through routers and gateways, thin clients, multimedia devices, and TV set-top boxes to robots and even rugged VME 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 best known home entertainment devices to embed Linux is the TiVo personal video recorder (PVR) 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.
(Continues...)
Excerpted from Linux for Embedded and Real-Time Applications by Doug Abbott Copyright © 2006 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.
