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:

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?

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.