Linux for Embedded and Real-time Applications

Doug Abbott

• Publisher: Newnes
• Year: 2012
• eBook ISBN: 9780123914330
• Edition: 3
• Topic: Tecnologia e ingegneria
• Subtopic: Ingegneria elettronica e telecomunicazioni

This new edition of Linux for Embedded and Real-Time Applications provides a practical introduction to the basics and the latest developments in this rapidly evolving technology. Ideal for those new to using Linux in an embedded environment, it takes a hands-on approach and covers key concepts plus specific applications.Key features include: - Substantially updated to focus on a specific ARM-based single board computer (SBC) as a target for embedded application programming- Includes an introduction to Android programming With this book you will learn: - The basics of Open Source, Linux and the embedded space- How to set up a simple system and tool chain- How to use simulation for initial application testing- Network, graphics and Android programming- How to use some of the many Linux components and tools- How to configure and build the Linux kernel, BusyBox and U-Boot bootloader- Provides a hands-on introduction for engineers and software developers who need to get up to speed quickly on embedded Linux, its operation and its capabilities – including Android- Updated and changed accompanying tools, with a focus on the author's specially-developed Embedded Linux Learning Kit

Part 1

Introduction and Getting Started

Chapter 1 The Embedded and Real-Time Space

Chapter 2 Installing Linux

Chapter 3 Introducing Linux

Chapter 4 The Host Development Environment

Chapter 5 The Hardware

Chapter 6 Eclipse Integrated Development Environment

Chapter 1

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 wa...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Preface
• Part 1: Introduction and Getting Started
• Part 2: Application Programming in a Cross-Development Environment
• Part 3: Components and Tools
• Appendix A: U-Boot Commands
• Appendix B: Why Software Should Not Have Owners