This document outlines the major changes that have occured in TinyOS since the last release (1.0) and the current release (1.1). These changes include the replacement of net.tinyos.sf.SerialForward with net.tinyos.sf.SerialForwarder (along with major changes to how java programs send and receive packets, and an improved UART protocol), compile-time race condition detection in nesC, support for the mica2 platform and Chipcon radio, power management, AM-level cryptography for integrity and confidentiality (TinySec), network reprogrammming, ad-hoc routing, and support for new mote programmers in uisp. Systems packaged with 1.0, such as TinyDB and Maté, also have many advancements. As with the transition from 0.6 to 1.0, there are many small changes such as bug fixes. This document only describes these major changes which every user should be aware of.

Serial Communications

net.tinyos.sf.SerialForward has been replaced by net.tinyos.sf.SerialForwarder.The new SerialForwarder will normally be used with the GenericBase replacement, TOSBase (see the TinyOS section). The old serial forwarder is still available, at net.tinyos.sf.old.SerialForward. As part of this transition a new package, net.tinyos.packet, provides standardized access to many different packet sources, ranging from SerialForwarder to TOSSIM to a serial port. Packet sources are specified by string descriptions: running net.tinyos.packet.BuildSource provides a list of all of the available sources. The new framework provides the following advantages:

• The new UART protocol provides reliable PC-mote communication (and preserves the destination address of received packets...).
• The new protocols are packet-size independent, so you should no longer need to specify packet sizes in your java applications or in the serial forwarder.
• TOSBase sets the group id on outgoing messages, and filters incoming messages by group id. Thus most java programs do not need to know the group id (net.tinyos.packet, and net.tinyos.message when used with the new packet sources, do not check or set group ids).
  
• Java applications can more easily connect to a variety of packet sources (see the next paragraph).
  

Most programs (except SerialForwarder itself) read the MOTECOM environment variable to find which packet source they should use, and if MOTECOM is not defined will connect to a SerialForwarder on the local host.

In summary:

• You can still use the old GenericBase, along with net.tinyos.sf.old.SerialForward, and leave your current java code unchanged.
• You can switch to TOSBase (which provides reliable PC-mote communication), and change your java code to use the new packet sources. The necessary changes are extremely minor, especially if you were using mig and the net.tinyos.message package.
• GenericComm uses the new UART protocol, so if you were connecting your PC directly to your mote application (i.e., not using GenericBase), you will have to switch to the new packet sources on the PC side.

nesC now supports and checks the TinyOS concurrency model. It makes a distinction between asynchronous code, which can execute in interrupt context, and synchronous code, which can only execute in tasks. The boot sequence is considered a task (as it runs synchronously). Essentially, sync (synchronous) code is non-preemptive; it runs to completion with respect to other sync code. async code, however, can preempt itself and sync code.

This means that if a variable is read or written in async code, there is a possible race condition; it can preempt a concurrent access. Variables that can be modified by async code must be protected by atomic sections, which ensure atomic access. This is an example of a state transition that is safe, even in the presence of async code:

    bool oldBusy;
    atomic {
      oldBusy = busy;
      busy = TRUE;
    }
    if (!oldBusy) {
    ...
    

nesC wiring allows interfaces to "fan-out;" a single uses can be wired to more than one provides and vice-versa. A single call point calls multiple functions: this raises the question of what the return value of the call means.

In nesc 1.0, the return value from a fan-out was that of one of the functions, randomly determined at compile-time. nesC 1.1 introduces the idea of a "combine function," which is associated with a type. For example, the combine function for result_t returns FAIL if any of its values to combine are FAIL. If calling StdControl.init fails on one of the callees, the caller should see so.

Some types do not have combine functions; for example TOS_MsgPtr does not. Calling two functions, both of which return a pointer, has unclear semantics, and is almost certainly a bug. In the case of ReceiveMsg.receive(), for example, which of the two buffers should be used?

nesC 1.0 had a unique function, to use with parameterized interfaces. However, some parameterized interfaces had fixed ranges that were smaller than their parameterization suggested (e.g., TimerC had 16 timers, but a uint8_t parameterization); using more would fail, using fewer wasted storage. nesC 1.1 has a new function, uniqueCount, which is resolved at compile time. Like unique, it takes a string parameter. For example, uniqueCount("Timer") will return the number of calls to unique("Timer").

nesC 1.1 includes a new tool, ncg, or "nesC Constant Generator. ncg can take a .h file, read all of the constants defined, and generate a Java class that provides those constants. This means that constants no longer have to be replicated across TinyOS code and the associated Java tools.

A more in-depth description of these changes can be found in the nesC Reference Manual.

TinyOS

TinyOS 1.1 supports the mica2 and mica2dot platforms, including a Chipcon-based active message networking stack. It also supports the mica platform, with its RFM-based networking stack. It no longer support the rene platform.

The directory structure of TinyOS has been changed slightly; the lib subdirectory now only contains directories representing add-on systems.

TinyOS 1.1 provides a many-to-one collection oriented ad-hoc routing system, which has been tested and evaluated both in controlled and deployment conditions (e.g., Great Duck Island). The routing system is in lib/Route.

TinyOS 1.1 includes support for single-hop binary reprogramming over the network. This system, Xnp, was developed by Crossbow and refined by the TinyOS team. Xnp is in lib/Xnp. There are several example applications that use it: XnpCount, XnpOscopeRF and XnpRfmToLeds. The Java tools are in net.tinyos.xnp.

TinyOS 1.1 has mechanisms for run-time power management.

GenericBase has been replaced by TOSBase. TOSBase provides the same functionality as GenericBase, but uses an improved serial communication protocol. GenericBase had no framing besides message size, and therefore failed when bytes transmitted to it were lost. TOSBase uses a framing protocol. Correspondingly, old applications tha talk to a serial port may not communicate with TOSBase. Additionally, GenericBase filtered outgoing messages based on group ID; TOSBase instead sets the group ID of all packets sent out on the radio. This means that Java-side tools do not need to know the group ID used in the network. For special applications, the TransparentBase application behaves like TOSBase except that it does not set the group id on outgoing messages or filter incoming messages by group id (leaving these tasks to the Java tools).

TOSSIM has been extended and refined. Its command line syntax has changed slightly. It now supports a lossy networking model, and there is a Java tool to generate loss topologies based on empirical data gathered from a mica network. TOSSIM 1.1 does not simulate the mica2 networking stack, instead, continues to support the mica RFM stack. TOSSIM does not support the new non-volatile storage interfaces yet (described below).

TOSSIM now includes TinyViz, a Java application that can visualize and actuate running simulations. TinyViz has an extensible "plugin" interface, so users can write new visualization plugins and load them into the TinyViz infrastructure.

TinyOS 1.1 has improved support for accessing non-volatile flash memory, through the ByteEEPROM region-based and Matchbox file system based interfaces. Matchbox is in lib/FS. There is also support for high-frequency sampling; depending on the platform and other factors, 3-5kHz ADC sampling to the flash (for later retrieval) is possible. This is found in apps/HighFrequencySampling.

TinySec, a networking stack that includes cryptographic integrity and confidentiality, is included in lib/TinySec.

The ADC component (ADCM) now provides fair-share access to different ports. It handles outstanding requests in a round-robin fashion, preventing one high-frequency sampler from dominating all others. There is also an alternative ADC implementation, ADCRef, which produces values taken in reference to the system voltage (since ADC readings depend on this).

sendVarLenPacket has been removed from GenericComm. Since the UART now uses a framing protocol, this functionality is not longer feasible.

Using nesC's concurrency support, many TinyOS components have been modified or rewritten to remove race conditions. System services should be correspondingly more stable.

Tools

nesC now includes support for on-mote debugging using JTAG.

MessageCenter, developed by Vanderbilt, is now part of the standard TinyOS toolchain. MessageCenter has several subtools. One allows you to dynamically specify packet formats for reception and transmission. MessageInjector, a TinyOS 1.0 that loads all MIG generated message classes into a GUI for setting fields and transmitting, has been incorporated into MessageCenter. MessageCenter is in the Java package net.tinyos.mcenter.

The Chipcon radio has a wide range of available frequencies. The tool channelgen, given a desired frequency, provides the corresponding values to set the radio at.

The uisp tool now supports the new serial-based programming board (mib510) and ethernet-based reprogramming (EPRB). Additionally, the standard Makerules file can be told to invoke uisp with appropriate parameters for these various programming boards, as explained here.

Systems

TinyOS 1.1 includes updated versions of TinyDB and Maté as separate packages.

 The contrib package includes a number of  subsystems from other groups. See the README file in each subdirectory of contrib for more information.