Linux for Embedded and Real-time Applications

Doug Abbott

• Publisher: Newnes
• Year: 2017
• Print ISBN: 9780128112779
• eBook ISBN: 9780128112786
• Edition: 4
• Topic: Tecnologia e ingegneria
• Subtopic: Ingegneria generale

Linux for Embedded and Real-Time Applications, Fourth Edition, provides a practical introduction to the basics, covering the latest developments in this rapidly evolving technology. Ideal for those new to the use of Linux in an embedded environment, the book takes a hands-on approach that covers key concepts of building applications in a cross-development environment. Hands-on exercises focus on the popular open source BeagleBone Black board. New content includes graphical programming with QT as well as expanded and updated material on projects such as Eclipse, BusyBox – configuring and building, the U-Boot bootloader – what it is, how it works, configuring and building, and new coverage of the Root file system and the latest updates on the Linux kernel..- Provides a hands-on introduction for engineers and software developers who need to get up to speed quickly on embedded Linux, its operation and capabilities- Covers the popular open source target boards, the BeagleBone and BeagleBone Black- Includes new and updated material that focuses on BusyBox, U-Boot bootloader and graphical programming with QT

Part I

Introduction

Outline

Chapter 1 The embedded and real-time space

Chapter 2 Installing linux

Chapter 3 Introducing linux

Chapter 4 The host development environment

Chapter 5 Eclipse integrated development environment

Chapter 6 The hardware

Chapter 1

The embedded and real-time space

Abstract

This chapter introduces concepts of embedded and real-time programming and shows how Linux fits in. We point out that embedded systems are often resource constrained, and use unusual peripheral devices not often found in PCs. Real-time means that the system must respond to its environment in a predictable time, not necessarily fast, but predictable.

Keywords

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

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

Chapter Outline

What is Embedded? 3

What is Real-Time? 4

How and Why Does Linux Fit in? 5

Open Source 6

Portable and Scalable 7

Where is Linux Embedded? 8

Open Source Licensing 9

Legal Issues 11

Alternatives to Linux 11

FreeRTOS 12

MicroC/OS 13

Resources 14

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:

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

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Dedication
• Preface
• Part I: Introduction
• Part II: Application programming in a cross-development environment
• Part III: Components and tools
• Appendix A. U-boot Commands
• Appendix B. Why Software Should Not Have Owners
• Index