Even with so many commercially available run-time solutions, more than 50 percent of all embedded projects today are built using in-house proprietary, or "roll your own", real-time technologies (Venture Development Corporation). The original eCos developers (Cygnus Solutions which later became part of Red Hat) partnered with microprocessor vendors and embedded product manufacturing companies to develop eCos around the requirement of an open, technically advanced run-time solution. eCos was designed to address the following fundamental issues that force embedded product manufacturing companies to develop their own run-time technologies:

• Cost - eCos is royalty free and license cost free. It is portable across chip architectures, which makes it well-suited for software developers of high-volume applications in consumer electronics, telecommunications, automotive and other deeply embedded applications,


• Control - eCos is an open-source run-time technology which fosters innovation, reduces risk, and places customers in control of their application specific content by enabling programmers on the Internet to read, redistribute, and modify the source code for eCos.


• Technical Fit - eCos provides source-level configuration (more than 200 configuration points) to exactly match application needs and is tightly integrated with the latest version of GNUPro tools, including highly optimized compilation technology, multi-threaded debugging, graphical configuration, test suites, etc.

Embedded systems have an amazing range of requirements, from 4 bit controllers up to large radar arrays with a thousand or so top of the range processors. Even if we limit the eCos target market to deeply embedded devices and to processors for which a gcc port is available, it is not possible to write a single system which meets everybody's requirements. The conventional approach forces application developers to adapt their software so that it works within the limitations of the operating system. The eCos approach is to provide a whole range of options and let the developer configure a system that best matches the needs of the application. Typical configuration options include the type of scheduler and the number of priority levels. The current release of the system has over 200 such options, and plenty more will be added as the system evolves.

Code and data size are vitally important for many embedded applications, so configurability must be achieved without adding any overheads. Some of it can be done at link time, but for maximum benefit most of it happens at compile time. It is possible for a configuration option to affect a single line of code, when this is appropriate. On the other hand a single configuration option might control the presence or absence of a complete TCP/IP stack. For system code written in C or C++ the main mechanism that is employed is C preprocessor #ifdef statements, which will be familiar to most embedded application developers.

Using #ifdef statements to provide a small number of configuration options is of course not very original. The critical problem is that configuration options are not independent: for example, changing a kernel option may affect whether or not the C library can provide thread-safe versions of various routines. The key innovation in eCos is that configuration options are treated as data items in their own right, complete with descriptions of all the dependencies between the various options. There is a graphical configuration tool which allows users to conveniently manipulate the various options, understand the various interactions, and check that the resulting configuration is valid.

The configuration framework also serves to componentize the system into different packages. The core system consists of a number of different packages including the kernel, the C library, and the math library. It is possible to enable or disable entire packages, as well as to manipulate configuration options within these packages. It is also possible to add new packages to the system, for example a TCP/IP stack. The key point is that these new packages can specify dependencies on other parts of the system, for example the TCP/IP stack could specify that it needs per-thread data support. The same technology that makes configurability work in the core system allows new packages to be added to the system and readily incorporated into an application. We expect large numbers of these packages to become available over time, and already there are software vendors who want to turn their existing software into eCos packages. We expect that many contributions from the open source community will take the form of ports of existing software or of completely new packages.

The eCos configuration system does not affect how you develop your own application code. It is not necessary to write your application in any special language, or to provide lots of configuration options in your own code, or to use a special development environment. The main output from the configuration system is a library that gets linked with your application code in the usual manner.

Certainly. There are several mailing lists which anybody can subscribe to. The ecos-announce mailing list is a low-volume moderated list for major announcements. The ecos-discuss mailing list is an unmoderated list for general discussion, both technical and non-technical among eCos users. The ecos-devel mailing list is for more technical discussions among developers of eCos itself. All the core eCos development team read these lists and participate in discussions as appropriate. Other more obscure lists exist to keep track of every detailed change in the eCos project. If you prefer you can subscribe to digest versions of these mailing lists instead.

We strongly recommend you read both the eCos documentation fully and search the above mail archives before asking simple questions on the list, particularly if they are likely to be problems that people would have encountered before.

If you have a question which you do not want to discuss in a public forum then there is a separate ecos-maintainers mail address. However note that general requests for help or information that would be more appropriate to a public list like ecos-discuss may not be answered.

A side effect of a fully configurable system is that it is just about impossible to answer questions like "What is the memory footprint of the kernel?" or "What is the interrupt latency?" These figures depend in large part on the configuration options selected by the user. For example if a simple application does not require the kernel at all, directly or indirectly, then the kernel package can be disabled completely and its memory footprint is 0 bytes.

Basic performance characterization data is available as part of the documentation as part of the architecture specific Getting Started manual, together with a description of the tests that were used to obtain this data. The sources for these tests are included with the eCos distribution.

There is no notion of separate address "spaces" in eCos like there would be in a system like Linux. All threads share the same address space and access capabilities. Note though, that 3G Lab have done some experimental work to provide protected address spaces for the Intel StrongARM SA1110, which can be found at http://www.3glab.org/.