Eric Brewer, UC Berkeley
David Culler, UC Berkeley
David Gay, Intel Research
Phil Levis, UC Berkeley
Rob von Behren, UC Berkeley
Matt Welsh, Harvard University
nesC (pronounced "NES-see") is an extension to the C programming
language designed to embody the structuring concepts and
execution model of TinyOS.
TinyOS is an event-driven operating system designed for sensor network
nodes that have very limited resources (e.g., 8K bytes of program memory,
512 bytes of RAM).
The basic concepts behind nesC are:
- Separation of construction and composition: programs are built out of
components, which are assembled ("wired") to form whole
programs. Components have internal concurrency in the form of
tasks. Threads of control may pass into a component through its
interfaces. These threads are rooted either in a task or a hardware
interrupt.
- Specification of component behaviour in terms of set of
interfaces. Interfaces may be provided or used by
components. The provided interfaces are intended to represent the
functionality that the component provides to its user, the used interfaces
represent the functionality the component needs to perform its job.
- Interfaces are bidirectional: they specify a set of functions to be
implemented by the interface's provider (commands) and a set to be
implemented by the interface's user (events). This allows a single
interface to represent a complex interaction between components (e.g.,
registration of interest in some event, followed by a callback when
that event happens). This is critical because all lengthy commands in
TinyOS (e.g. send packet) are non-blocking; their completion is
signaled through an event (send done). By specifying interfaces, a
component cannot call the send command unless it provides an
implementation of the sendDone event.
Typically commands call downwards, i.e., from application components to
those closer to the hardware, while events call upwards. Certain primitive
events are bound to hardware interrupts.
- Components are statically linked to each other via their interfaces.
This increases runtime efficiency, encourages rubust design, and allows for
better static analysis of programs.
- nesC is designed under the expectation that code will be generated
by whole-program compilers. This should also allow for better code
generation and analysis.
The image below shows the structure (components and their wiring) of a
simple application, Blink, that blinks an LED once a second:
The sourcecode for Blink is in two parts, the wiring in Blink and the actual application logic (C code) in BlinkM.
- 1.0: Initial nesC release.
- 1.1: Concurrency support:
async declarations,
atomic statements, compile-time data-race detection, uniqueCount.
- 1.1.1: Better support for new platforms.
- 1.1.2: Maintenance release (minor features, bug fixes).
- 1.1.3: Network Types: platform-independent
networking support.
For more details, see the ChangeLog.
An implementation of nesC (including source code) is available on Sourceforge.
- The nesC Language: A Holistic Approach to Networked Embedded
Systems, David Gay, Phil Levis, Rob von Behren, Matt Welsh,
Eric Brewer, and David Culler. In Proceedings of
Programming Language Design and Implementation (PLDI) 2003,
June 2003.
(PDF)
- nesC v1.1 Language Reference (PDF)
nesC: A Programming Language for Deeply Networked Systems