FAQ

General

What is TinyOS?

TinyOS is an open-source operating system designed for low-power wireless devices, such a sensor networks, ubiquitous computing, personal area networks, smart buildings and smart meters. TinyOS provides useful software abstractions of the underlying device hardware: for example, TinyOS can present a flash storage chip, which has blocks and sectors with certain erase/write properties, as a simple abstraction of a circular log. Providing useful, well-designed and heavily tested software abstractions greatly simplifies the job of application and system developers.

Where is it useful?

TinyOS is especially useful for microcontroller-based devices that have sensors and/or networking capabilities. It's been designed for very reasource-constrained devices, such as microcontrollers with a few kB of RAM and a few tens of kB of code space. It's also been designed for devices that need to be very low power.

How is TinyOS different than Arduino?

At a high level, Arduino is lighter weight than TinyOS: Arduino is some simple C support for microcontrollers and sensors, while TinyOS is a full fledged operating system that's been in development for a decade. The learning curves reflect this: it's easier to get up and started with Arduino and easier to write a simple sensing application. In the long term and for more powerful applications, however, TinyOS's greater facilities, especially networking (e.g., multihop routing, reliable dissemination, time synchronization), pay off.

At a more technical level, there are three major differences between TinyOS and Arduino:

1) TinyOS and its APIs are designed for low-power operation; Arduino is not.

2) Arduino focuses on sensing, computation, and digital IO; TinyOS also supports these abstractions adding excellent support for wireless networking.

3) TinyOS is written in nesC, a C dialect designed for the OS, while Arduino is in C. While TinyOS programmers can write applications in C, the core OS is in nesC.

How is TinyOS code licensed?

All code in the main TinyOS tree is licensed under a New BSD license. Unlike the GPL, a New BSD license does not require you redistribute source code. It does have some restrictions, however, such as including copyright notices in documentation and not using the names of the developers to promote or endorse products.

As of 4/23/2011 (commit 5543, main SVN T2 repo), a license template can be found at licenses/bsd.txt.

What are its strengths?

TinyOS supports multiple microcontroller families and radio chips, so there is a significant body of existing code which you can start from. Because TinyOS has thousands of users and its existing design is over five years old, this code is highly robust and efficient. Furthermore, it has very few bugs.

TinyOS has especially strong support for low-power operation, including wireless networking. TinyOS link layers (single-hop communication) support low-power operation, and TinyOS multihop protocols use these features. Quickly writing an application for a multihop network that can last 6 months on a pair of AA batteries is quite easy. TinyOS also supports secure networking on some radio chips. Support for the CC2420, the leading 802.15.4/ZigBee radio chip, is especially detailed and strong.

TinyOS has extensive networking support, and this support includes technically excellent protocol designs which have become de facto standards, or in some cases, parts of Internet standards. This support has been in part due to TinyOS's use as a platform by many leading low-power wireless research groups, who have then released their code for general use and supported it well. In particular, TinyOS supports multihop, network-wide sub-millisecond time synchronization through the FTSP protocol, data collection to a designated root or gateway through the CTP protocol, reliable data dissemination to every node in a network through the Trickle algorithm, and installing new binaries over the wireless network using Deluge. Support for RPL, the forthcoming Internet standard for routing in low-power wireless networks, is currently underway: several of the RPL authors are TinyOS developers.

What are its weaknesses?

Historically, TinyOS had two major weaknesses: its programming model takes a little getting used to, and computationally-intensive applications can be difficult to write. These two weaknesses are tightly entwined.

Basically, because TinyOS is intended for devices with very little RAM, all of its APIs are split-phase, or non-blocking. When you tell TinyOS to send() a message, the send function returns almost immediately, well before the message is actually sent. At some point later, TinyOS calls a callback on your program, sendDone, telling it the send completed. Because nothing blocks, TinyOS expects no piece of code to run for a very long time: this is critical, because if a piece of code runs uninterrupted for a long time, other pieces of code (such as the sendDone event) can't run, and so the OS might be forced to drop packets, miss timeouts, etc. Many novice programmers are used to single-threaded programming, where all calls block: transitioning to this event-driven, non-blocking style can take a little while to learn. On the upside, however, there's a tremendous amount of supporting documentation to help, including books, tutorials, and huge amounts of example code.

Because TinyOS doesn't work well with long, uninterrupted pieces of code, CPU-intensive applications can cause problems. To play nice with TinyOS, you have to break a long computation into a number of small parts that can be executed one by one. E.g., rather than have a nested loop that iterates over a NxN array, break it into N separate computations that iterate over N cells.

Current version of TinyOS include a threads library to help with these cases. Essentially, you can write a threaded application on top of the rest of the OS: this threaded application has a blocking API, can include long loops, etc. Furthermore, this threading support allows you to write applications in C, rather than nesC, reducing the barrier to entry.

Who uses TinyOS?

TinyOS is used by thousands of developers worldwide: it averages about 100 downloads a day, or 35,000 a year (where each download is from a unique IP address). It is the standard OS used by low power wireless and sensor network researchers: motivation within these communities to make their results available as open source code for others to use is greatly responsible for TinyOS having cutting edge technologies. R&D labs, startup companies, and embedded wireless product lines also use TinyOS. Example commerial users include Motorola, Intel, Arch Rock, Crossbow, and the People Power Company.

I'm having trouble installing TinyOS or using it: where should I ask for help?

TinyOS has a mailing list for questions and requests for help. Note that this mailing list has been active for almost a decade now, with thousands of users. Chances are someone has already encountered the same problem as you, and you can find the answer in the archives: the main TinyOS site has a search tool:

http://www.tinyos.net/archives.html

If you can't find the answer in the archives, then you should consider sending a message to the tinyos-help mailing list. Try to give as much information as possible: "I cant install TinyOS pls help" won't get much a response, while detailed questions typically do. Be patient, and wait a few days for a response. As many of the core developers have other responsibilities and jobs, immediate responses are rare.

How do I learn more?

http://docs.tinyos.net is the central repository for TinyOS documentation. You can find high-level information (such as this FAQ) at http://www.tinyos.net.

Hardware and Software

What do I need to program TinyOS devices?

You can install the TinyOS programming environment on Linux, Mac OS X, and Windows machines. There are also virtual machines with pre-installed support you can download, which can be simpler than installing the environment on your own machine.

You'll also need TinyOS hardware devices, and possibly a programming board to connect them to your machine (usually a USB serial port).

What hardware does TinyOS support?

TinyOS supports a dozen or so different hardware platforms, each of which respresents a different combination of processor, radio, storage, and exposed IO pins. As of 2.1.1, TinyOS supports the telos family, micaZ, IRIS, mica2, the shimmer family, epic, mulle, tinynode, span, and iMote2.

For microcontrollers, TinyOS supports the Texas Instruments MSP430 family, Atmel's Atmega128, Atmega128L, and Atmega1281, and the Intel px27ax processor. There is work underway to support the Cortex M3.

For radio chips, TinyOS supports the Texas Instruments/ChipCon CC1000 and CC2420, the Infineon TDA5250, the Atmel RF212 and RF230, and the Semtech XE1205 radios. Outside the main tree, groups have added support for additional chips (such as the TI/ChipCon CC1100 and CC2500).

For flash chips, TinyOS supports two NOR devices: the Atmel AT45DB and the STMicroelectronics STM25P chip.

What networking facilities does it provide?

TinyOS has extensive networking support, and this support includes technically excellent protocol designs which have become de facto standards, or in some cases, parts of Internet standards. This support has been in part due to TinyOS's use as a platform by many leading low-power wireless research groups, who have then released their code for general use and supported it well. The TinyOS net2 Working Group is responsible for adding, improving, and maintaining TinyOS's network protocols.

TinyOS supports low duty cycle operation through low-power link layers. Rather than keep the radio always on, TinyOS turns the radio on periodically (e.g., every few hundred ms) to check if there is a packet to receive. This enables the network to appear "always on" yet support sub-1% duty cycles: the basic tradeoff is that communication has higher latency.

TinyOS supports multihop, network-wide sub-millisecond time synchronization through the Flooding Time Synchronization Protocol, developed by researchers at Vanderbilt University.

Data collection protocols build a self-organizing, self-repairing routing topology to data collection points known as "roots." Typically these roots are connected to a PC or other device, such that the data collected can be stored in a database for later use. Collection protocols send data in only one direction (towards a root): they do not support messages to arbitrary nodes in the network. TinyOS's standard collection protocol, the Collection Tree Protocol (CTP), is highly efficient and robust: it continues to deliver data even after large numbers of node failures and has emerged as the gold standard against which other routing protocols are measured.

Data dissemination protocols reliably deliver a piece of data to every node in a network. TinyOS supports three dissemination protocols: Drip, DIP, and DHV. These three protocols represent a gradual evolution towards more efficient algorithms. Generally speaking, applications should use DHV.

TinyOS includes support for reprogramming a multihop wireless network over the air with the Deluge protocol. A Deluge-enabled network supports having multiple binaries in the network at once: a command line tool can instruct the network to change programs. This operation takes a short while as the nodes reprogram themselves.

All of the above protocols are subjects of a long literature of research and publications, such that there is extensive information in how they work. They are all designed to work on top of low power link layers.

Finally, there is ongoing work to support the recent Internet standard, Routing Protocol for Lossy and low power networks (RPL), as well as IPv6 support for 802.15.4 (6lowpan).

What are the programming APIs like?

Because the core of TinyOS is completely non-blocking, operations that might take a long time are split-phase: they have completion callbacks. The first phase a command you can call to start the operation. The second phase is the callback to signal completion. Unlike most APIs, however, where the function is bound at compile-time and the callback is passed as a function pointer (or pointer to an object with a method), in nesC both directions are bound at compile-time. Programming APIs are made up of nesC interfaces, which connect software components. These interfaces specify calls in both directions, from component A to component B and from component B to A. There are interfaces for sending packets (send/sendDone), starting timers (start/fired), sampling sensors (read/readDone), and storage (write/writeDone).

Does TinyOS support threaded programming?

As of 2.1.0, TinyOS supports threaded programming through the TOSThreads library. You can write threaded programs in either C or nesC. There are threaded, blocking APIs for most basic functionality, such as communication, storage and sensing. TOSThreads code can be found in tos/lib/tosthreads, and there the TinyOS tutorials include a TOSThreads tutorial.

I am looking for code for protocol or system "X": how do I find it?

Generally, the best place to start is with the authors of the paper describing it. Even if they don't maintain an implementation, chances are they are aware of existing versions of it. Emailing tinyos-help isn't usually effective.

nesC Language

What is nesC?

nesC is a variant of the C language that adds additional features. Basic statements, like variable declaration, for loops, and assignments are just as in C. nesC adds a few concepts to aid programming:

• Components are like objects, in that they couple code with state, but unlike objects components only be instantiated at compile time.
• Interfaces are sets of functions that describe a role or service. One unique feature of interfaces is that they can be bidirectional: two components interact that interact through a single interface can each have functions they must provide and can call.
• A concurrency model based on TinyOS's concurrency model. nesC distinguishes code that is safe from interrupts (called 'async') and code that cannot run in interrupt context. The nesC compiler checks and enforces this restriction.

This wiki has numerous tutorials and online resources on programming nesC. You can also purchase a book.

Why does TinyOS use nesC?

TinyOS uses nesC rather than C because it provides linguistic support for the TinyOS execution and programming model. For example, rather than having C macros for programming constructs like tasks and events, which are bug prone, using nesC allows a full compiler to check their use. Furthermore, nesC can transform the underlying C code in ways that makes it much easier for the compiler to optimize. For example, because TinyOS programs often have many small functions, inlining functions can cut code size and execution time significantly; however, some compiler, such as gcc, only inline if the function has already been defined. The nesC compiler produces C code for an underlying C compiler that is formatted to maximize the degree of optimization.

How hard is nesC to learn?

nesC is a C dialect: all C constructions and syntax are legal. It simply adds a few more constructs, such as interfaces, components, and a concurrency model. These constructs, however, are at a high level in the program: they change how one structures and implements your code. For that reason, nesC is very easy to learn but a bit difficult to master. The TinyOS Programming Manual goes into a great deal of detail on nesC programming conventions, giving hints on things to do or avoid. A programmer who knows C is typically completely fluent in nesC after spending two weeks programming in it and reading the supporting documentation.

Organization

How do I contribute code if I'm not part of a working group?

Contribution instructions.