An Introduction to the eCos World

This chapter is from the book

Embedded Software Development with eCos

Learn More Buy

This chapter is from the book

This chapter is from the book 

Embedded Software Development with eCos

Learn More Buy

1.3 Architecture Overview

eCos is designed as a configurable component architecture consisting of several key software components such as the kernel and the HAL. The fundamental goal is to allow construction of a complete embedded system from these reusable software components. This allows you to select different configuration options within the software component, or remove unused components altogether, in order to create a system that specifically matches the requirements of your application. By creating an eCos image that closely matches your system requirements, the size of the software is compact, only including used components. The software application is also faster because extra code is not executed, compared to other real-time operating systems that do not offer configurability and, therefore, incorporate all functionality regardless if it is required by the application.

Figure 1.1 shows an example of how the core building blocks, and some of the optional components available in the eCos system, can be layered together to incorporate the functionality needed for a specific application.

Figure 1.1 Example embedded software system showing layering of eCos packages.

Since configuration is a key aspect of the eCos system, tools are provided to manage the complexity of the different configuration options. These tools also allow components to be added or removed as needed. The tools build the main end product of an eCos configuration, which is a library that can be linked with application code.

1.3.1 eCos Terminology

The eCos configuration system involves some key terms that are important to understand. These terms are used in eCos documentation and throughout this book.

1.3.1.1 Component Framework

The collection of tools that allow users to configure the eCos system and manage different packages in the repository is called the component framework. Included in the component framework are the command-line configuration tool, the graphical Configuration Tool, the Memory Layout

Tool, and the Package Administration Tool. How these tools are used to manage and build an eCos configuration image is detailed in Chapter 11.

The component framework saves the collection of choices into a configuration. A configu-ration contains the packages that have been selected, as well as the status of options within the package describing whether the option is enabled, disabled, or set to a particular value. The framework tools operate on the configuration as a whole using the properties of configuration options to determine things such as default values and valid option ranges. The configuration is saved in a file with a .ecc extension. The relationship between a configuration and the values in the .ecc file is described in Chapter 11.

Figure 1.2 shows a portion of the eCos Kernel package from the Configuration Tool. The figure shows how the building blocks are encapsulated within each other to create a complete and independent package. We can see the hierarchy of the configuration from packages to components to configuration options to suboptions. Building blocks are grouped together in a package based on the functionality they include. In Figure 1.2, we see the eCos Kernel package, which contains the Kernel Exception Handling component and the Kernel Schedulers component; the other eCos Kernel components are not shown in this figure. We can see in Figure 1.2 the nesting of configuration options, such as Scheduler Timeslicing, and suboptions that compose the components. The different modules, components, and options are described further later in this section. Additional information about the Configuration Tool can be found in Chapter 11.

Figure 1.2 Example of the configuration building blocks that compose a package.

1.3.1.2 Component Repository

The component repository is a directory structure containing all packages from an eCos installation. The component framework includes a Package Administration Tool for adding new packages, updating current packages, and removing old packages within the repository. The main directory, ecos, contains the eCos distribution files. The subdirectory that contains the component repository is packages. A database file, ecos.db (located in the packages directory), is maintained by the Package Administration Tool and contains the details about the various packages in the component repository.

Occasionally, the database file needs to be hand edited. For example, when porting a HAL to your own hardware platform, editing the database file allows the new HAL to be recognized and controlled by the configuration tools. We will go through the process for editing the database file in Chapter 13, Porting eCos. In general, application developers can treat the repository as a read-only resource that can be reused for different applications. Figure 1.3 gives a high-level overview of the component repository directory structure.

Because eCos is an evolving code base with new contributions available all the time, the directory structure shown in Figure 1.3 is a snapshot of the eCos version 2 component repository. It is intended to show the overall layout of the eCos source code components rather than specifics about the directories. When new contributions to the eCos project are made, the maintainers decide if the contribution belongs under an existing subdirectory or requires the start of a new subdirectory. The latest eCos repository can be found online at:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=ecos

Figure 1.3 High-level component repository directory structure snapshot.

The details about configuring a system to use the latest source code found in the online repository are covered in Chapter 10, The Host Development Platform.

A description of the component repository directory structure is given in Table 1.1. Details of the directory structure and file contents for packages can be found in Chapter 11.

Table 1.1 Component Repository Directory Structure Descriptions

1.3.1.3 Configuration Options

The configuration option is the fundamental unit of configurability in the eCos system. Typically, a configuration option corresponds to a single choice you can make. This choice might be to enable, disable, or to set a value for the option. Configuration options have a macro associated with them. The macro is used in the source-level configuration control. Each macro has a sensible default value that can be used as a baseline. Once the application is built and running, the options can be tuned to meet the specific requirements of the system. The configuration options selected can affect which files are built into the eCos library, or cause certain values to be set in a particular file. In turn, selection of certain configuration options allows you to have control down to a particular source code line in some circumstances.

The component framework uses a Component Definition Language (CDL) to describe the package. Within each package is at least one CDL script file. This script file describes the package to the component framework. Detailed information about the CDL can be found in Chapter 11.

The configuration options detailed in this section are text names used by the graphical Configuration Tool. At this time, the configuration option and the relationship with its associated CDL name are unimportant. Throughout the book, the CDL names for specific components or options are given as reference.

The nesting of configuration options is used to give finer control over the system. This nesting of configuration options is shown in Figure 1.2. The configuration option Scheduler Timeslicing contains the configuration suboption Number of Clock Ticks Between Time Slices. If

Scheduler Timeslicing is enabled, a value, in this case 5, for the suboption can then be selected. If Scheduler Timeslicing is disabled, the suboption setting is irrelevant and cannot be set within the Configuration Tool.

A particular configuration option might have dependencies on other options in the config-uration. These dependencies, or constraints, are sometimes straightforward where one configu-ration option requires that another option be enabled. For example, in Figure 1.2, selecting the Bitmap Scheduler configuration option requires that Scheduler Timeslicing be disabled.

Other times, configuration options cannot be modified. Take the case of processor endian-ness. Some processors are hard-wired to operate in a specific endian mode, and others can be programmed to operate in either big-endian or little-endian mode at runtime. Depending on the hardware selected, endianness might not be a configuration option that can be modified. In other configuration options, the constraint might be a range for a particular value. For example, the configuration option Number Of Priority Levels has a constraint range of 1 to 32, which is currently set to 32 in Figure 1.2. Specifying a value out of this range is not allowed in the Configu-ration Tool.

As configuration options are modified, conflicts might arise because certain constraints are not satisfied. The configuration tools report these conflicts allowing us to take corrective action. These conflicts can be bypassed; however, compile-time or link-time failure might occur. Con-flicts should be resolved before continuing with the system configuration. The configuration tools try to resolve conflicts that arise during the configuration process. The tools might apply a solution automatically or ask us for intervention in solving the conflict. Additional information about conflicts can be found in Chapter 11.

1.3.1.4 Components and Packages

A component is a configuration option that encapsulates more detailed options within it. Entire components can be enabled or disabled, depending on the needs of a particular application. For example, in Figure 1.2, the Kernel Exception Handling component can be disabled by unchecking the box next to the component. Disabling the component causes all configuration options under that component, as well as any files associated with the component, to be irrelevant and not included in the build. This hierarchy of encapsulation gives us control of the configuration at a higher level. Eliminating unused components also reduces the compile time of the eCos image.

Another example where component control is useful is in the case where a particular device on the target hardware, such as an Ethernet port, is not going to be used in the application. Eliminating the device driver component for the Ethernet port reduces memory usage in the system.

A package is a type of component that is ready for distribution. Incorporated in a package are all necessary source code files, header files, configuration description files, documentation, and other relevant files. A package is often contained in a single file, allowing it to be installed with the appropriate tool or updated in the future when changes are made. Having a distribution package as a standalone unit allows third-party developers to extend the functionality offered in the eCos system. Enabling a package loads the configuration data into the appropriate tool. You also have control over the version of the packages that are used in the system.

1.3.1.5 Targets

A target is the piece of hardware on which the application will be executed. The target might be an off-the-shelf evaluation board, your own hardware platform, or a simulator. When creating a configuration, you select a target so that the component framework can load particular packages to support the devices and HAL relevant to the target. In addition, configuration options are changed from their default values to settings appropriate for the target.

The process is more automated for evaluation boards supported by eCos, whereas using your own hardware requires more involvement to determine what packages are to be loaded and the value of configuration option settings.

1.3.1.6 Templates

A template is a partial configuration that gives us a valid starting point. Templates are a combination of a hardware target and a group of packages. The group of packages is given a name, as shown in Table 1.2, to describe the functionality included. eCos comes with a small number of default templates. When a new configuration is created, a template is used as a starting point to match the general needs of the application. Configuration options can then be fine-tuned to meet more specific requirements you have. The configuration tools show the specific packages included in the template.

Table 1.2 eCos Templates