RTEMS Porting Guide
Since there are a wide variety of embedded systems, there are a wide variety of processors targeting embedded systems. RTEMS alleviates some of the burden on the embedded systems programmer by providing a consistent, high-performance environment regardless of the target processor. RTEMS has been ported to a variety of microprocessor families including:
In addition, there is a port of RTEMS to UNIX that uses standard UNIX services to simulate the embedded environment.
Each RTEMS port supplies a well-defined set of services that are the foundation for the highly portable RTEMS and POSIX API implementations. When porting to a new processor family, one must provide the processor dependent implementation of these services. This set of processor dependent core services includes software to perform interrupt dispatching, context switches, and manipulate task register sets.
The RTEMS approach to handling varying processor models reflects the approach taken by the designers of the processors themselves. In each processor family, there is a core architecture that must be implemented on all processor models within the family to provide any level of compatibility. Many of the modern RISC architectures refer to this as the Architectural Definition. The Architectural Definition is intended to be independent of any particular implementation. Additionally, there is a feature set which is allowed to vary in a defined way amongst the processor models. These feature sets may be defined as Optional in the Architectural Definition, be left as implementation defined characteristics, or be processor model specific extensions. Support for floating point, virtual memory, and low power mode are common Optional features included in an Architectural Definition.
The processor family dependent software in RTEMS includes a definition of which features are present in each supported processor model. This often makes adding support for a new processor model within a supported family as simple as determining which features are present in the new processor implementation. If the new processor model varies in a way previously unaccounted for, then this must be addressed. This could be the result of a new Optional feature set being added to the Architectural Definition. Alternatively, this particular processor model could have a new and different implementation of a feature left as undefined in the Architectural Definition. This would require software to be written to utilize that feature.
There is a relatively small set of features that may vary in a processor family. As the number of processor models in the family grow, the addition of each new model only requires adding an entry for the new model to the single feature table. It does not require searching for every conditional based on processor model and adding the new model in the appropriate place. This significantly eases the burden of adding a new processor model as it centralizes and logically simplifies the process.
RTEMS Porting Guide
Copyright © 1988-2004 OAR Corporation