The sensor OS is based on Redhat eCos, an open-source, real-time operating system for embedded applications . It meets the requirements of the embedded space that Linux cannot yet reach. Linux currently scales from a minimal size of around 500 KB of kernel and 1.5 MB of RAM, all before taking into consideration application and service requirements. eCos can provide the basic runtime infrastructure necessary to support devices with memory footprints in the tens to hundreds of KB, with real-time options.
The original eCos OS is designed to be completely scalable across platforms as well as within a given platform. Essentially, source level configuration allows the user to add or remove packages from a source repository based on system requirements. For example, the user might choose to remove math libraries and the resulting kernel will be leaner. The core eCos system consists of a number of different components, such as the kernel, the C library, an infrastructure package, etc. Each of these provides a large number of configuration options, allowing application developers to build a system that matches the requirements of their particular applications.
To manage the potential complexity of multiple components and lots of configuration options, eCos has a component framework: a collection of tools specifically designed to support configuring multiple components. Furthermore, this framework is extensible, allowing additional components to be added to the system at any time. The eCos component description language (CDL) lets the configuration tools check for consistency in a given configuration and point out any dependencies that have not been satisfied.
At the core of the eCos kernel is the scheduler. This defines the way in which threads are run, and provides the mechanisms by which they may synchronize. It also controls the means by which interrupts affect thread execution. To allow threads to cooperate and compete for resources, it is necessary to provide mechanisms for synchronization and communication. The classic synchronization mechanisms are mutexes/condition variables and semaphores. These are provided in the eCos kernel, together with other synchronization/communication mechanisms that are common in real-time systems, such as event flags and message queues.
The kernel also provides exception handling. An exception is a synchronous event caused by the execution of a thread. These include the machine exceptions raised by hardware (such as divide-by-zero, memory fault, and illegal instruction) and machine exceptions raised by software (such as deadline overrun). The simplest, and most flexible, mechanism for exception handling is to call a function. This function needs context in which to work, so access to some working data is required. The function may also need to be handed some data about the exception raised — at least the exception number and some optional parameters. As opposed to exceptions, which are synchronous in nature, interrupts are asynchronous events caused by external devices. They may occur at any time and are not associated in any way with the currently running thread and are harder to deal with. The ways in which interrupt vectors are named, how interrupts are delivered to the software, and how interrupts are masked are all highly hardware specific. On the SA-1110, two kinds of interrupts are supported: fast interrupts (FIQ) and regular interrupts (IRQ); both can be masked.
TABLE 27.5 Typical Power Management Functions
UAMPS_ENABLE_DVS(), UAMPS_SET_VOLTAGE(), DVS UAMPS_SET_PROC_CLOCK(), UAMPS_CHECK_VCORE_STABLE(), UAMPS_SET_PROC_CLOCK(), uamps_set_proc_rate(), uamps_dvs_scheduler()
UAMPS_PERIPHERAL_POWER_ON(), UAMPS_PERIPHERAL_POWER_OFF(), UAMPS_V3_STANDBY_ON(), UAMPS_V3_STANDBY_OFF(), Shutdown SA11X0_PWR_MGR_WAKEUP_ENABLE, SA11X0_PWR_MGR_GENERAL_CONFIG, SA11X0_PWR_MGR_CONTROL, uamps_set_proc_idle(), uamps_set_proc_sleep(), uamps_goto_sleep_state()
The kernel also provides a rich set of timing utilities such as counter, clocks, alarms, and timers. The counter objects provided by the kernel provide an abstraction of the clock facility that is generally provided. Application code can associate alarms with counters, where an alarm is identified by the number of ticks until it triggers, the action to be taken on triggering, and whether the alarm should be repeated. Clocks are counters associated with a stream of ticks that represent time periods. Clocks have a resolution associated with them, whereas counters do not.
Was this article helpful?