嵌入式系统编程：C和C++指南

需积分: 10 179 浏览量更新于2024-07-30 收藏 963KB PDF 举报

"Programming Embedded Systems in C and C++" 这本书，"Programming Embedded Systems in C and C++" 是由Michael Barr撰写的一本面向初学者的嵌入式系统开发指南。出版商是O'Reilly，第一版发布于1999年1月，共191页。该书特别适合那些已经有C或C++编程基础，并希望涉足嵌入式系统领域的读者。作者在书中涵盖了嵌入式系统开发的多个关键主题，如测试内存设备、编写和擦除闪存、验证非易失性存储内容、控制片上外设、设计和实现设备驱动、优化嵌入式代码以提高大小和速度，以及如何在不牺牲性能的情况下充分利用C++语言特性。书中内容结构清晰，首先从介绍什么是嵌入式系统开始，阐述了嵌入式系统的多样性和C语言作为嵌入式开发的最小公分母角色。接着，作者探讨了嵌入式系统设计的各种变体和应用领域，进一步引导读者理解这些系统的复杂性和独特性。在技术细节方面，读者将学习如何进行硬件交互，比如与内存和外设的通信，以及如何编写高效且适应性强的代码。设备驱动设计是嵌入式系统中的重要部分，书中有专门章节讲解这一主题，帮助读者理解如何为特定硬件平台构建和调试驱动程序。此外，书中还讨论了代码优化技巧，这对于有限资源的嵌入式环境至关重要。C++部分则强调如何在保持性能的同时利用C++的高级特性，例如类、模板和异常处理，这些都是在嵌入式开发中需要谨慎考虑的。书的前言部分，作者解释了编写此书的动机，目标读者群体，以及书的组织结构。他还指出了在书中的约定，包括排版和用词规则。同时，书中提供了获取在线示例的方法，方便读者实践学习。作者还鼓励读者在遇到问题时与他们联系，并在个人评论和致谢部分表达了对支持者的感激之情。 "Programming Embedded Systems in C and C++" 是一本全面而深入的嵌入式系统开发教程，对于想进入这个领域的程序员来说，是一份宝贵的资源，它不仅传授了必要的理论知识，还提供了丰富的实践指导。

Programming Embedded Systems in C and C++

- 16 -

Table 1-1. Common Design Requirements for Embedded Systems

Criterion Low Medium High

Processor 4- or 8-bit 16-bit 32- or 64-bit

Memory < 16 KB 64 KB to 1 MB > 1 MB

Development cost < $100,000 $100,000 to $1,000,000 > $1,000,000

Production cost < $10 $10 to $1,000 > $1,000

Number of units < 100 100-10,000 > 10,000

Expected lifetime days, weeks, or months years decades

Reliability may occasionally fail must work reliably must be fail-proof

In order to simultaneously demonstrate the variation from one embedded system to the next

and the possible effects of these design requirements on the hardware, I will now take some

time to describe three embedded systems in some detail. My goal is to put you in the system

designer's shoes for a few moments before beginning to narrow our discussion to embedded

software development.

1.2.1 Digital Watch

At the end of the evolutionary path that began with sundials, water clocks, and hourglasses is

the digital watch. Among its many features are the presentation of the date and time (usually

to the nearest second), the measurement of the length of an event to the nearest hundredth of a

second, and the generation of an annoying little sound at the beginning of each hour. As it

turns out, these are very simple tasks that do not require very much processing power or

memory. In fact, the only reason to employ a processor at all is to support a range of models

and features from a single hardware design.

The typical digital watch contains a simple, inexpensive 8-bit processor. Because such small

processors cannot address very much memory, this type of processor usually contains its own

on-chip ROM. And, if there are sufficient registers available, this application may not require

any RAM at all. In fact, all of the electronics-processor, memory, counters and real-time

clocks-are likely to be stored in a single chip. The only other hardware elements of the watch

are the inputs (buttons) and outputs (LCD and speaker).

The watch designer's goal is to create a reasonably reliable product that has an extraordinarily

low production cost. If, after production, some watches are found to keep more reliable time

than most, they can be sold under a brand name with a higher markup. Otherwise, a profit can

still be made by selling the watch through a discount sales channel. For lower-cost versions,

the stopwatch buttons or speaker could be eliminated. This would limit the functionality of

the watch but might not even require any software changes. And, of course, the cost of all this

Programming Embedded Systems in C and C++

- 17 -

development effort may be fairly high, since it will be amortized over hundreds of thousands

or even millions of watch sales.

1.2.2 Video Game Player

When you pull the Nintendo-64 or Sony Playstation out from your entertainment center, you

are preparing to use an embedded system. In some cases, these machines are more powerful

than the comparable generation of personal computers. Yet video game players for the home

market are relatively inexpensive compared to personal computers. It is the competing

requirements of high processing power and low production cost that keep video game

designers awake at night (and their children well-fed).

The companies that produce video game players don't usually care how much it costs to

develop the system, so long as the production costs of the resulting product are low-typically

around a hundred dollars. They might even encourage their engineers to design custom

processors at a development cost of hundreds of thousands of dollars each. So, although there

might be a 64-bit processor inside your video game player, it is not necessarily the same type

of processor that would be found in a 64-bit personal computer. In all likelihood, the

processor is highly specialized for the demands of the video games it is intended to play.

Because production cost is so crucial in the home video game market, the designers also use

tricks to shift the costs around. For example, one common tactic is to move as much of the

memory and other peripheral electronics as possible off of the main circuit board and onto the

game cartridges. This helps to reduce the cost of the game player, but increases the price of

each and every game. So, while the system might have a powerful 64-bit processor, it might

have only a few megabytes of memory on the main circuit board. This is just enough memory

to bootstrap the machine to a state from which it can access additional memory on the game

cartridge.

1.2.3 Mars Explorer

In 1976, two unmanned spacecraft arrived on the planet Mars. As part of their mission, they

were to collect samples of the Martian surface, analyze the chemical makeup of each, and

transmit the results to scientists back on Earth. Those Viking missions are amazing to me.

Surrounded by personal computers that must be rebooted almost daily, I find it remarkable

that more than 20 years ago a team of scientists and engineers successfully built two

computers that survived a journey of 34 million miles and functioned correctly for half a

decade. Clearly, reliability was one of the most important requirements for these systems.

What if a memory chip had failed? Or the software had bugs that caused it to crash? Or an

electrical connection broke during impact? There is no way to prevent such problems from

occurring. So, all of these potential failure points and many others had to be eliminated by

Programming Embedded Systems in C and C++

- 18 -

adding redundant circuitry or extra functionality: an extra processor here, special memory

diagnostics there, a hardware timer to reset the system if the software got stuck, and so on.

More recently, NASA launched the Pathfinder mission. Its primary goal was to demonstrate

the feasibility of getting to Mars on a budget. Of course, given the advances in technology

made since the mid-70s, the designers didn't have to give up too much to accomplish this.

They might have reduced the amount of redundancy somewhat, but they still gave Pathfinder

more processing power and memory than Viking ever could have. The Mars Pathfinder was

actually two embedded systems: a landing craft and a rover. The landing craft had a 32-bit

processor and 128 MB of RAM; the rover, on the other hand, had only an 8-bit processor and

512KB. These choices probably reflect the different functional requirements of the two

systems. But I'm sure that production cost wasn't much of an issue in either case.

1.3 C: The Least Common Denominator

One of the few constants across all these systems is the use of the C programming language.

More than any other, C has become the language of embedded programmers. This has not

always been the case, and it will not continue to be so forever. However, at this time, C is the

closest thing there is to a standard in the embedded world. In this section I'll explain why C

has become so popular and why I have chosen it and its descendent C++ as the primary

languages of this book.

Because successful software development is so frequently about selecting the best language

for a given project, it is surprising to find that one language has proven itself appropriate for

both 8-bit and 64-bit processors; in systems with bytes, kilobytes, and megabytes of memory;

and for development teams that consist of from one to a dozen or more people. Yet this is

precisely the range of projects in which C has thrived.

Of course, C is not without advantages. It is small and fairly simple to learn, compilers are

available for almost every processor in use today, and there is a very large body of

experienced C programmers. In addition, C has the benefit of processor-independence, which

allows programmers to concentrate on algorithms and applications, rather than on the details

of a particular processor architecture. However, many of these advantages apply equally to

other high-level languages. So why has C succeeded where so many other languages have

largely failed?

Perhaps the greatest strength of C-and the thing that sets it apart from languages like Pascal

and FORTRAN-is that it is a very "low-level" high-level language. As we shall see

throughout the book, C gives embedded programmers an extraordinary degree of direct

hardware control without sacrificing the benefits of high-level languages. The "low-level"

nature of C was a clear intention of the language's creators. In fact, Kernighan and Ritchie

included the following comment in the opening pages of their book The C Programming

Language :

Programming Embedded Systems in C and C++

- 19 -

C is a relatively "low level" language. This characterization is not pejorative; it simply means that C deals with

the same sort of objects that most computers do. These may be combined and moved about with the arithmetic

and logical operators implemented by real machines.

Few popular high-level languages can compete with C in the production of compact, efficient code for almost all

processors. And, of these, only C allows programmers to interact with the underlying hardware so easily.

1.3.1 Other Embedded Languages

Of course, C is not the only language used by embedded programmers. At least three other

languages-assembly, C++, and Ada-are worth mentioning in greater detail.

In the early days, embedded software was written exclusively in the assembly language of the

target processor. This gave programmers complete control of the processor and other

hardware, but at a price. Assembly languages have many disadvantages, not the least of which

are higher software development costs and a lack of code portability. In addition, finding

skilled assembly programmers has become much more difficult in recent years. Assembly is

now used primarily as an adjunct to the high-level language, usually only for those small

pieces of code that must be extremely efficient or ultra-compact, or cannot be written in any

other way.

C++ is an object-oriented superset of C that is increasingly popular among embedded

programmers. All of the core language features are the same as C, but C++ adds new

functionality for better data abstraction and a more object-oriented style of programming.

These new features are very helpful to software developers, but some of them do reduce the

efficiency of the executable program. So C++ tends to be most popular with large

development teams, where the benefits to developers outweigh the loss of program efficiency.

Ada is also an object-oriented language, though it is substantially different than C++. Ada was

originally designed by the U.S. Department of Defense for the development of

mission-critical military software. Despite being twice accepted as an international standard

(Ada83 and Ada95), it has not gained much of a foothold outside of the defense and

aerospace industries. And it is losing ground there in recent years. This is unfortunate because

the Ada language has many features that would simplify embedded software development if

used instead of C++.

1.3.2 Choosing a Language for the Book

A major question facing the author of a book like this is, which programming languages

should be included in the discussion? Attempting to cover too many languages might confuse

the reader or detract from more important points. On the other hand, focusing too narrowly

could make the discussion unnecessarily academic or (worse for the author and publisher)

limit the potential market for the book.

Programming Embedded Systems in C and C++

- 20 -

Certainly, C must be the centerpiece of any book about embedded programming-and this

book will be no exception. More than half of the sample code is written in C, and the

discussion will focus primarily on C-related programming issues. Of course, everything that is

said about C programming applies equally to C++. In addition, I will cover those features of

C++ that are most useful for embedded software development and use them in the later

examples. Assembly language will be discussed in certain limited contexts, but will be

avoided whenever possible. In other words, I will mention assembly language only when a

particular programming task cannot be accomplished in any other way.

I feel that this mixed treatment of C, C++, and assembly most accurately reflects how

embedded software is actually developed today and how it will continue to be developed in

the near-term future. I hope that this choice will keep the discussion clear, provide

information that is useful to people developing actual systems, and include as large a potential

audience as possible.

1.4 A Few Words About Hardware

It is the nature of programming that books about the subject must include examples. Typically,

these examples are selected so that they can be easily experimented with by interested readers.

That means readers must have access to the very same software development tools and

hardware platforms used by the author. Unfortunately, in the case of embedded programming,

this is unrealistic. It simply does not make sense to run any of the example programs on the

platforms available to most readers-PCs, Macs, and Unix workstations.

Even selecting a standard embedded platform is difficult. As you have already learned, there

is no such thing as a "typical" embedded system. Whatever hardware is selected, the majority

of readers will not have access to it. But despite this rather significant problem, I do feel it is

important to select a reference hardware platform for use in the examples. In so doing, I hope

to make the examples consistent and, thus, the entire discussion more clear.

In order to illustrate as many points as possible with a single piece of hardware, I have found

it necessary to select a middle-of-the-road platform. This hardware consists of a 16-bit

processor (Intel's 80188EB

[2]

), a decent amount of memory (128KB of RAM and 256 KB of

ROM), and some common types of inputs, outputs, and peripheral components. The board

I've chosen is called the Target188EB and is manufactured and sold by Arcom Control

Systems. More information about the Arcom board and instructions for obtaining one can be

found in Appendix A.

[2]

Intel's 80188EB processor is a special version of the 80186 that has been redesigned for use in embedded systems. The original

80186 was a successor to the 8086 processor that IBM used in their very first personal computer-the PC/XT. The 80186 was never

the basis of any PC because it was passed over (in favor of the 80286) when IBM designed their next model-the PC/AT. Despite

that early failure, versions of the 80186 from Intel and AMD have enjoyed tremendous success in embedded systems in recent

years.

剩余186页未读，继续阅读

haoranhit

粉丝: 0
资源: 1

嵌入式系统编程：C和C++指南

Programming Embedded Systems in C and C++

programming embedded systems in C and C++

Programming Embedded Systems in C and C++.chm

EmbeddedSystem_Programming_In_C&CPP

(ebook pdf) Programming Embedded Systems in C and C++

C-Embedded-Systems-Programming.rar_嵌入式/单片机/硬件编程_C/C++_

Programming.Embedded.Systems.in.C.and.C.Plus.Plus_plus

用C和C ++编程嵌入式系统（Michael Barr）Programming Embedded Systems in C and C++ (Michael Barr)

智慧建造总体策划方案（76页）.pptx

基于 Python2.7 和 PyQT4 开发的 modbus 通信采集软件

最新资源