QNX Neutrino RTOS下的嵌入式系统开发指南

需积分: 5 8 浏览量更新于2024-07-18 收藏 1.63MB PDF 举报

《构建嵌入式系统指南》是一本专为使用QNX Neutrino实时操作系统（Real-Time Operating System, RTOS）进行嵌入式系统开发的开发者设计的实用手册。该指南由1996年至2014年的QNX Software Systems Limited，黑莓公司的一家子公司发行，版权所有。 QNX Software Development Platform 6.6 是本书的核心内容，它提供了全面的开发环境和工具集，旨在帮助开发者高效地在嵌入式环境中构建系统。本书覆盖了从系统架构、硬件选择到软件配置的各个方面，对于想要深入理解如何在QNX Neutrino RTOS架构下构建可靠、高效的嵌入式系统的开发者来说，具有重要的参考价值。第一章概述了构建嵌入式系统的整体概念。首先，介绍了初始化过程中的重要角色，即IPL（Initial Program Loader），它负责引导设备启动并加载操作系统。启动程序则负责设置系统的基本环境，包括初始化硬件、加载配置信息和执行必要的设置。接着，章节强调了QNX Neutrino RTOS在嵌入式系统中的核心地位。作为实时操作系统，它为嵌入式应用提供了关键的并发性和可靠性，确保系统能够稳定运行在资源受限的平台上。开发者需要了解如何与RTOS交互，以及如何利用其提供的服务和API来构建系统组件。硬件选择是构建嵌入式系统时不可忽视的部分，包括处理器的选择。开发者需要根据应用场景的需求（如性能、功耗、成本等）来决定合适的处理器架构。此外，确定合适的初始化和配置源也是关键，这通常涉及到选择适当的固件、配置文件或外部数据源，确保系统能在启动时正确配置。文件系统的选择同样重要，因为它们决定了数据的存储和管理方式。在QNX环境下，开发者可能需要考虑不同类型的文件系统，如闪存、NAND、SD卡等，以适应特定的存储需求和性能要求。 I/O设备的集成是另一个关键环节，包括串口、USB、网络接口等，这些设备的驱动程序和通信协议需要与RTOS兼容，以实现数据交换和系统扩展。最后，章节还指导读者如何开始实际的开发工作，包括安装开发工具、设置开发环境、编写和调试代码等步骤，确保开发者能顺利步入嵌入式系统的实践阶段。《构建嵌入式系统指南》不仅提供了理论知识，还结合了丰富的实践案例和实用技巧，旨在帮助开发者充分利用QNX Neutrino RTOS的优势，打造高效稳定的嵌入式解决方案。通过阅读此书，读者将能更好地理解和掌握嵌入式系统开发的各个环节，从而在实际项目中取得成功。

Introduction

From the software perspective, the following steps occur when the system starts up:

Processor begins executing at the reset vector. The Initial Program Loader (IPL)

locates the OS image and transfers control to the startup program in the image.

Startup program configures the system and transfers control to the microkernel

and process manager (procnto).

The procnto module loads additional drivers and application programs.

After we look at the software aspects in some more detail, we'll consider the impact

that the hardware has on this startup process.

The role of the IPL

The first step performed by the software is to load the OS image. This is done by a

program called the Initial Program Loader (IPL).

The IPL's initial task is to minimally configure the hardware to create an environment

that will allow the startup program, and consequently the microkernel, to run.

Specifically, this task includes at least the following steps:

Start execution from the reset vector.

Configure the memory controller, which may include configuring chip selects and/or

PCI controller.

Configure clocks.

Set up a stack to allow the IPL lib to perform OS verification and setup (image

download, scan, setup, and jump).

The IPL is described in detail in the chapter on Writing an IPL Program (p. 77).

Other

files

...

procnto

Startup

Figure 1: An OS image loaded by the IPL.

Warm-start and cold-start IPL

There are two general types of IPL: warm-start and cold-start. Warm-start IPL is typically

invoked by a ROM-monitor or BIOS; some aspects of the hardware and processor

configuration will have already been set up.

Overview of Building Embedded Systems

With cold-start IPL, on the other hand, nothing has been configured or initialized —

the CPU and hardware have just been reset. Naturally, the work that needs to be done

within a warm-start IPL will be a subset of the work required in a cold-start IPL.

We'll approach the discussion of the IPL's responsibilities starting at the end, describing

the goal or final state that everything should be in just before the first component of

the image is started. Then we'll take a look at the steps necessary to get us to that

final state.

Depending on the design of your target, you may have to take a number of steps,

ranging from none (e.g. you're running on a standard platform with a ROM monitor or

BIOS, and have performed a warm-start IPL via disk or network boot; the boot ROM

has done all the work described below for you) to many (e.g. you have a custom

embedded system without firmware and the image is stored on a specialized piece of

hardware).

The final state (just before the first component of the image is started) is characterized

by the following:

• The memory controller has been configured to give access to the memory present

on the system.

• Minimal hardware configuration has been performed (e.g. chip selects to map

EPROMs have been programmed).

• The entire image is now located in linearly addressable memory.

• The first part of the image, the startup code, is now in RAM. (Note that the startup

code is relatively small and that the RAM area is reclaimed when the startup code

is finished.)

Either the IPL or the BIOS/ROM monitor code is responsible for transferring the image

to linearly addressable memory. The OS image must have been built in a format that

the IPL or ROM monitor code understands so that it can know where to place the

image in memory and to what address to pass control after the image has been loaded.

For example, an IBM PC BIOS system typically loads a raw binary and then jumps to

the first address. Other systems may accept an image in ELF format, using the ELF

header information to determine the location to place the image as well as the starting

address. Refer to the documentation that came with your hardware to find out what

image formats the IPL code can accept.

Once the IPL has located the image, and the entire image is now in linearly addressable

memory, control is transferred to the startup program. At that point, the IPL is done

and is out of the picture.

The role of the startup program

The second step performed by the software is to configure the processor and hardware,

detect system resources, and start the OS. This is done by the startup program. (For

details, see the chapter on Customizing Image Startup Programs (p. 109).)

Introduction

While the IPL did the bare minimum configuration necessary to get the system to a

state where the startup program can run, the startup program's job is to “finish up”

the configuration. If the IPL detected various resources, it would communicate this

information to the startup program (so it wouldn't have to redetect the same resources.)

To keep QNX Neutrino as configurable as possible, we've given the startup program

the ability to program such things as the base timers, interrupt controllers, cache

controllers, and so on. It can also provide kernel callouts, which are code fragments

that the kernel can call to perform hardware-specific functions. For example, when a

hardware interrupt is triggered, some piece of code must determine the source of the

interrupt, while another piece of code must be able to clear the source of the interrupt.

Note that the startup program does not configure such things as the baud rate of serial

ports. Nor does it initialize standard peripheral devices like an Ethernet controller or

EIDE hard disk controller — these are left for the drivers to do themselves when they

start up later.

Once the startup code has initialized the system and has placed the information about

the system in the system page area (a dedicated piece of memory that the kernel will

look at later), the startup code is responsible for transferring control to the QNX

Neutrino kernel and process manager (procnto), which perform the final loading

step.

Startup's responsibilities

Let's take a look at the overall responsibilities and flow of the startup code:

Copy and decompress the image, if necessary.

Configure hardware.

Determine system configuration.

Start the kernel.

Copying and decompressing the image

If the image isn't in its final destination in RAM, the startup code copies it there. If

the image is compressed, the startup code automatically decompresses the image.

Compression is optional; you can create an image file that isn't compressed, in which

case the startup code won't bother trying to decompress it.

Configuring the hardware

The main task here is to set up the minimum required to be able to determine the

system configuration (and then perform the system configuration).

The details of what needs to be configured during the hardware configuration phase

depend on your particular hardware.

Overview of Building Embedded Systems

剩余247页未读，继续阅读

hushuo0428

粉丝: 2
资源: 33

QNX Neutrino RTOS下的嵌入式系统开发指南

Building Embedded Linux Systems, 2nd

building embedded linux systems, 2nd ed

making embedded systems 2fd edition pdf

real-time uml workshop for embedded systems

embedded systems firmware demystified

Embedded Linux Primer: A Practical, Real-World Approach

Design Patterns for Embedded Systems in C

design patterns for embedded systems in c : an embedded software engineering toolkit

嵌入式系统开发推荐书籍

real-time software design for embedded systems pdf

最新资源