eCos组件编写指南：配置与组织详解

eCos

需积分: 9 49 浏览量更新于2024-08-01 1 收藏 977KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

《eCos组件编写者指南》由Bart Veer和John Dallaway共同编著，于2001年出版，版权属于Red Hat Inc。该指南主要针对eCos（实时操作系统）组件的开发和配置提供深入的指导，强调了在eCos组件框架中的灵活性和可配置性。 1. **概述**：指南首先介绍了一个全面的概念框架，概述了eCos组件开发的基础概念，包括术语定义、组件框架的组成部分，如组件、包和配置选项。读者可以在这里了解eCos组件设计的基本原则。 2. **组件与配置**：作者详细解释了组件是如何组织的，以及配置选项在组件构建过程中的作用。组件是可自定义的功能单元，而配置则是通过配置选项调整其行为或特性。配置选项可能影响组件的性能、功能实现或与其他组件的交互。 3. **CDL（Component Description Language）**： CDL是eCos组件描述的关键部分，它是一种用于定义组件属性、约束和冲突的元数据语言。通过CDL，开发者可以精确地描述组件的需求和限制，使得组件可以在不同的目标环境中正确配置和集成。 4. **组件仓库与配置的重要性**：书中讨论了组件仓库，即存储和管理组件的地方，以及为什么配置能力对于eCos组件至关重要。配置能力允许系统根据实际需求动态调整，提高系统的适应性和灵活性。 5. **配置方法与度量**：提供了多种配置方法的探讨，包括不同层次的配置，从简单的开关到复杂的依赖关系处理，帮助开发者理解和选择合适的配置策略。 6. **警告与注意事项**：随着指南深入，作者还提供了关于潜在陷阱和问题的警告，帮助开发者避免在组件开发过程中遇到的常见问题。 7. **包组织与构建流程**：包是组件开发的基本单元，指南阐述了如何组织包内容、处理依赖性，以及构建过程中如何处理可配置的源代码。此外，还介绍了如何编写测试用例和支持主机环境的工具链。 8. **包分发格式**：为了便于分发和部署，指南介绍了eCos包的分布文件格式，包括如何准备和打包组件，使其在不同的目标环境中能无缝集成。《eCos组件编写者指南》是一本详尽的资源，涵盖了从组件设计、配置管理到实际开发和分发的全过程，为eCos开发者提供了一套完整的组件化开发实践指南。无论是初次接触eCos的开发者，还是经验丰富的技术专家，都能从中获得宝贵的信息和实践经验。

资源详情

资源推荐

Chapter 2. Package Organization

Note: Earlier releases of eCos came with two separate ﬁles, targets and packages. The ecos.db database

replaces both of these.

Caution

The current ecos.db database does not yet provide all of the information needed by

the component framework. Its format is subject to change in future releases, and the

ﬁle may be replaced completely if necessary. There are a number of other likely future

developments related to the component repository and the database. The way targets

are described is subject to change. Sometimes it is desirable for component writers to

do their initial development in a directory outside the component repository, but there is

no speciﬁc support in the framework for that yet.

Package Versioning

Below each package directory there can be one or more version sub-directories, named after the versions. This

is a requirement of the component framework: it must be possible for users to install multiple versions of a

package and select which one to use for any given application. This has a number of advantages to users: most

importantly it allows a single component repository to be shared between multiple users and multiple projects,

as required; also it facilitates experiments, for example it is relatively easy to try out the latest version of some

package and see if it makes any difference. There is a potential disadvantage in terms of disk space. However

since eCos packages generally consist of source code intended for small embedded systems, and given typical

modern disk sizes, keeping a number of different versions of a package installed will usually be acceptable.

The administration tool can be used to remove versions that are no longer required.

The version current is special. Typically it corresponds to the very latest version of the sources, obtained

by anonymous CVS. These sources may change frequently, unlike full releases which do not change (or only

when patches are produced). Component writers may also want to work on the current version.

All other subdirectories of a package correspond to speciﬁc releases of that package. The component frame-

work allows users to select the particular version of a package they want to use, but by default the most recent

one will be used. This requires some rules for ordering version numbers, a difﬁcult task because of the wide

variety of ways in which versions can be identiﬁed.

1. The version current is always considered to be the most recent version.

2. If the ﬁrst character of both strings are either v or V, these are skipped because it makes little sense to

enforce case sensitivity here. Potentially this could result in ambiguity if there are two version directories

V1.0 and v1.0, but this will match the confusion experienced by any users of such a package. However

if two subsequent releases are called V1.0 and v1.1, e.g. because of a minor mix-up when making the

distribution ﬁle, then the case difference is ignored.

Chapter 2. Package Organization

3. Next the two version strings are compared one character at a time. If both strings are currently at a digit

then a string to number conversion takes place, and the resulting numbers are compared. For example v10

is a more recent release than v2. If the two numbers are the same then processing continues, so for v2b

and v2c the version comparison code would move on to b and c.

4. The characters dot ., hyphen - and underscore _ are treated as equivalent separators, so if one release goes

out as v1_1 and the next goes out as v1.2 the separator has no effect.

5. If neither string has yet terminated but the characters are different, ASCII comparison is used. For example

V1.1b is more recent than v1.1alpha.

6. If one version string terminates before the other, the current character determines which is the more recent.

If the other string is currently at a separator character, for example v1.3.1 and v1.3, then the former is

assumed to be a minor release and hence more recent than the latter. If the other string is not at a separator

character, for example v1.3beta, then it is treated as an experimental version of the v1.3 release and

hence older.

7. There is no special processing of dates, so with two versions ss-20000316 and ss-20001111 the numeri-

cal values 20001111 and 20000316 determine the result: larger values are more recent. It is suggested that

the full year be used in such cases rather than a shorthand like 00, to avoid Y2100 problems.

8. There is no limit on how many levels of versioning are used, so there could in theory be a

v3.1.4.1.5.9.2.7 release of a package. However this is unlikely to be of beneﬁt to typical users of a

package.

The version comparison rules of the component framework may not be suitable for every version numbering

scheme in existence, but they should cope with many common cases.

Caution

There are some issues still to be resolved before it is possible to combine the current

sources available via anonymous CVS and full releases of eCos and additional packages

in a single component repository. The ﬁrst problem relates to the ecos.db database: if

a new package is added via the CVS repository then this requires a database update,

but the administration tool is bypassed. The second problem arises if an organization

chooses to place its component repository under source code control using CVS, in

which case different directories will belong to different CVS servers. These issues will

be addressed in a future release.

Package Contents and Layout

A typical package contains the following:

1. Some number of source ﬁles which will end up in a library. The application code will be linked with this

library to produce an executable. Some source ﬁles may serve other purposes, for example to provide a

linker script.

2. Exported header ﬁles which deﬁne the interface provided by the package.

3. On-line documentation, for example reference pages for each exported function.

4. Some number of test cases, shipped in source format, allowing users to check that the package is working

as expected on their particular hardware and in their speciﬁc conﬁguration.

5. One or more CDL scripts describing the package to the conﬁguration system.

Chapter 2. Package Organization

It is also conventional to have a per-package ChangeLog ﬁle used to keep track of changes to that package.

This is especially valuable to end users of the package who may not have convenient access to the source code

control system used to manage the master copy of the package, and hence cannot ﬁnd out easily what has

changed. Often it can be very useful to the main developers as well.

Any given packages need not contain all of these. It is compulsory to have at least one CDL script describing

the package, otherwise the component framework would be unable to process it. Some packages may not have

any source code: it is possible to have a package that merely deﬁnes a common interface which can then be

implemented by several other packages, especially in the context of device drivers; however it is still common

to have some code in such packages to avoid replicating shareable code in all of the implementation packages.

Similarly it is possible to have a package with no exported header ﬁles, just source code that implements an

existing interface: for example an ethernet device driver might just implement a standard interface and not

provide any additional functionality. Packages do not need to come with any on-line documentation, although

this may affect how many people will want to use the package. Much the same applies to per-package test

cases.

The component framework has a recommended per-package directory layout which splits the package contents

on a functional basis:

For example, if a package has an include sub-directory then the component framework will assume that all

header ﬁles in and below that directory are exported header ﬁles and will do the right thing at build time. Sim-

ilarly if there is doc property indicating the location of on-line documentation then the component framework

will ﬁrst look in the doc sub-directory.

This directory layout is just a guideline, it is not enforced by the component framework. For simple packages

it often makes more sense to have all of the ﬁles in just one directory. For example a package could just contain

the ﬁles hello.cxx, hello.h, hello.html and hello.cdl. By default hello.h will be treated as an exported

header ﬁle, although this can be overridden with the include_ﬁles property. Assuming there is a doc property

referring to hello.html and there is no doc sub-directory then the tools will search for this ﬁle relative to the

package’s top-level and everything will just work. Much the same applies to hello.cxx and hello.cdl.

Tip: Older versions of the eCos build system only supported packages that followed the directory structure

exactly. Hence certain core packages such as error implement the full directory structure, even though

that is a particularly simple package and the full directory structure is inappropriate. Component writers can

decide for themselves whether or not the directory structure guidelines are appropriate for their package.

Outline of the Build Process

The full build process is described in Chapter 4, but a summary is appropriate here. A build involves three

directory structures:

Chapter 2. Package Organization

1. The component repository. This is where all the package source code is held, along with CDL scripts,

documentation, and so on. For build purposes a component repository is read-only. Application developers

will only modify the component repository when installing or removing packages, via the administration

tool. Component writers will typically work on just one package in the component repository.

2. The build tree. Each conﬁguration has its own build tree, which can be regenerated at any time using the

conﬁguration’s ecos.ecc saveﬁle. The build tree contains only intermediate ﬁles, primarily object ﬁles.

Once a build is complete the build tree contains no information that is useful for application development

and can be wiped, although this would slow down any rebuilds following changes to the conﬁguration.

3. The install tree. This is populated during a build, and contains all the ﬁles relevant to application devel-

opment. There will be a lib sub-directory which typically contains libtarget.a, a linker script, start-up

code, and so on. There will also be an include sub-directory containing all the header ﬁles exported by

the various packages. There will also be a include/pkgconf sub-directory containing various conﬁgura-

tion header ﬁles with #define’s for the options. Typically the install tree is created within the build tree,

but this is not a requirement.

The build process involves the following steps:

1. Given a conﬁguration, the component framework is responsible for creating all the directories in the build

and install trees. If these trees already exist then the component framework is responsible for any clean-ups

that may be necessary, for example if a package has been removed then all related ﬁles should be expunged

from the build and install trees. The conﬁguration header ﬁles will be generated at this time. Depending

on the host environment, the component framework will also generate makeﬁles or some other way of

building the various packages. Every time the conﬁguration is modiﬁed this step needs to be repeated,

to ensure that all option consequences take effect. Care is taken that this will not result in unnecessary

rebuilds.

Note: At present this step needs to be invoked manually. In a future version the generated makeﬁle

may if desired perform this step automatically, using a dependency on the ecos.ecc saveﬁle.

2. The ﬁrst step in an actual build is to make sure that the install tree contains all exported header ﬁles. All

compilations will use the install tree’s include directory as one of the places to search for header ﬁles.

3. All source ﬁles relevant to the current conﬁguration get compiled. This involves a set of compiler ﬂags

initialized on a per-target basis, with each package being able to modify these ﬂags, and with the ability for

the user to override the ﬂags as well. Care has to be taken here to avoid inappropriate target-dependencies

in packages that are intended to be portable. The component framework has built-in knowledge of how

to handle C, C++ and assembler source ﬁles — other languages may be added in future, as and when

necessary. The compile property is used to list the ﬁles that should get compiled. All object ﬁles end up in

the build tree.

4. Once all the object ﬁles have been built they are collected into a library, typically libtarget.a, which

can then be linked with application code. The library is generated in the install tree.

5. The component framework provides support for custom build steps, using the make_object and make

properties. The results of these custom build steps can either be object ﬁles that should end up in a library,

or other ﬁles such as a linker script. It is possible to control the order in which these custom build steps

take place, for example it is possible to run a particular build step before any of the compilations happen.

Chapter 2. Package Organization

Conﬁgurable Source Code

All packages should be totally portable to all target hardware (with the obvious exceptions of HAL and device

driver packages). They should also be totally bug-free, require the absolute minimum amount of code and

data space, be so efﬁcient that cpu time usage is negligible, and provide lots of conﬁguration options so that

application developers have full control over the behavior. The conﬁguration options are optional only if a

package can meet the requirements of every potential application without any overheads. It is not the purpose

of this guide to explain how to achieve all of these requirements.

The eCos component framework does have some important implications for the source code: compiler ﬂag

dependencies; package interfaces vs. implementations; and how conﬁguration options affect source code.

Compiler Flag Dependencies

Wherever possible component writers should avoid dependencies on particular compiler ﬂags. Any such de-

pendencies are likely to impact portability. For example, if one package needs to be built in big-endian mode

and another package needs to be built in little-endian mode then usually it will not be possible for application

developers to use both packages at the same time; in addition the application developer is no longer given a

choice in the matter. It is far better for the package source code to adapt the endianness at compile-time, or

possibly at run-time although that will involve code-size overheads.

Note: A related issue is that the current support for handling compiler ﬂags in the component framework

is still limited and incapable of handling ﬂags at a very ﬁne-grain. The support is likely to be enhanced in

future versions of the framework, but there are non-trivial problems to be resolved.

Package Interfaces and Implementations

The component framework provides encapsulation at the package level. A package A has no way of accessing

the implementation details of another package B at compile-time. In particular, if there is a private header ﬁle

somewhere in a package’s src sub-directory then this header ﬁle is completely invisible to other packages. Any

attempts to cheat by using relative pathnames beginning with ../.. are generally doomed to failure because

of the presence of package version directories. There are two ways in which one package can affect another:

by means of the exported header ﬁles, which deﬁne a public interface; or via the CDL scripts.

This encapsulation is a deliberate aspect of the overall eCos component framework design. In most cases it does

not cause any problems for component writers. In some cases enforcing a clean separation between interface

and implementation details can improve the code. Also it reduces problems when a package gets upgraded:

component writers are free to do pretty much anything on the implementation side, including renaming every

single source ﬁle; care has to be taken only with the exported header ﬁles and with the CDL data, because

those have the potential of impacting other packages. Application code is similarly unable to access package

implementation details, only the exported interface.

Very occasionally the inability of one package to see implementation details of another does cause problems.

One example occurs in HAL packages, where it may be desirable for the architectural, variant and platform

HAL’s to share some information that should not be visible to other packages or to application code. This may

be addressed in the future by introducing the concept of friend packages, just as a C++ class can have friend

functions and classes which are allowed special access to a class internals. It is not yet clear whether such cases

are sufﬁciently frequent to warrant introducing such a facility.

剩余157页未读，继续阅读

feichih

粉丝: 2
资源: 19

eCos组件编写指南：配置与组织详解

eCos Component Writer's Guide

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

matlab安装ecos

lim x cos( 1 + ecos(x) + 73x4) x→0 x

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

ecos 操作系统 配置

tcpdump ecos

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

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

ecos-2.0.7.post1-cp37-cp37m-win_amd64.whl

(1+ecos(f))x''+(1+4ecos(f))x'=0

ERROR: Could not build wheels for ecos, scs, which is required to install pyproject.toml-based projects

有哪些比较好的canopen开源实现

安装cvxpy常见错误

调用cvx包求解min||y-As||2+M^(-1/2)*|Ws^(1/2)Ds|

如何正确安装cvxpy

ERTEC200乱码

最新资源

ecos 操作系统配置