TinyOS
From Capsil Wiki
Unlike most other operating systems (such as eCos [1] or uC/Cos [2], TinyOS is based on an event-driven programming model instead of multithreading. TinyOS programs are composed into event handlers and tasks with run-to-completion-semantics. When an external event occurs, such as an incoming data packet or a sensor reading, TinyOS calls the appropriate event handler to handle the event. Event handlers can post tasks that are scheduled by the TinyOS kernel some time later. Both the TinyOS system and programs written for TinyOS are written in a special programming language called nesC (Network Embedded Systems C) which is an extension to the C programming language and optimised for the memory limitations of sensor networks. NesC is designed to detect race conditions between tasks and event handlers.
Contents |
Components
A typical TinyOS configuration contains five subsystems, sensors/actuators, communications, storage, timers, and processor/power management, with higher-level services built on this foundation. The open-source repository provides components for popular chips, including several microcontrollers, radios, Flash memories, ADCs, and sensors as well as configurations for several popular platforms. Carefully designed telescoping interfaces allow designers to select among hardware-specific and hardware-independent capabilities.
TinyOS 2.0 provides sensor drivers, which scale from low-rate, low-power sampling of environmental factors to high-rate, low-jitter sampling of vibration or acceleration. Drivers handle warm-up, acquisition, arbitration, and interface specifics. Since sensor selection is closely tied to the application and mechanical design, drivers must be easily configured and tested, rather than dynamically loaded after market. Communications and networking have driven the TinyOS design as available radios and microcontroller interfaces evolved. The communication subsystem has to meet real-time requirements and respond to asynchronous events while other devices and processes are serviced. Most recent platforms use IEEE 802.15.4 radios, such as the ChipCon CC2420 [1], with a packet-level interface. The TinyOS 2.0 radio component provides a uniform interface to the full capabilities of the radio chip. The link-level component provides rich media access control (MAC) capabilities, including channel activity detection, collision avoidance, data transfer, scheduling, and power management, allowing networking components to optimize for specific protocols. Several platforms use other radios, including those from Nordic, Infineon, and Freescale, and many provide wired links for gateways, serial-based peripherals, or federations of microcontrollers. The TinyOS community has developed networking layers targeted at different applications with different techniques for discovery, routing, power reduction, reliability, and congestion control. These networking layers provide higher-level communication services to embedded applications with a TinyOS programming interface.
Evolution
TinyOS 2.0 was released in 2006 was motivated by the need for greater platform flexibility, improved robustness and reliability, and a move towards service oriented application development. Since this time, the TinyOS community has added support for additional hardware platforms such as T-Node, IRIS, SHIMMER, BTnode rev3 and IMOTE2, and a host of new application level services. These enhancements have resulted in several minor releases (i.e. TinyOS 2.0.1, 2.0.2). The current release TinyOS 2.1 takes a step towards addressing the need for easier and more robust application development. According to www.tinyOS.net “TinyOS 2.1 introduces a number of significant enhancements to core TinyOS components and interfaces. The most notable features include a fully preemptable application-level threads library known as TOSThreads [2], and a runtime memory protection service called Safe TinyOS. The former aims to ease writing event-driven code while preserving the time-sensitive aspect of TinyOS. The latter aims to make applications more robust through memory safety check”.
Full information on the latest developments in the TinyOS world can be found at [3]. There is a long list of other embedded operating systems (i.e. non wireless sensor network types) and the selection of the appropriate one will depend on the application and the processor involved. Examples include; DSPnano RTOS Embedded Linux, Inferno (distributed OS, Bell Labs), LynxOS, uC/OS, eCos, MINIX 3, .NET Micro Framework, OS/RT, Windows XP Embedded and Windows CE.
References
- Back to BSN Operating Systems and Development Page
- Back to Body Sensor Networks Page
- Back to Main Page
