- Where It All Started—Cygnus Solutions
- The Origins of eCos
- Architecture Overview
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 The Origins of eCos
Initial design discussions for eCos began in the spring of 1997. The primary goal was to bring a cost-effective, high-quality embedded software solution to the marketplace. This new development would also complement the existing GNUPro tools, thereby expanding Cygnus' product offering.
Another essential requirement was that eCos needed to be designed in such a way that a small resource footprint could be constructed. By working with different semiconductor companies, Cygnus was able to architect a real-time operating system (RTOS) that abstracted the hardware layer and was highly configurable. This enabled the RTOS to fit into many diverse embedded systems. The highly configurable nature of eCos also allowed companies to reduce time to market for embedded products.
Reducing cost is always a concern in embedded systems. By using the open-source model, eCos was available with no initial costs. It could be downloaded and "test driven" free of charge. In addition to eliminating startup costs, another attractive cost-saving feature was that eCos had no backend charges—it had to be royalty-free.
Developers have full access to the entire software source code, including the tools, which can be modified as necessary (see Appendix B, eCos License, for the eCos license). There are no up-front license fees for the eCos run-time source code or any of the associated tools; everything needed to set up a complete embedded software development environment can be accomplished for free. Developers do not have to contribute back any additional components or applications developed; however, they are required to contribute back modifications to the eCos code itself. These contributions help the open-source community develop a better product.
Today, numerous companies are using eCos, and many successful products have been launched running eCos, including the Brother HL-2400 CeN network color laser printer, Delphi Communiport, and the Iomega Hip Zip Digital Audio Player.
1.2.1 In a Word: Configurability
In order to get an understanding of the eCos architecture, it is important to appreciate the component framework that makes up the eCos system. This component framework is specifically targeted at embedded systems and meeting the requirements associated in embedded design. Using this framework, an enormous amount of functionality for an application can be built from reusable software components or software building blocks. The eCos component framework has been designed to control components to minimize memory use, allow users to control timing behavior to meet real-time requirements, and use usual programming languages (e.g., C, C++, and assembly for certain implementations in the Hardware Abstraction Layer [HAL]).
Most embedded software today provides more functionality than what might actually be needed for a particular application. Often, extra code is included in a software system that gives generic support for functionality that embedded developers are not concerned with and is not needed. This extra code makes the software unnecessarily more complex. Furthermore, the more code, the greater the chance of something going wrong. An example would be a simple "Hello World" program. With most RTOSes, full support for mutexes, task switching, and other features would be included, even though it is not necessary for such a simplistic application. eCos gives the developer ultimate control over run-time components where functionality that is not needed can easily be removed. eCos can be scaled from a few hundred bytes up to hundreds of kilobytes when features such as networking stacks are included and third-party contributions such as Web servers are used.
Developers are able to select components that satisfy basic application needs, and config-ure that particular component for the specific implementation requirements for the application. This could mean enabling or disabling a particular feature within a component, or selecting a particular implementation for the component. An example of this is in the kernel scheduler con-figuration. eCos offers the developer options such as the ability to select the number of priority levels and whether time slicing is used. Any code unnecessary to meeting the developer's requirements is eliminated in the final image of the application.
Configurability allows a company to build an internal foundation of reusable components with access to the source code of the component. This can reduce development time and time to market because the components are highly portable and can be used in a wide range of applications. The eCos framework encourages third-party development to extend the features and functionality of the core eCos components. As more and more developers work toward extending the functionality on products and contribute these components back to the eCos project, the growth in functionality of eCos is limitless. Moreover, if the functionality is presently not available, the source code is there to accomplish the task yourself.
1.2.2 The eCos Configuration Method
As embedded systems are pushed to be smaller, faster, cheaper, and more sophisticated, control over all software in the system is necessary. There are different methods to control the behavior of components included in an application image. The philosophy of the eCos component control implementation is to reduce the size for systems that have resource limitations, even to the detriment of systems that do not have strict resource constraints. With this design philosophy in mind, minimal systems do not suffer from additional code necessary to support advanced features only used in more complex systems.
One method to control software components is at run time. In this method, no up-front configuration of the component is done. The code linked to the application provides support for all behaviors of the component whether it is required by the application or not, causing the code size to be much larger. An example of run-time control is an application that runs on a desktop. When the application is executed from the disk drive, the shared libraries (Dynamic Link Libraries [DLL], etc.) needed by the application are loaded when the application starts. Another method for component control is at link time. In this case, the code can use onlythe specific functions of a component that it needs, and the code that supports functionality not needed by the application is left out. Many linkers, such as the GNU linker (ld), offer link-time control, or commonly called, selective linking. With selective linking, unreferenced functions and data are removed from the application image. However, this is still insufficient because only entire functions can be removed—an all-or-nothing approach.
Compile-time control gives the developer control of the component behavior at the earliest stage, allowing the implementation of the component itself to be built for the specific application for which it is intended. Compile-time control gives the best results in terms of code size because the control is at the individual statement level in the source code rather than at the function or object level. This makes compile-time control very well suited for embedded development. eCos uses compile-time control methods for its software components, along with selective linking provided by the GNU linker. Using compile-time control or source-level configuration is achieved by using the C preprocessor. An example of source-level configuration is shown in Code Listing 1.1. The flag INCLUDE_FUNCTIONALITY is either enabled or disabled by the developer. When this section of the code is compiled, only the code that is needed is included in the application image.
Code Listing 1.1 Example code of source-level configuration.
1 #ifdef INCLUDE_FUNCTIONALITY 2 3 ... 4 5 #else 6 7 ... 8 9 #endif
With source-level configuration, very specific options can be applied in the code, which is appropriate for embedded systems since the majority of embedded applications compile into static images.
In addition to generating smaller code, source-level configuration offers many other advantages important in embedded software development:
Applications are faster because variables do not have to be checked during run time to determine what action to take.
The code is more responsive and latencies are reduced, which aids in creating a more deterministic system that is important in real-time devices.
A simpler code base is generated, making verification and testing easier.
The code is tailored for the application, creating an application-specific RTOS.
Costs can be reduced because resource usage is optimized and processor cycles are efficiently used, thereby enabling less expensive hardware to be specified in the design.
The Configuration Tool, provided with the eCos release, eases the selection and configura-tion of the software components. The tool also provides the capability to build the eCos framework from the software building blocks selected, which are then linked with the application. The Configuration Tool runs on both Windows and Linux platforms. A detailed look at the Configu-ration Tool is presented in Chapter 11, The eCos Toolset.
1.2.3 eCos Core Components
Certain standard functionality is expected in a real-time embedded operating system, including interrupt handling, exception and fault handling, thread synchronization, scheduling, timers, and device drivers. eCos delivers these standard components with the real-time kernel as the central core. The core components are:
Hardware Abstraction Layer (HAL)—providing a software layer that gives general access to the hardware.
Kernel—including interrupt and exception handling, thread and synchronization support, a choice of scheduler implementations, timers, counters, and alarms.
ISO C and math libraries—standard compatibility with function calls.
Device drivers—including standard serial, Ethernet, Flash ROM, and others.
GNU debugger (GDB) support—provides target software for communicating with a GDB host enabling application debugging.
Both eCos and the application run in supervisor mode. In the eCos system, there is no division between user and kernel mode.
A minimal test infrastructure is included with eCos. The tests are configured in a similar way to the application, which ensures that the exact configuration selected is tested. The Config-uration Tool provides the facilities for administering the tests. Expanding the current test infrastructure is planned in future eCos releases.
1.2.4 Processor and Evaluation Platform Support
eCos supports a wide variety of popular embedded processor architectures. This makes eCos a great choice for companies using many diverse hardware architectures on different product lines. Once the eCos HAL has been ported to a new architecture, the application layer can be moved over seamlessly to support the new application requirements.
The eCos software support is for standard commercial evaluation platforms on the market today. The main processor architectures supported include:
- ARM
- Fujitsu FR-V
- Hitachi H8/300
- Intel x86
- Matsushita AM3x
- MIPS
- NEC V8xx
- PowerPC
- Samsung CalmRISC16/32
- SPARC
- SPARClite
- SuperH
Appendix A, Supported Processors and Evaluation Platforms, lists the specific processor ports and evaluation platforms supported by eCos. Since many ports are contributed back to the eCos project for the benefit of others to use, the eCos Web site, at http://sources.redhat.com/ecos/hardware.html, is the best source for finding the most recent contributions for the eCos project.
1.2.5 eCos Support
Getting support is always a concern when trying to determine whether a certain product should be used. There are different means for getting support with eCos. The route used for obtaining support will greatly depend on the amount of assistance needed.
There are six different mailing lists available for the eCos project:
Discussion List—contains support and technical assistance on various topics about the eCos project from developers. The list can be found online at http://sources.redhat.com/ml/ecos-discuss, and the email address for the list is ecos-discuss@sources.redhat.com.
Patches List—used for submitting eCos patches for approval by the maintainers before they are committed to the source code repository. The list also hosts discussions about the different patches submitted. This list can be found online at http://sources.redhat.com/ml/ecos-patches, and the email address for posts is ecos-patches@sources.redhat.com.
Development List—includes discussions about current enhancements being developed, such as new ports and new features. General requests for help and information about eCos should be kept to the discussion list. This list can be found online at http://sources.redhat.com/ml/ecos-devel, and the email address is ecos-devel@sources .redhat.com.
Announcement List—a low-volume list for significant news about eCos that is also used to announce new eCos releases or major feature enhancements. This list can be found online at http://sources.redhat.com/ml/ecos-announce, and the email address is ecos-announce@sources.redhat.com.
CVS Web Pages List—contains notifications of changes to the eCos Web pages that are maintained in Concurrent Versions System (CVS). This read-only list can be found online at http://sources.redhat.com/ml/ecos-webpages-cvs.
CVS List—a read-only list that gives notifications of changes made to the eCos source code repository. This list can be found online at http://sources.redhat.com/ml/ecos-cvs.
As with all mailing lists, it is generally a good idea to dig in and try to find the answer to your problem before posting a previously reported, and solved, question to the list. To assist with this process, the eCos mailing lists provide a means for searching previous messages posted to the list.
Through my development using eCos, I have found that the discussion list is very responsive, compared to facilities provided by other companies in the past. I have found a two to three-day turnaround on getting answers to questions I have posted to the list from developers in the eCos community. However, it should be understood that not all questions asked on the discussion list are answered. Having questions that are very specific and detailed often helps the maintainers, and other developers, to lend support.
A great advantage of open-source development, and an open discussion list, is that the community for the project is there to assist in answering questions. Quite often, users who have encountered similar problems will post answers to aid their developer colleagues.
Users are able to subscribe to any of the lists and receive emails for all messages posted to a particular list or a digest form that contains a collection of messages from the particular list. Receiving individual messages can be somewhat overwhelming; therefore, subscription to the digest version of the discussion list might be better. To sign up for any of the mailing lists, you can go online at:
http://sources.redhat.com/ecos/intouch.html
Bug tracking for the eCos project is contained in a Bugzilla database. The Bugzilla database has an advanced search engine that allows searches based on keywords, for particular platforms, and specific versions of eCos. The Bugzilla database search engine can be found online at:
http://bugzilla.redhat.com/bugzilla/query.cgi?product=Red%20Hat%20eCos
Additional information about other features about the Bugzilla bug tracking software, including a new bug report form, can be found online at:
http://bugzilla.redhat.com/bugzilla
If there are private technical issues to discuss about eCos development and collaboration, the maintainers have an email address to reach them directly at: