eCos组件开发指南：配置与实践

需积分: 10 37 浏览量更新于2024-07-26 收藏 608KB PDF 举报

《eCos组件开发者指南》由Bart Veer和John Dallaway合著，于2000年出版，版权归属于Red Hat Inc。本指南主要针对eCos组件开发提供深入的指导，旨在帮助开发者更有效地构建、配置和管理可定制的组件。以下是章节概览和关键知识点： 1. **概述**：首先，作者对eCos组件框架进行了介绍，解释了术语和基本概念，包括组件（Component）、包（Package）和配置（Configuration）。这些元素是构建可配置系统的核心，允许用户根据需求定制软件的行为。 2. **组件框架**：这部分详细阐述了组件开发的基础架构，如配置选项（Configuration Option）、目标（Target）和模板（Template），以及它们如何影响组件的功能性和行为。同时，还讨论了组件约束（Constraints）、冲突（Conflicts）以及用于描述组件特性的Component Description Language (CDL)。 3. **包组织与仓库**：章节探讨了包在eCos组件生态系统中的作用，包括版本控制（Package Versioning）和包内容与布局。开发者需要理解如何组织代码，确保编译器依赖关系（Compiler Flag Dependencies）得到处理，并区分接口和实现（Package Interfaces and Implementations）。 4. **可配置源代码与文档**：指南强调了如何将配置选项融入到源代码中，如嵌套#include指令和包含配置头文件。此外，还包括如何编写详尽的包文档，以便其他开发者理解和使用。 5. **测试与支持**：作者提供了测试用例的编写指导，以及如何在主机环境中支持组件开发。这涉及到如何创建和分发eCos包装的详细过程，包括package distribution file format和准备工作。 6. **警告与最佳实践**：最后，书中列出了可能遇到的潜在问题和建议，以帮助开发者避免常见陷阱，确保组件的可靠性和一致性。《eCos组件开发者指南》是一本实用的工具书，它不仅提供了构建定制eCos组件的技术细节，还为开发者提供了解决实际问题的策略，是深入理解并进行高效eCos组件开发不可或缺的参考资料。

Chapter 1. Overview

them as appropriate; any unused functions will just get eliminated at link-time. Compile-time

selection of behavior is another option, and it can be the most powerful one of the three and the

best suited to embedded systems development.

Degrees of Conﬁgurability

Components can support conﬁgurability in varying degrees. It is not necessary to have any con-

ﬁguration options at all, and the only user choice is whether or not to load a particular package.

Alternatively it is possible to implement highly-conﬁgurable code. As an example consider a typ-

ical facility that is provided by many real-time kernels, mutex locks. The possible conﬁguration

options include:

1. If no part of the application and no other component requires mutexes then there is no point

in having the mutex code compiled into a library at all. This saves having to compile the

code. In addition there will never be any need for the user to conﬁgure the detailed behavior

of mutexes. Therefore the presence of mutexes is a conﬁguration option in itself.

2. Even if the application does make use of mutexes directly or indirectly, this does not mean

that all mutex functions have to be included. The minimum functionality consists of lock

and unlock functions. However there are variants of the locking primitive such as try-lock

and try-with-timeout which may or may not be needed.

Generally it will be harmless to compile the try-lock function even if it is not actually re-

quired, because the function will get eliminated at link-time. Some users might take the view

that the try-lock function should never get compiled in unless it is actually needed, to reduce

compile-time and disk usage. Other users might argue that there are very few valid uses for

a try-lock function and it should not be compiled by default to discourage incorrect uses.

The presence of a try-lock function is a possible conﬁguration option, although it may be

sensible to default it to true.

The try-with-timeout variant is more complicated because it adds a dependency: the mutex

code will now rely on some other component to provide a timer facility. To make things

worse the presence of this timer might impact other components, for example it may now be

necessary to guard against timer interrupts, and thus have an insidious effect on code size.

The presence of a lock-with-timeout function is clearly a sensible conﬁguration option, but

the default value is less obvious. If the option is enabled by default then the ﬁnal application

Chapter 1. Overview

image may end up with code that is not actually essential. If the option is disabled by default

then users will have to enable the option somehow in order to use the function, implying

more effort on the part of the user. One possible approach is to calculate the default value

based on whether or not a timer component is present anyway.

3. The application may or may not require the ability to create and destroy mutexes dynam-

ically. For most embedded systems it is both less error-prone and more efﬁcient to create

objects like mutexes statically. Dynamic creation of mutexes can be implemented using a

pre-allocated pool of mutex objects, involving some extra code to manipulate the pool and

an additional conﬁguration option to deﬁne the size of the pool. Alternatively it can be im-

plemented using a general-purpose memory allocator, involving quite a lot of extra code

and conﬁguration options. However this general-purpose memory allocator may be present

anyway to support the application itself or some other component. The ability to create and

destroy mutexes dynamically is a conﬁguration option, and there may not be a sensible de-

fault that is appropriate for all applications.

4. An important issue for mutex locks is the handling of priority inversion, where a high priority

thread is prevented from running because it needs a lock owned by a lower priority thread.

This is only an issue if there is a scheduler with multiple priorities: some systems may need

multi-threading and hence synchronization primitives, but a single priority level may sufﬁce.

If priority inversion is a theoretical possibility then the application developer may still want

to ignore it because the application has been designed such that the problem cannot arise

in practice. Alternatively the developer may want some sort of exception raised if priority

inversion does occur, because it should not happen but there may still be bugs in the code.

If priority inversion can occur legally then there are three main ways of handling it: priority

ceilings, priority inheritance, and ignoring the problem. Priority ceilings require little code

but extra effort on the part of the application developer. Priority inheritance requires more

code but is automatic. Ignoring priority inversion may or may not be acceptable, depending

on the application and exactly when priority inversion can occur. Some of these choices

involve additional conﬁguration options, for example there are different ways of raising an

exception, and priority inheritance may or may not be applied recursively.

5. As a further complication some mutexes may be hidden inside a component rather than be-

ing an explicit part of the application. For example, if the C library is conﬁgured to provide

a malloc call then there may be an associated mutex to make the function automatically

thread-safe, with no need for external locking. In such cases the memory allocation com-

ponent of the C library can impose a constraint on the kernel, requiring that mutexes be

Chapter 1. Overview

provided. If the user attempts to disable mutexes anyway then the conﬁguration tools will

report a conﬂict.

6. The mutex code should contain some general debugging code such as assertions and tracing.

Usually such debug support will be enabled or disabled at a coarse level such as the entire

system or everything inside the kernel, but sometimes it will be desirable to enable the

support more selectively. One reason would be memory requirements: the target may not

have enough memory to hold the system if all debugging is enabled. Another reason is

if most of the system is working but there are a few problems still to resolved; enabling

debugging in the entire system might change the system’s timing behavior too much, but

enabling some debug options selectively can still be useful. There should be conﬁguration

options to allow speciﬁc types of debugging to be enabled at a ﬁne-grain, but with default

settings inherited from an enclosing component or from global settings.

7. The mutex code may contain specialized code to interact with a debugging tool running on

the host. It should be possible to enable or disable this debugging code, and there may be

additional conﬁguration options controlling the detailed behavior.

Altogether there may be something like ten to twenty conﬁguration options that are speciﬁc

to the mutex code. There may be a similar number of additional options related to assertions

and other debug facilities. All of the options should have sensible default values, possibly ﬁxed,

possibly calculated depending on what is happening elsewhere in the conﬁguration. For example

the default setting for an assertion option should generally inherit from a kernel-wide assertion

control option, which in turn inherits from a global option. This allows users to enable or disable

assertions globally or at a more ﬁne-grained level, as desired.

Different components may be conﬁgurable to different degrees, ranging from no options at all to

the ﬁne-grained conﬁgurability of the above mutex example (or possibly even further). It is up to

component writers to decide what options should be provided and how best to serve the needs of

application developers who want to use that component.

Warnings

Large parts of eCos were developed concurrently with the development of the conﬁguration tech-

nology, or in some cases before design work on that technology was complete. As a consequence

the various eCos packages often make only limited use of the available functionality. This situa-

tion is expected to change over time. It does mean that many of the descriptions in this guide will

剩余197页未读，继续阅读

gxqf188

粉丝: 0
资源: 1

eCos组件开发指南：配置与实践

The eCos Component Writer's Guide

组件编写者指南 Component Writers Guide

eCos Component writer's guide修改理解eCos组件及源码的指导手册

matlab安装ecos

请举例说明ecos任务切换步骤及中断

ecos 操作系统 配置

tcpdump ecos

请举例讲解ecos进行任务切换的压栈情况

'ECOS', 'ECOS_BB', 'OSQP', 'SCIPY', 'SCS'分别应用在什么情况下

最新资源

ecos 操作系统配置