| Author: | Philip Levis |
|---|---|
| Date: | -Feb 8 2006 | Oct 30 2006 |
Note
This document gives a brief overview of TinyOS 2.0, highlighting how and where it departs from 1.1 and 1.0. Further detail on these changes is detailed in TEP (TinyOS Enhancement Proposal) documents.
TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS. Its development was motivated by our belief that many aspects of 1.x strain to meet requirements and uses that were not foreseen @@ -323,8 +323,8 @@ the scheduler, booting and initialization. Further detail on each of these can be found in TEPs (TinyOS Enhancement Proposals), which document and describe these abstractions.
Platforms exist in the tos/platforms subdirectory. In TinyOS 2.0, a platform is a collection of chips and some glue code that connects them together. For example, the mica2 platform is the CC1000 radio @@ -361,7 +361,7 @@ use and safely compile on multiple platforms. For example, the HIL component of the CC1000 on the mica2 is ActiveMessageC, representing a full active message communication layer.
The HAA is described in TEP 2: Hardware Abstraction Architecture[TEP2].
-Currently (as of the 2.0 beta release at TTX3), TinyOS 2.0 supports +
Currently (as of the 2.0 release in November 2006), TinyOS 2.0 supports the following platforms:
+@@ -375,9 +375,10 @@ the following platforms:
- btnode3
The btnode3 platform is not included in the RPM.
As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO policy. However, tasks in 2.0 operate slightly differently than in 1.x.
@@ -405,8 +406,8 @@ however, or the scheduler will break all nesC's static concurrency analysis. Details on the new scheduler and how to extend it can be found in TEP 106: Schedulers and Tasks[TEP106].TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface StdControl has been split into two interfaces: Init and StdControl. The latter only has two commands: start and stop. @@ -419,13 +420,13 @@ handles this event and start services accordingly. Details on the new boot sequence can be found in TEP 107: TinyOS 2.x Boot Sequence[TEP107].
TinyOS 2.0 is written with nesC 1.2, which introduces the concept of a 'generic' or instantiable component. Generic modules allow TinyOS to have reusable data structures, such as bit vectors and queues, which simplify development. More importantly, generic -configurations allow services to encapsulate complex wiring +configurations allow services to encapsulate complex wiring relationships for clients that need them.
In practice, this means that many basic TinyOS services are now virtualized. Rather than wire to a component with a parameterized @@ -435,8 +436,8 @@ service component does all of the wiring underneath (e.g., in the case of timers, to a unique) automatically, reducing wiring mistakes and simplifying use of the abstraction.
TinyOS 2.0 provides a much richer set of timer interfaces than 1.x. Experience has shown that timers are one of the most critical abstractions a mote OS can provide, and so 2.0 expands the fidelity @@ -446,7 +447,7 @@ timers, and the timer system may provide one or two high-precision timers that fire asynchronously (they have the async keyword). Components can query their timers for how much time remainins before they fire, and can start timers in the future (e.g., -'start firing a timer at 1Hz starting 31ms from now'). TEP 102: +'start firing a timer at 1Hz starting 31ms from now'). TEP 102: Timers[TEP102] defines what HIL components a platform must provide in order to support standard TinyOS timers. Platforms are required to provide millisecond granularity timers, and can provide @@ -463,8 +464,8 @@ components App, new TimerMilliC(); App.Timer -> TimerMilliC;
In TinyOS 2.0, the message buffer type is message_t, and it is a buffer that is large enough to hold a packet from any of a node's communication interfaces. The structure itself is completely opaque: @@ -485,8 +486,8 @@ active message layer as ActiveMessageC.
communication. Instead, a component should wire to SerialActiveMessageC, which provides active message communication over the serial port. -Active message communication is virtualized through four generic -components, which take the AM type as a parameter: AMSenderC, +
Active message communication is virtualized through four generic +components, which take the AM type as a parameter: AMSenderC, AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is virtualized in that the call to send() does not fail if some other component is sending (as it does with GenericComm in 1.x). Instead, @@ -494,9 +495,9 @@ it fails only if that particular AMSenderC already has a packet outstanding or if the radio is not in a sending state. Underneath, the active message system queues and sends these outstanding packets. This is different than the QueuedSendC approach of 1.x, in which there -is an N-deep queue that is shared among all senders. With N AMSenderC +is an N-deep queue that is shared among all senders. With N AMSenderC components, there is an N-deep queue where each sender has a single -reserved entry. This means that each AMSenderC receives +reserved entry. This means that each AMSenderC receives 1/n of the available post-MAC transmission opportunities, where n is the number of AMSenderC components with outstanding packets. In the worst case, n is the number of components; even when every @@ -504,10 +505,13 @@ protocol and component that sends packets is trying to send a packet, each one will receive its fair share of transmission opportunities.
Further information on message_t can be found in TEP 111: message_t[TEP111], while further information on AM can be -found in TEP 116: Packet Protocoks[TEP116].
+found in TEP 116: Packet Protocols[TEP116]. +The current TinyOS release has a low-power stack for the CC1000 +radio (mica2 platform) and an experimental low-power stack for +the CC2420 radio (micaz, telosb, and intelmote2 platforms).
In TinyOS 2.0, named sensor components comprise the HIL of a platform's sensors. TEP 114 describes a set of HIL data acquisition interfaces, such as Read, ReadStream, and Get, which sensors @@ -525,8 +529,8 @@ the organization of sensor boards can be found in TEP 109: Sensorboards[TEP109], and the details of the HIL sensor interfaces can be found in TEP 114: Source and Sink Independent Drivers[TEP114].
The standard TinyOS 1.x return code is result_t, whose value is either SUCCESS (a non-zero value) or FAIL (a zero value). While this makes conditionals on calls very easy to write (e.g., if (call @@ -538,7 +542,7 @@ commands and events define which error codes they may return and why.
different in 2.0. Calls that were once:
if (call X.y()) {
- busy = TRUE;
+ busy = TRUE;
}
now have their meanings reversed. In 1.x, the busy statement will execute @@ -550,47 +554,60 @@ if (call X.y() == SUCCESS) { }
While basic abstractions, such as packet communication and timers, -can be virtualized, experiences with 1.x showed that some cannot +can be virtualized, experiences with 1.x showed that some cannot without either adding significant complexity or limiting the system. The most pressing example of this is a shared bus on a microcontroller. Many different systems -- sensors, storage, the radio -- might need to use the bus at the same time, so some way of arbitrating access is needed.
-To support these kinds of abstractions, TinyOS 2.0 introduces +
To support these kinds of abstractions, TinyOS 2.0 introduces the Resource interface, which components use to request and -acquire shared resources, and arbiters, which provide a policy for +acquire shared resources, and arbiters, which provide a policy for arbitrating access between multiple clients. For some abstractions, the arbiter also provides a power management policy, as it can tell when the system is no longer needed and can be safely turned off.
TEP 108: Resource Arbitration[TEP108] describes the Resource interface and how arbiters work.
Power management in 2.0 is divided into two parts: the power state of the microcontroller and the power state of devices. The former, discussed in TEP 112: Microcontroller Power Management[TEP112], -is computed in a chip-specific manner by examining which devices +is computed in a chip-specific manner by examining which devices and interrupt souces are active. The latter, discussed in TEP 115: Power Management of Non-Virtualised Devices{TEP115], is handled through resource abiters. Fully virtualized services have their own, individual power management policies.
+TinyOS 2.0 provides low-power stacks for the CC1000 (mica2) +and CC2420 (micaz, telosb, imote2) radios. Both use a low-power +listening apporach, where transmitters send long preambles or +repeatedly send packets and receivers wake up periodically to +sense the channel to hear if there is a packet being +transmitted. The low-power stack CC1000 is standard, while +the CC2420 stack is experimental. That is, the default CC1000 +stack (chips/cc1000) has low-power-listening, while the default +CC2420 stack (chips/cc2420) does not. To use the low-power CC2420 +stack, you must include chips/cc2420_lpl in your application Makefile.
TinyOS 2.0 provides simple reference implementations of two of +
TinyOS 2.0 provides simple reference implementations of two of the most basic protocols used in mote networks: dissemination -and collection. Dissemination reliably delivers small (fewer +and collection. Dissemination reliably delivers small (fewer than 20 byte) data items to every node in a network, while collection builds a routing tree rooted at a sink node. Together, these two protocols enable a wide range of data collection -applications.
+applications. Collection has advanced significantly since the +most recent beta release; experimental tests in multiple +network conditions have seen very high (>98%) deliver rates +as long as the network is not saturated.TinyOS 2.0 represents the next step of TinyOS development. Building on user experiences over the past few years, it has taken the basic TinyOS architecture and pushed it forward in several directions, @@ -599,19 +616,19 @@ still under active development: future prereleases will include non-volatile storage, basic multihop protocols (collection routing, dissemination), and further power management abstractions.
TinyOS 2.0 is the result of a lot of hard work from a lot of people, -including (but not limited to) David Gay, Philip Levis, Cory Sharp, -Vlado Handziski, Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui, -Prabal Dutta, -Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler, -Kristin Wright, Ion Yannopoulos, Henri Dubois-Ferriere, Jan Beutel, +including (but not limited to) David Gay, Philip Levis, Cory Sharp, +Vlado Handziski, Jan Hauer, Kevin Klues, Joe Polastre, Jonathan Hui, +Prabal Dutta, +Gilman Tolle, Martin Turon, Phil Buonodonna, Ben Greenstein, David Culler, +Kristin Wright, Ion Yannopoulos, Henri Dubois-Ferriere, Jan Beutel, Robert Szewczyk, Rodrigo Fonseca, Kyle Jamieson, Omprakash Gnawali, -and Kristin Wright.
+David Moss, and Kristin Wright.