Chapter 1. Overview

The eCos component architecture involves a number of key concepts.

The eCos component framework places a great deal of emphasis on configurability. The fundamental goal is to allow large parts of embedded applications to be constructed from re-usable software components, which does not a priori require that those components be highly configurable. However embedded application development often involves some serious constraints.

Many embedded applications have to work with very little memory, to keep down manufacturing costs. The final application image that will get blown into EPROM's or used to manufacture ROMs should contain only the code that is absolutely necessary for the application to work, and nothing else. If a few tens of kilobytes are added unnecessarily to a typical desktop application then this is regrettable, but is quite likely to go unnoticed. If an embedded application does not fit on the target hardware then the problem is much more serious. The component framework must allow users to configure the components so that any unnecessary functionality gets removed.

Many embedded applications need deterministic behavior so that they can meet real-time requirements. Such deterministic behavior can often be provided, but at a cost in terms of code size, slower algorithms, and so on. Other applications have no such real-time requirements, or only for a small part of the overall system, and the bulk of the system should not suffer any penalties. Again the component framework must allow the users control over the timing behavior of components.

Embedded systems tend to be difficult to debug. Even when it is possible to get information out of the target hardware by means other than flashing an LED, the more interesting debugging problems are likely to be timing-related and hence very hard to reproduce and track down. The re-usable components can provide debugging assistance in various ways. They can provide functionality that can be exploited by source level debuggers such as gdb, for example per-thread debugging information. They can also contain various assertions so that problems can be detected early on, tracing mechanisms to figure out what happened before the assertion failure, and so on. Of course all of these involve overheads, especially code size, and affect the timing. Allowing users to control which debugging features are enabled for any given application build is very desirable.

However, although it is desirable for re-usable components to provide appropriate configuration options this is not required. It is possible to produce a package which does not provide a single configuration option — although the user still gets to choose whether or not to use the package. In such cases it is still necessary to provide a minimal CDL script, but its main purpose would be to integrate the package with the component framework's build system.

The purpose of configurability is to control the behavior of components. A scheduler component may or may not support time slicing; it may or may not support multiple priorities; it may or may not perform error checking on arguments passed to the scheduler routines. In the context of a desktop application a button widget may contain some text or it may contain a picture; the text may be displayed in a variety of fonts; the foreground and background color may vary. When an application uses a component there must be some way of specifying the desired behavior. The component writer has no way of knowing in advance exactly how a particular component will end up being used.

One way to control the behavior is at run time. The application creates an instance of a button object, and then instructs this object to display either text or a picture. No special effort by the application developer is required, since a button can always support all desired behavior. There is of course a major disadvantage in terms of the size of the final application image: the code that gets linked with the application has to provide support for all possible behavior, even if the application does not require it.

Another approach is to control the behavior at link-time, typically by using inheritance in an object-oriented language. The button library provides an abstract base class Button and derived classes TextButton and PictureButton. If an application only uses text buttons then it will only create objects of type TextButton, and the code for the PictureButton class does not get used. In many cases this approach works rather well and reduces the final image size, but there are limitations. The main one is that you can only have so many derived classes before the system gets unmanageable: a derived class TextButtonUsingABorderWidthOfOnePlusAWhiteBackgroundAndBlackForegroundAndATwelvePointTimesFontAndNoErrorCheckingOrAssertions is not particularly sensible as far as most application developers are concerned.

The eCos component framework allows the behavior of components to be controlled at an even earlier time: when the component source code gets compiled and turned into a library. The button component could provide options, for example an option that only text buttons need to be supported. The component gets built and becomes part of a library intended specifically for the application, and the library will contain only the code that is required by this application and nothing else. A different application with different requirements would need its own version of the library, configured separately.

In theory compile-time configurability should give the best possible results in terms of code size, because it allows code to be controlled at the individual statement level rather than at the function or object level. Consider an example more closely related to embedded systems, a package to support multi-threading. A standard routine within such a package allows applications to kill threads asynchronously: the POSIX routine for this is pthread_cancel; the equivalent routine in µITRON is ter_tsk. These routines themselves tend to involve a significant amount of code, but that is not the real problem: other parts of the system require extra code and data for the kill routine to be able to function correctly. For example if a thread is blocked while waiting on a mutex and is killed off by another thread then the kill operation may have to do two things: remove the thread from the mutex's queue of waiting threads; and undo the effects, if any, of priority inheritance. The implementation requires extra fields in the thread data structure so that the kill routine knows about the thread's current state, and extra code in the mutex routines to fill in and clear these extra fields correctly.

Most embedded applications do not require the ability to kill off a thread asynchronously, and hence the kill routine will not get linked into the final application image. Without compile-time configurability this would still mean that the mutex code and similar parts of the system contain code and data that serve no useful purpose in this application. The eCos approach allows the user to select that the thread kill functionality is not required, and all the components can adapt to this at compile-time. For example the code in the mutex lock routine contains statements to support the killing of threads, but these statements will only get compiled in if that functionality is required. The overall result is that the final application image contains only the code and data that is really needed for the application to work, and nothing else.

Of course there are complications. To return to the button example, the application code might only use text buttons directly, but it might also use some higher-level widget such as a file selector and this file selector might require buttons with pictures. Therefore the button code must still be compiled to support pictures as well as text. The configuration tools must be aware of the dependencies between components and ensure that the internal constraints are met, as well as the external requirements of the application code. An area of particular concern is conflicting requirements: a button component might be written in such a way that it can only support either text buttons or picture buttons, but not both in one application; this would represent a weakness in the component itself rather than in the component framework as a whole.

Compile-time configurability is not intended to replace the other approaches but rather to complement them. There will be times when run-time selection of behavior is desirable: for example an application may need to be able to change the baud rate of a serial line, and the system must then provide a way of doing this at run-time. There will also be times when link-time selection is desirable: for example a C library might provide two different random number routines rand and lrand48; these do not affect other code so there is no good reason for the C library component not to provide both of these, and allow the application code to use none, one, or both of them as appropriate; any unused functions will just get eliminated at link-time. Compile-time selection of behavior is another option, and it can be the most powerful one of the three and the best suited to embedded systems development.

Components can support configurability in varying degrees. It is not necessary to have any configuration options at all, and the only user choice is whether or not to load a particular package. Alternatively it is possible to implement highly-configurable code. As an example consider a typical facility that is provided by many real-time kernels, mutex locks. The possible configuration options include:

Altogether there may be something like ten to twenty configuration options that are specific to the mutex code. There may be a similar number of additional options related to assertions and other debug facilities. All of the options should have sensible default values, possibly fixed, possibly calculated depending on what is happening elsewhere in the configuration. For example the default setting for an assertion option should generally inherit from a kernel-wide assertion control option, which in turn inherits from a global option. This allows users to enable or disable assertions globally or at a more fine-grained level, as desired.

Different components may be configurable to different degrees, ranging from no options at all to the fine-grained configurability of the above mutex example (or possibly even further). It is up to component writers to decide what options should be provided and how best to serve the needs of application developers who want to use that component.

Large parts of eCos were developed concurrently with the development of the configuration technology, or in some cases before design work on that technology was complete. As a consequence the various eCos packages often make only limited use of the available functionality. This situation is expected to change over time. It does mean that many of the descriptions in this guide will not correspond exactly to how the eCos packages work right now, but rather to how they could work. Some of the more extreme discrepancies such as the location of on-line documentation in the component repository will be mentioned in the appropriate places in the guide.

A consequence of this is that developers of new components can look at existing CDL scripts for examples, and discover discrepancies between what is recommended in this guide and what actually happens at present. In such cases this guide should be treated as authoritative.

It is also worth noting that the current component framework is not finished. Various parts of this guide will refer to possible changes and enhancements in future versions. Examining the source code of the configuration tools may reveal hints about other likely developments, and there are many more possible enhancements which only exist at a conceptual level right now.