It also grants you the right to freely develop and distribute applications based on eCos. We welcome all contributions back to eCos such as board ports, device drivers and other components, as this helps the growth and development of eCos, and is of benefit to the entire eCos community. One of the key technological innovations in eCos is the configuration system.
The configuration system allows the application writer to impose their requirements on the run-time components, both in terms of their functionality and implementation, whereas traditionally the operating system has constrained the application's own implementation.
Essentially, this enables eCos developers to create their own application-specific operating system and makes eCos suitable for a wide range of embedded uses. 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.
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 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. 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. 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. 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 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.
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. 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.
April 15, January 27, May 9, May 4, Earlier news items are available in the eCos news archive. Initially, the main hurdle is configuring the tools and source code to get your platform up and running. The source code to eCos is provided and the rights to change or add to the source are granted to the user. These rights are covered by the eCos Public License. One of the key aspects of eCos is its configuration system.
It allows the programmer to control what functionality and features are included at runtime. Selecting from package modules, the programmer can layer different functionality, such as an Ethernet driver and networking support or a different scheduling algorithm, according to the needs of the application. Unwanted features can be eliminated easily to reduce the resource footprint. The configuration system also enables developers to employ third-party components to extend and enhance the functionality of the operating system.
The base of this layered architecture is the hardware abstraction layer HAL. Once the HAL has been ported to run on a given target's processor and any specific configuration needed for the target platform itself is added, eCos can be up and running quickly.
Currently, numerous target architectures are supported by eCos and more ports will be added as programmers make them available. Table 1 lists some of the supported architectures. Device drivers, memory management, exception handling, timers, counters, and standard C and math libraries are all available. Complete development and debug tools are also provided, including software configuration and build tools, GNU-based compilers, assemblers, linkers, debuggers, and simulators.
The eCos host tools are available in Linux and Windows versions. The first component in the eCos system architecture is the hardware abstraction layer, which can be broken down into three sub-modules. The first HAL sub-module defines the architecture.
Each processor family supported by eCos is said to be a different architecture. Each architecture sub-module contains the code necessary for CPU startup, interrupt delivery, context switching, and other functionality specific to the instruction set architecture of that processor family.
A second HAL sub-module defines the variant. A variant is a specific processor within a processor family. An example of an eCos feature at this level is support for an on-chip peripheral like a memory management unit MMU.
The third HAL sub-module defines the platform. A platform, or board, is a specific piece of hardware that includes the selected processor architecture and variant.
This module includes code for startup, chip select configuration, interrupt controllers, and timer devices. The eCos kernel consists of a scheduler and mechanisms for thread synchronization, exception handling, interrupt handling, and timers.
The scheduler is the heart of the kernel and contains two modes of operation: bitmap and multi-level queue scheduling. Currently, only one scheduler is supported at a time. The bitmap scheduler represents each thread, which must have a unique priority, with a bit in a bitmap. The multi-level queue implements a number of thread priorities, where threads of the same priority can be timesliced.
Thread synchronization is accomplished through the use of mutexes and semaphores. These can be combined with event flags and message queues for thread communication. Exception handlers are routines for handling machine exceptions raised by hardware and software.
Passed to the handler routines are a pointer to context information that was previously registered with the handler, the exception number, and an error code. Exception handlers may be set up globally, per-thread, or both. Interrupt handlers process events caused by external devices. Since delivery of interrupts to the software is architecture specific, eCos provides a generalized scheme of utilizing an interrupt service routine ISR and a deferred service routine to maintain low interrupt latency.
The general mechanism for accessing a particular device is via a handle. Basic functions are provided to send and receive data from the device, as well as to manipulate the state of the driver or the actual device itself. The GNU development tools provide the build and debug capabilities and binary utilities support.
These tools have been described in Embedded Systems Programming magazine.
0コメント