eCos - Embedded Cygnus Operating System

1.2 Requirements

The requirements defined in this section are being used to drive the design of eCos and future enhancements.

1.2.1 Infrastructure
As mentioned earlier, one of the primary goals of eCos is to create a standardized mechanism to extend its functionality. Cygnus wants to provide the means to create and support an open marketplace for embedded software components. The infrastructure provides the necessary assistance and support to write components that are portable between architectures, platforms and devices. It is important to provide as wide a marketplace, and scope of potential applications, as possible for all components built for eCos. The key objective of the infrastructure is to help reduce the time to market for embedded products. This is achieved by helping to simplify and expedite the process of application development. The availability of a wide variety of "off-the-shelf" embedded components is a prerequisite for this. Users select the components that satisfy their applications' basic needs and then configure them to match specific implementation requirements. Configurations supported are capable of ranging between the architectural and C initialization code, and the user's embedded application at the low end, to high end configurations such as an embedded Internet application, complete with file system, Ethernet, TCP/IP, Java(tm) and Web server support. Not only should the users be able to select the particular components they want, but they should also be able to configure those components to their applications' requirements. This could mean enabling or disabling particular features within a component, or choosing between different implementations of the same component. An example of this is a memory allocator. In terms of features, the user may wish to enable support for detection of writes past allocated boundaries. In terms of implementations, the user may require one that is fast, and may not care if it is non-deterministic and/or wasteful of memory, or one that has a low memory overhead but is slow(er), and non-deterministic, and so on. Generic features and functionality are selectable on a global or per-component basis. This includes features such as instrumentation and debug level. To achieve this, eCos supports micro-configuration of the components. This enables functionality, resource requirement, and performance trade-offs. Most importantly, it supports the concept of including only the specific functionality required by the embedded application. Any code and data that is superfluous to this goal does not exist in an application's final image.

Users are provided with the ability to add components and to modify existing components to their exact requirements. This enables organizations to use the configuration functionality to build their own internal bases of reusable components, and to access the raw code of the components. This lets them modify those components to meet their exact requirements. Some third parties may not allow modification to code, but all Cygnus components provide this feature. The delivery and packaging of the components support both physical media and Internet distribution. The infrastructure will support source and/or object code versions of the components. Object code-only versions may severely reduce the configurability and portability of the component. Tools that simplify the task of using the components to create an embedded system application are provided. Specific functionality the tools support include:

• A simple user interface that aids the process of component selection and configuration
• The installation of additional components
• Reduced effort required in specifying every aspect of the system's configuration
• The provision for automatic inclusion and exclusion of components via dependencies on components and configurations that the user is interactively setting. Rigorous checks on the consistency and validity of the intra- and inter-component dependencies. Default options and available options in some components may change due to other components and options within them being selected.
• Users should have various ways of viewing their configurations, including inter-component dependencies and potentially image size.
• Methods for organizations to standardize the base system configuration available to their application developers, limiting the types and varieties of configuration options available to them.
• Analysis of application code component requirements and dependencies, for both automatic configuration and verification of the correct usage of previously configured functionality
• Static initialization of system data, so that code to support dynamic allocation and initialization can be dispensed within the system image
• Production of not only a configured system, but also the associated test code, and hyperlinks to the documentation configured to the same specification
• Tools that simplify and aid the construction of components by third parties and users
• Comprehensive documentation and online help
• All information, interfaces, component descriptions, and packaging formats necessary for third parties and users to produce packaged components will be standardized and published by Cygnus.

1.2.2 Component and General Embedded System Requirements
The design and implementation of all embedded software components developed by Cygnus will focus on fulfilling the requirements of the embedded marketplace. These requirements include:

• Low cost
• Reduced resource requirements
• Low overhead
• Real-time response
• Power management support
• Reduced development time
• Connectivity
• Reliability

The market and technology are constantly pushing embedded systems in the direction of smaller, faster, cheaper, and more sophisticated implementations; and in many scenarios these systems are now expected to run off batteries and offer some level of communications connectivity. Moreover, embedded systems are deployed in highly competitive markets, where time to market can be of the utmost importance to the success of the product. These factors can be converted into a number of general requirements for all eCos components developed by Cygnus and third parties.

Low cost. Costs are reduced by not only making the development software free, but also by royalty-free deployment of the resulting embedded system. Additionally, shortened development cycles due to better development tools reduce costs. For high-volume embedded systems, the predominant cost is that of the hardware. It is important that the system software and configuration tools do everything possible to reduce hardware resource requirements.

Reduced resource requirements. A smaller footprint enables the costs of memory to be reduced, and in some instances allow a more compact physical design and reduced power consumption. In some circumstances, this small footprint enables the complete application to fit into on-chip memory, without having to resort to additional external devices. The philosophy of eCos component implementation is to optimize code size for the small case, even if it is detrimental to the larger one. That is to say, minimal systems will not suffer from additional baggage necessary to support advanced features that are only necessary for the most complex and sophisticated systems. Providing as small a resource footprint as possible is one of the key requirements of eCos. There is always a trade-off between functionality and resource requirements. Existing systems provide rich feature sets, but with little ability to chose the exact subset of features users want to be present, or from a number of alternative implementations providing different semantics. All Cygnus-developed components will support configuration of their functionalities.

Low overhead. Being efficient in the use of processor cycles enables designers to specify less expensive hardware solutions, or achieve better performance for a given design. This objective also requires that eCos provide good analysis tools to aid engineers in optimizing their systems.

Real-time response. Confidence that real-time requirements can be met enables engineers to specify less expensive solutions. More importantly, if a system does not provide any guarantees, it will not be used in real-time systems.

Power management support. More systems are being used in portable, non-tethered contexts. We must pay attention in the design of the system to this requirement. This includes support for processor frequency gearing, processor stand-by, device low-power modes and power failure.

Reduced development time. Providing a highly portable and configurable system with a range of pre-built components helps reduce both the development costs and time to market. The ease with which the system can be debugged is a key area where eCos and the Cygnus toolchain provides strong support.

Connectivity. The ability to communicate with, and network-enable, embedded devices is growing in importance. eCos enables a rich menu of communications options, both in terms of device drivers and protocol stacks. For example, TCP/IP and IrDA components would be ideal candidate components for eCos.

Reliability. Consumer products and other embedded products are expected by users to be error-free in operation. Developers need to rely that the third party software embedded with their applications is completely reliable. Strict quality and testing procedures are implemented with eCos.

1.2.3 Kernel
The design of the kernel components is directed toward providing maximum functionality and utility while minimizing the memory footprint. There is no such thing as a free lunch , but by paying close attention to memory usage, and assiduous use of the configuration functionality, eCos is able to provide exactly the functional content required with a minimal resource footprint. eCos is targeted at static systems. Dynamic run-time loading of code is not required by the vast majority of embedded systems. Although dynamic creation of certain objects such as threads and memory is a necessary optional feature, fully static implementation of these features is provided. This will enable us to dispense with creation and initialization interfaces and code. As there is no requirement for dynamic program loading, it should not be necessary to provide the concept of tasks. Threads alone are sufficient for the majority of embedded systems. It is envisioned that later generations of eCos will support the option of multiple applications and the dynamic loading of these applications. Eventually we will implement flash memory patching, system upgrades, and loading of interpreted code.

Initial implementations do not support virtual memory (VM) , although we may need to support VM features in future implementations. These features may include protection, device simulation, and code decompression. eCos will support combinations of code and data in Flash, ROM, RAM, on-chip memory, etc. Support for relocating code from ROM to RAM at run-time should also be provided. This is to support performance-sensitive code and flash memory write procedures. Development of multi-processor architecture support for Symmetric Multiprocessing (SMP) and distributed memory are not high on our list of requirements, and the initial kernel architecture does not support these features, but the system is designed so that SMP support can be easily added at a later stage in eCos evolution.

All the standard functionality expected in a real-time embedded operating system is catered for:, including interrupt handling, exception and fault handling, threads, synchronization, scheduling - with multiple policies, timers, and device drivers. These features are fully configurable, making a range of different features and alternative implementations possible. The core kernel component designs are influenced both by ease of use, and by the need for layering migration and compatibility layers such as ITRON and POSIX threads. Other components and libraries will add additional non-kernel-specific functionality that may traditionally be seen as kernel features. This includes features such as memory allocation and data structure access support. These libraries include an ISO standard C library and math library. The run-time characteristics of the kernel are fully real-time. In order to be classed as a real-time operating system, certain requirements must be met and certain timings must be made available to demonstrate these characteristics. eCos development focused on the following characteristics:

• Deterministic and low interrupt latency. The time taken for the system to respond to an interrupt and enter the ISR. Basically the maximum time for which the system disables interrupts.
• Deterministic and low dispatch latency. The time taken from the point a thread becomes ready to run to the point it begins executing, in a given scheduling environment.
• Deterministic and minimal memory footprint. For a given system configuration memory requirement for both code and data must be deterministic. All dynamic memory allocation is prohibited or at least configurable in core components. The memory requirements of a system must not vary. An embedded system must not run out of memory, either through lack of it, or fragmentation of the memory pool.
• Deterministic and timed core kernel primitives. Demonstrates the performance of the system and enables an estimation of execution time with which to determine if real-time constraints can be met. These timings will be published for all architectures that we support. The timings are essential for a developer to determine if his or her application can meet its real-time requirements on a given hardware implementation.

The HAL supports architectural portability of itself and the rest of the infrastructure. Where possible, it isolates architectural-dependent features, and presents them in an abstract form to enable the other infrastructure components to be completely portable. The HAL allows an application to directly access hardware and architectural features. It does not assume that it is in sole control of all aspects of the system. Platform ports have an emphasis placed on ease of porting since our users will be doing these ports themselves. The HAL is isolated from the rest of the kernel. Kernel components are built with ease of debugging in mind. All major functionality provides optionally-configured instrumentation. Instrumentation provides ways of writing event records in an area of memory set aside for this purpose. The event records include information such as a time stamp, record type, and optional supporting data. The records can be downloaded by a host-based tool for analysis and display. This serves several purposes:

• It aids our own kernel debugging
• It aids the users in visualizing and debugging their embedded systems
• It enables analysis of time-critical kernel primitives and events for performance characterization and performance regression testing.

1.2.4 Device Drivers
The key objective of device drivers is to isolate higher level components from dependence on specific device implementations. Device drivers abstract an interface that covers the range of possible chip implementations for a particular device type. The only globally common interface functions are likely to be initialization, self test, and possibly power saving modes. Since there is no intention to provide support for dynamic loading of device drivers (or any other code), all drivers are statically linked. For this reason there is no need to provide traditional IOCTL-like interfaces. Instead each device type's API can be designed to support operations and features specific to that type of device. The device driver design focuses on efficiency and does not introduce unnecessary layering or complexity. The device driver architecture and API must support multiple devices of the same type being present in the system, possibly with multiple device drivers present to handle this requirement. The support for this should not cause overhead in systems that do not require multiple devices of that type to be present. Bus type devices must support other devices being layered on top of them.

1.2.5 Testing
Developing a demonstrably robust system is essential if eCos is to be accepted by the embedded marketplace, and to compete with existing mature and acknowledged reliable systems. The only way to create reliability is through good architectural design and thorough testing. In this environment, testing is not an option. It is mandatory. There is a range of different classes of testing included in the eCos testing framework:

• Module testing (tests of particular portions of functionality within a component)
• Component testing (whole component testing)
• System test suites (combination/integration testing)
• Regression tests (bug reports converted to test cases)
• Stress/torture testing (loading the system beyond its intended normal limits)
• Performance tests (processor overhead and test execution time)
• Memory footprint tests (tracking the resource requirements of the system binaries)
• Real-time performance testing (characterizing the real-time performance of specific implementations)

Tests are not just to ensure that the system is reliable and works to specification. They also show that we have not negatively impacted the performance, real-time characterization, or resource footprint of the system. In addition to the results of the test -- pass, fail or indeterminate -- data such as the execution time and code size of the test binary will be recorded. This will enable us to track and flag major and creeping changes that increase the system overhead and memory footprint. Cygnus has developed a test framework that includes full automation as well as the ability to select and run individual test cases. The automated testing is run constantly, running through specified permutations of configurations and targets for each test case. The test cases are built using the latest set of sources that have been checked in. All results can be logged in a test results database. Failed or aberrant test case results cause an error log entry and e-mail to be generated, describing and pinpointing the failure. These test cases are configurable in an analogous way to the component they are written to test. Each explicitly-configurable feature has its own test case. The level of complexity due to the number of components will rapidly overtake any test system's ability to fully test all combinations of components and component options, on all supported architectures, and on all target platforms. For this reason, a standard subset of the most popular configurations will be chosen and tested thoroughly. In addition, some form of random combination testing is also provided. Each test case specifies the configuration and targets that it is compatible with and written for.

A minimal test infrastructure is shipped as part of eCos. When engineers configure their systems, they are not only building an application with a given set of configuration options. They are also building a test suite using the same configuration that includes all the tests for the chosen components and their options. The tests are configured in an analogous way to the application. In this way the exact configuration selected by the user is tested, providing a reasonable level of test coverage specific to the configuration. We will offer the automated test infrastructure to eCos customers in the future, but are currently only using it for our own testing of eCos.