An Introduction to nesC

1
An Introduction to nesC

• Vinay Kumar Singh
• Dongseo University

2
Outline

• Introduction
• TinyOS concepts
• nesC concepts
• Example
• References
• Conclusion.

3
(No Transcript)
4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
TinyOS Execution Contexts

• 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.

10
(No Transcript)
11
(No Transcript)
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

• modules
• module C1
• requires interface triangle
• implementation ...
• module C2
• provides interface triangle in
• requires
• interface triangle out
• interface rectangle side
• implementation ...
• module C3
• provides interface triangle
• provides interface rectangle
• implementation ...

14
Visualizing configurations

• Connect configurations
• configuration app
• implementation
• uses c1, c2, c3
• c1 -gt c2 // implicit interface sel.
• c2.out -gt c3.triangle
• c3 lt- c2.side
• Partial configurations
• component c2c3
• provides interface triangle t1
• implementation
• uses c2, c3
• t1 -gt c2.in
• c2.out -gt c3.triangle
• c3 lt- c2.side

15
More on wiring

• configuration C
• provides interface X
• implementation
• components C1, C2
• X C1.X
• C1.Y -gt C2.Y
• C1.Z lt- C2.Z
• used when any endpoint is external (a
  specification element provides or uses)
• -gt or lt- used when both endpoints are
  internal
• A -gt B is equivalent to B lt- A

16
Interfaces, commands, events

• Interfaces are bidirectional they specify a set
  of functions to be implemented by the interfaces
  provider (commands) and a set to be implemented
  by the interfaces user (events)
• Commands typically call downwards (from
  application components to components closer to
  hardware) while events call upwards

17
Fan-in, fan-out

• 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.Xs commands are called and multiple
  signalers will issue callbacks for subscribers to
  C.Xs events.

18
Implicit connections

• configuration C
• implementation
• components C1, C2
• C1 lt- C2.X
• C2.Y lt- C2
• C1.Z -gt C2
• When only there is only one specification element
  of a given type in the component being mapped to
  or from, it doesnt need to be explicitly
  specified in connections
• C1.X lt- C2.X is equivalent to C1 lt- 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.sendx 1(1, sizeof(Message), msg1)
• Signaling an event
• int x ...
• signal Send.sendDonex 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 -gt SingleTimer.StdControl
• Main.StdControl -gt BlinkM.StdControl
• BlinkM.Timer -gt SingleTimer.Timer
• BlinkM.Leds -gt LedsC

25
BlinkM.nc (specification)

• module BlinkM
• provides
• interface StdControl
• uses
• interface Timer
• interface Leds

26
BlinkM.nc (implementation)

• 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()
• return SUCCESS

27
SingleTimer.nc

• configuration SingleTimer
• provides interface Timer
• provides interface StdControl
• implementation
• components TimerC
• Timer TimerC.Timerunique("Timer")
• StdControl TimerC

28
Blink.nc(Complete configuration)