1. An Introduction to nesC
Vinay Kumar Singh
Dongseo University

2. Outline Introduction TinyOS concepts nesC concepts Example References
Conclusion.

7. TinyOS Execution Contexts
Hardware
Interrupts
events
commands
Tasks
Events generated by interrupts preempt tasks
Tasks do not preempt tasks
Both essential process state transitions

8. nesC
TinyOS was originally written in C, applications were combinations of .c, .comp, and .desc files.
TinyOS (components) have been reimplemented in nesC.
A new language for mote programming is currently being developed.
nesC is a temporary solution.

9. Quick Review: nesC
Pronounced “”NES-see”
Extension of C
Supports C syntax
Compiled into C
“designed to embody the structuring concepts and execution model of TinyOS”.

12. Vocabulary
Application – one or more components wired together to form an executable
Component – basic building blocks for nesC apps. Two types: modules and configurations
Module – component that implements one or more interfaces
Configuration – component that wires other components together
Interface – provides an abstract definition of the interaction between two components

13. Visualizing modules C1 C2 C3 modules: module C1 {
requires interface triangle;
} implementation { ... }
module C2 {
provides interface triangle in;
requires {
interface triangle out;
interface rectangle side; }
module C3 {
provides interface triangle;
provides interface rectangle; C1 C2 C3

14. Visualizing configurations
Connect configurations:
configuration app { }
implementation {
uses c1, c2, c3;
c1 -> c2; // implicit interface sel.
c2.out -> c3.triangle;
c3 <- c2.side; }
Partial configurations:
component c2c3 {
provides interface triangle t1;
uses c2, c3;
t1 -> c2.in; C1 C2 C3 C2 C3

15. More on wiring
configuration C {
provides interface X;
} implementation {
components C1, C2;
X = C1.X;
C1.Y -> C2.Y;
C1.Z <- C2.Z; }
“=“ used when any endpoint is external (a specification element – provides or uses)
“->” or “<-” used when both endpoints are internal
A -> B is equivalent to B <- A

16. Interfaces, commands, events
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)
Commands typically call downwards (from application components to components closer to hardware) while events call upwards

17. Fan-in, fan-out Endpoints can be connected multiple times.
configuration C {
provides interface X;
} implementation {
components C1, C2;
X = C1.X;
X = C2.X; }
Endpoints can be connected multiple times.
In this case, multiple functions will be executed when C.X’s commands are called and multiple signalers will issue callbacks for subscribers to C.X’s events.

18. Implicit connections
configuration C {
} implementation {
components C1, C2;
C1 <- C2.X;
C2.Y <- C2;
C1.Z -> C2; }
When only there is only one specification element of a given type in the component being mapped to or from, it doesn’t need to be explicitly specified in connections
C1.X <- C2.X is equivalent to C1 <- C2.X as long as there is only one specification element of type X in C1

19. Tasks
“A task is an independent locus of control defined by a function of storage class task returning void and with no arguments: task void myTask() { ... }”
“Tasks are posted by prefixing a call to the task with post, e.g., post myTask();”

20. Example interface // can include c files interface SendMsg {
command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg);
event result_t sendDone(TOS_MsgPtr msg, result_t success); }

21. More on commands and events
Calling a command
int x = ...;
call Send.send[x + 1](1, sizeof(Message), &msg1);
Signaling an event
signal Send.sendDone[x + 1](&msg1, SUCCESS);

22. Atomic statements
bool busy; // global
void f() {
bool available;
atomic {
available = !busy;
busy = TRUE; }
if (available) do_something;
atomic busy = FALSE;
“guarantee that the statement is executed “as-if” no other computation occurred simultaneously”
Should be short!
nesC forbids: call, signal, goto, return, break, continue, case, default, label

23. Blink Example
Program toggles the red LED every second.

24. Blink.nc configuration Blink { } implementation {
components Main, BlinkM, SingleTimer, LedsC;
Main.StdControl -> SingleTimer.StdControl;
Main.StdControl -> BlinkM.StdControl;
BlinkM.Timer -> SingleTimer.Timer;
BlinkM.Leds -> LedsC;

25. BlinkM.nc (specification)
module BlinkM {
provides {
interface StdControl;
} uses {
interface Timer;
interface Leds; }

26. BlinkM.nc (implementation)
command result_t StdControl.init() {
call Leds.init();
return SUCCESS; }
command result_t StdControl.start() {
// Start a repeating timer that fires every 1000ms
return call Timer.start(TIMER_REPEAT, 1000);
command result_t StdControl.stop() {
return call Timer.stop();
event result_t Timer.fired() {
call Leds.redToggle();

27. SingleTimer.nc configuration SingleTimer { provides interface Timer;
provides interface StdControl; }
implementation {
components TimerC;
Timer = TimerC.Timer[unique("Timer")];
StdControl = TimerC;

28. Blink.nc(Complete configuration)