构建嵌入式Linux设备：从网络路由器到DIY MP3播放器

需积分: 7 61 浏览量更新于2024-07-27 收藏 961KB PDF 举报

"嵌入式Linux是针对嵌入式系统和信息设备的设计者以及一般Linux程序员的专业知识领域。它深入地讲解如何将微型Linux发行版与你选择的硬件相结合，从而构建从网络路由器到自制MP3播放器等各种设备。书中提供了创建最小Linux系统的具体建议，以及如何根据目标（更好、更快、更便宜）选择合适的硬件，教授读者如何构建他们的第一个嵌入式Linux设备。书中的实践方法帮助读者找到最适合应用的开源软件，并指导选择调试应用的正确工具，同时避免陷阱，降低构建成本。例如，TiVo这样的产品就是基于Linux技术，能够自动录制电视节目。" 嵌入式Linux是一种将Linux操作系统应用于非传统个人计算机环境的系统，通常在资源有限、对功耗和性能有特定要求的设备中使用。这些设备可以是消费电子产品，如智能家居设备、手机、汽车导航系统，甚至是医疗设备和工业控制系统。Linux因其开源、稳定和可定制性而成为嵌入式开发的热门选择。嵌入式Linux的基础知识包括： 1. **硬件集成**：选择适合的处理器和外围设备，理解硬件接口，以及如何配置Linux内核以适应特定硬件平台。 2. **裁剪Linux系统**：为了适应有限的内存和存储空间，需要从完整的Linux发行版中删除不必要的组件，只保留必要的服务和库。 3. **编译固件**：使用交叉编译工具链在宿主机上构建适用于目标硬件的固件。 4. **启动加载器（Bootloader）**：如U-Boot，用于初始化硬件并加载内核到内存中。 5. **设备驱动程序**：为硬件设备编写或适配驱动程序，使Linux系统能够识别和控制它们。 6. **文件系统优化**：选择合适的文件系统类型（如ext2, ext3, YAFFS等），并进行优化以减少空间占用和提高读写速度。 7. **嵌入式应用程序开发**：利用C/C++、Python等语言编写高效的应用程序，利用Linux的API和库。 8. **电源管理**：在电池供电设备中，确保系统的低功耗运行。 9. **调试与测试**：使用GDB、Strace等工具进行调试，以及通过单元测试和系统测试验证功能和性能。 10. **安全性和稳定性**：考虑设备的安全性，包括防火墙设置、数据加密和固件更新机制，以防止未经授权的访问和保护用户隐私。 11. **持续集成和发布**：建立自动化构建和测试流程，以确保每次更新的质量和兼容性。学习嵌入式Linux不仅可以帮助你设计和构建自己的嵌入式设备，还可以提升你在物联网(IoT)、智能硬件和工业4.0领域的专业技能。通过实践和项目经验，你可以深入理解如何将Linux的优势应用于各种嵌入式场景，创造出高效、可靠且经济的产品。

Embedded Linux

Page 16

•

Typing

make config

make menuconfig

, or

make xconfig

in the root of the kernel source runs

the standard kernel configure routines. You can turn options on or off or sometimes compile

them as modules so they can be loaded at runtime.

•

There are hundreds—perhaps even thousands—of kernel patches floating around the Internet.

Some are very small—enough to fix a small bug in one file. Medium-size patches may affect a

half-dozen files and add support for a particular hardware device. Some large patches add or

affect many dozens of files and add support for new architectures. Often applying a patch adds

new questions or entire screens to the kernel-configuration screens previously described.

•

The One True Method of really "configuring" the kernel to do exactly what you want is to hack

on it yourself. Until recently, this was an exercise only for those who have lots of time and

patience—the Linux kernel source code is well structured but somewhat obtuse. Linus doesn't

believe in cluttering up the source with comments for the uninitiated (see Chapter 5 of

Documentation/Coding Style in the Linux source tree).

Fortunately, times have changed and there are now several good overviews of the Linux kernel. Perhaps

the most lucid is Understanding the Linux Kernel by Daniel Pierre Bovet and Marco Cesati (O'Reilly,

2000).

Networking, Filesystems, and Executable Formats

Some embedded Linux applications have no use for the networking code. Be sure to configure the

kernel so that the networking code is skipped if you don't need it; it takes up a lot of space. Also, make

sure that your kernel supports only the one or two filesystem types you actually need. Finally, you

probably need only one executable format, ELF (Executable and Linking Format), for your embedded

application, so be sure to turn off all the rest. For details on the ELF file format, consult the following

documents:

•

http://ibiblio.org/pub/Linux/GCC/ELF.doc.tar.gz

•

http://ibiblio.org/pub/Linux/GCC/elf.ps.gz

In general, it's a good idea to look through the documentation for all the choices in the kernel build

menu. If you're using

make menuconfig

to configure the kernel, you can press the question mark (

)

at any time to get information on the choice you have highlighted.

While you're developing your embedded device, it's handy to enable loadable module support in the

kernel. That way, if you need support for a feature that you hadn't anticipated, you can go back,

recompile the modules you need, copy them onto your device, and load them. Without loadable module

support, you have to recompile the whole kernel, which can be a bit of a pain. When you're done

developing the device, you can save some amount of RAM and ROM space by recompiling the kernel

without loadable module support and with your drivers compiled directly into the kernel. However, you

should figure out exactly how much of a savings this is and whether it's worth it—having loadable

module support may be useful for upgrading drivers in the field.

Execute-in-Place (XIP)

Embedded Linux

Page 18

Most of the time, it's not very important exactly how long a specific task takes to complete on a

computer. For instance, when someone hits a key on the keyboard, they expect a letter to appear

"instantly"—but how fast is "instantly"? It could be anywhere from a few tens of milliseconds to a

couple of hundred milliseconds. You're probably not going to notice the difference between any two

timings under 50 milliseconds (about 1/20th of a second). However, the timing of some operations in

some computer applications is crucial. For instance, if your application moves a robotic arm to a precise

location so that it can pick up a chip from a stack, then to another location so it can lay down the chip at

a precise location on a PC board, the timing of the movement operations must be exact. This is when

you need a real-time OS.

For instance, most modern cars have antilock braking systems. In these systems, special sensors detect

when one or more wheels begin to "lock up"—a dangerous situation that can cause the vehicle (and its

occupants!) to slide. In these situations, it's imperative that when the sensors detect a wheel beginning to

lock, the braking on that wheel be reduced immediately. Have you ever worked on a computer system

where you started a new program and the entire computer became unresponsive for several seconds?

Imagine what would happen if the computer controlling your antilock brakes was similarly busy and

unresponsive—right when a deer jumped in front of your car! This is a situation where you need what's

called hard real time .

A hard real-time OS guarantees that, without fail, no matter what else happens, a response to an event

will occur within a specified fixed time. For example, when wheel lockup is detected, braking for that

wheel must be reduced within a certain number of milliseconds. In this example, a hard limit exists on

how long the system can take to respond to the wheel lockup condition. This hard limit means that this is

a hard real-time task—first, because there's an absolute limit on the amount of time available for a

response, and second, because bad things will happen if the system fails to respond within the specified

time limit. These two features of the task to be performed make it clear that the task requires a hard real-

time operating system.

When working with a soft real-time OS, on the other hand, when an event occurs the system will try its

best to service the event within an average response time. For example, when playing a game of Quake

III, when a player fires a rocket at another player there's an expectation that the game program will draw

a fiery explosion onscreen, make explosion noises, and dutifully subtract health from your opponent.

With all of this complexity added to the existing events in the game, it's very likely that the frame rate of

the game may drop slightly while rendering the explosion and playing back the additional audio, since

these tasks require additional CPU time. If the frame rate should drop from 50 frames per second (fps)

to, say, 40 fps for the duration of the explosion, no harm is done—the player continues to enjoy her

game, since the system is still "fast enough." Being "fast enough" is a defining characteristic of soft

realtime systems. In this case, no fixed frame rate is required of the system, and no harm occurs should

the frame rate decrease slightly.

Both hard and soft real-time systems are useful, but they have distinctly different uses. In fact, a hard

real-time OS usually accommodates tasks requiring both hard and soft real-time response.

Several attributes differentiate a real-time operating system from a standard operating system, as shown

in the following list.

Embedded Linux

Page 19

•

Response time predictability. A hard real-time OS guarantees that the timing of some

operations will be precise within its stated limitations. These response times are much faster than

those of a typical operating system—they're measured in tens of microseconds (millionths of a

second) instead of milliseconds (thousandths of a second).

•

Schedulability. In a hard real-time operating system, a process can be scheduled to perform at a

very precise time in the future or at a very precise interval. Again, the precision is down to the

microsecond level instead of the millisecond level.

•

Stability under pressure. In a hard real-time system, the processor can become inundated with

far more signals from different sources than it can handle; however, some of those signals are

much more important than other signals and must be recognized and dealt with.The ability to

prioritize a vast array of different signals quickly and efficiently is another hallmark of a good

real-time system.

For more details on embedded real-time systems, see Raj Rajkumar, et al, The Concise Handbook of

Linux for Embedded Real-Time Systems Version 1.0 (Pittsburgh, Pennsylvania: TimeSys Corporation,

2000), p. 5. In addition, www.RealTimeLinux.org provides a lot of information about real-time Linux.

Several real-time Linux kernel projects are underway, as shown in Table 1.1 .

Table 1.1. Real-Time Linux Projects

Address Title Site Sponsor

www.rtlinux.org RTLinux—Real time

Linux

New Mexico Institute of

Technology

http://server.aero.polimi.it/projects/rtai/ RTAI—Real Time

Application Interface

Dipartimento di Ingegneria

Aerospaziale Politecnico di

Milano

www.ittc.ukans.edu/kurt/ KURT—The KU Real

Time Linux

University of Kansas

http://linux.ece.uci.edu/RED-

Linux/index.html

RED-Linux University of California, Irvine

Creating or Acquiring a Development Environment

Before you can even start coding, you must either create or acquire a development environment for your

chosen microprocessor or microcontroller. You'll need a C compiler, assembler (part of the compiler),

linker, runtime library, debugging tools, and perhaps an emulator. The fastest way to acquire a

development environment is to get it from one of the embedded Linux toolkits. Usually this is free or a

nominal price.

Booting the Kernel

Embedded Linux

Page 20

How the computer loads the operating system into memory and starts it is an issue that most software

developers never have to think about. Most of us work on PCs or similar platforms that have a BIOS that

does the dirty work of setting up the computer's hardware and finding and loading the OS loader (for

example, LILO or GRUB) into RAM so that the kernel can start. The most we ever have to think about

is which OS loader to use and how to configure it properly.

Welcome to the world of embedded devices, where you may start with a manual that says only

something like this:

"Hard Reset (HRESET)—Input" causes the hard reset exception to be taken and the physical address of

the handler is always x'FFF00100'.

PowerPC 601 RISC Microprocessor User's Manual (IBM Corporation, 1993), p. 5-16.

It's now up to you to write the assembly code to do the following:

1. Initialize all of the hardware.

2. Move the OS loader into memory from storage (or perhaps you just load the OS itself).

3. Jump into the code you just loaded.

Fortunately, most development boards for the various microcontrollers and microprocessors come with

ample documentation and sample code for startup. There are also many examples on the Internet for the

many different processors that Linux supports.

Software Size

Unlike a general-purpose computer system, an embedded system only requires enough software to

actually get a specific set of jobs done. This means you can do without a lot of the fluff that normally

goes into a general-purpose computer system such as X windows, email and newsreaders, games, and so

on. By doing this, you can make the software image much smaller. This is important because you

normally don't have a hard drive in an embedded application. Even when you do have one for storage, it

may be better to put the system software and applications in ROM or flash so they aren't as vulnerable to

corruption. Both ROM and flash are much more expensive byte-for-byte than space on a hard drive, so

it's important to include just the software that your embedded application actually uses.

Another reason to limit the software that ships in your embedded application is simple; if it's not there, it

can't break. It's usually very inconvenient to upgrade the software in an embedded application—

sometimes it's impossible.

However, a tradeoff exists between engineering time and footprint size. Generally, the longer you

engineer the product, the smaller and more efficient you can make it, reducing your memory

requirements, and thus reducing the cost of each unit. However, the more time you spend on efficiency,

the fewer features the product will have, given constant engineering resources. Also, if the product sits

in engineering too long, you may lose considerable market advantage to your competitors.

Reducing the Software Footprint

剩余163页未读，继续阅读

电网桌面软件开发

粉丝: 6
资源: 48

构建嵌入式Linux设备：从网络路由器到DIY MP3播放器

嵌入式LINUX基础教程中文第2版 --百度网盘

嵌入式linux设备驱动开发详解

嵌入式linux

嵌入式Linux 嵌入式Linux起步

嵌入式linux开发 嵌入式linux开发

嵌入式Linux和嵌入式Linux开发环境

嵌入式Linux与嵌入式Linux开发.pdf

嵌入式Linux应用程序开发详解嵌入式Linux网络编程,嵌入式Linux应用程序开发详解,C,C++源码.zip

嵌入式Linux应用程序开发详解嵌入式Linux网络编程_smallestbt3_linux_linux网络编程_嵌入式linu

嵌入式Linux C语言应用程序设计：嵌入式Linux C语言应用程序设计

最新资源

嵌入式linux开发嵌入式linux开发