Programming in nesC (and TOSSIM) - PowerPoint PPT Presentation

Loading...

PPT – Programming in nesC (and TOSSIM) PowerPoint presentation | free to download - id: 4a249e-MWY2N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Programming in nesC (and TOSSIM)

Description:

Programming in nesC (and TOSSIM) Professor Jack Stankovic Department of Computer Science University of Virginia Questions How do you program these wireless sensor ... – PowerPoint PPT presentation

Number of Views:191
Avg rating:3.0/5.0
Slides: 71
Provided by: MarkSc75
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Programming in nesC (and TOSSIM)


1
Programming in nesC (and TOSSIM)
Professor Jack Stankovic Department of Computer
Science University of Virginia
2
Questions
  • How do you program these wireless sensor devices?
  • How do you debug your code on a PC?
  • How do you download your code?
  • How do you debug the system?

nesC
TOSSIM Lab 3
Lab 0
Message Center Lab 2
3
Questions
  • What else do you need to know?
  • TinyOS
  • Why nesC?
  • Most widely used
  • Example of systems language for embedded systems

4
Helpful Materials
  • Labs and Lab materials see class web site
  • Handouts read
  • Read
  • The nesC Language A Holistic Approach to
    Networked Embedded Systems, D. Gay, et. al.,
    PLDI, 2003 (sections 1-4 inclusive)
  • Google to find TinyOS tutorial

5
Outline
  • Overview
  • Main Elements and Examples
  • Task Model and Concurrency
  • More Coding Details
  • Examples
  • Message Center (Lab 2 intro in class)
  • TOSSIM
  • Summary

6
TinyOS and nesC Paradigm
  • Component-based
  • TinyOS, libraries, applications written in nesC
  • Intended for embedded systems and WSN
  • C-like syntax (new keywords)
  • Call, signal, task, post, async,
  • TinyOS concurrency model (tasks and events)

7
TinyOS and nesC Paradigm
  • No dynamic memory
  • nesC bi-directional interface is an excellent fit
    for event driven systems
  • Race conditions checked at compile time

8
Big Picture
  • Write components use components written by
    others
  • Will need new keywords/framework for defining
    components
  • Glue components together
  • Called wiring
  • Configuration file
  • Bi-directional interfaces
  • Concurrency/Execution Model
  • Tasks
  • Event handlers
  • Data races checked at compile time

9
Big Picture
  • Use development environment on PC and download to
    target system (motes)
  • Simulator available before downloading
  • Debug on PC
  • Message Center tool inject/read msgs
  • Debug on actual platform

10
Big Picture
  • nesC application
  • 1 or more components
  • Wire them together
  • Must have a MAIN component
  • Modules (implement your code)
  • Configurations (the wiring)
  • Interfaces

11
Big Picture
Provides Interfaces
Interface Commands (how to use
the interface) Events (user of
interface must implement)
Component
Uses Interfaces
12
Application Example
13
Example (cont.)
  • You might only write the application component
  • Perhaps all other components are from a library
  • Applies to TinyOS
  • 108 code modules in TinyOS
  • Examples of Applications
  • Surge 31 modules 27 of them OS
  • TinyDB 65 modules 38 of them OS

14
Example (cont.)
  • Note HW components
  • Veneer of SW exists for each HW component
  • Hides interrupt vector set up
  • Abstracts details of HW init and use (more
    details later)

15
Interfaces
Interface Declare commands (implementor of
this interface
must implement these commands) Declare
events (User of this interface, i.e., a
components that
invokes commands,
must implement these events call
back functions)
Interfaces have global scope!
16
Interface Example
Timer.nc filename for a bidirectional
interface interface Timer command result_t
start (char type uint32_t interval) command
result_t stop() event result_t
fired()
  • Interface is a type
  • Many instances of the interface may exist
  • A command or event in an interface is named i.f
    (Ex Timer.start, Timer.fired)

17
Split Phase
  • Because of the execution model, code should exist
    in small execution pieces
  • Similar to asynchronous method calls
  • Separate initiation of method call from the
    return of the call
  • Call to split-phase operation returns immediately
  • When work actually finishes the caller is
    notified via another method call

18
Specify Split-Phase
  • Declare Interface with both
  • Command
  • Event
  • (e.g., Timer.nc of previous (2) slides back)
  • Use to avoid long delay operations
  • (since a non-preemptive model is used)

19
Components and Interfaces
Provides interfaces (multiple interfaces) (bi-dire
ctional)
Component
Uses Interfaces (multiple interfaces) (bidirection
al)
20
Component Example -Modules
  • Implements a components specification with C
    code

module MyCompM provides interface X
provides interface Y uses interface
Z implementation // C code
module MyCompM provides interface
X interface Y uses interface
Z implementation // C code
specification
MyCompM.nc
MyCompM.nc
The implementation part implements the provides
interfaces and if the uses interface has an event
then this module must also implement an event
handler.
21
Interfaces
  • Used for grouping functionality, like
  • split-phase operation (send, sendDone)
  • standard control interface (init, start, stop)
  • Describe bidirectional interaction
  • Interface provider must implement commands
  • Interface user must implement events

TimerM
ClockC
Note This is how you declare a split-phase
operation, i.e., Command and Event declared.
22
Interfaces
  • Examples of interfaces

interface StdControl command result_t init
() command result_t start () command
result_t stop ()
interface Timer command result_t start (char
type,
uint32_t interval) command result_t stop ()
event result_t fired ()
StdControl.nc
Timer.nc
interface SendMsg command result_t send
(uint16_t addr,
uint8_t len,
TOS_MsgPtr p) event result_t sendDone
()
interface ReceiveMsg event TOS_MsgPtr
receive (TOS_MsgPtr m)
ReceiveMsg.nc
SendMsg.nc
23
Interfaces
  • Not all Interfaces are split-phase
  • E.g., StdControl and ReceiveMsg are not

interface ReceiveMsg event TOS_MsgPtr
receive (TOS_MsgPtr m)
interface StdControl command result_t init
() command result_t start () command
result_t stop ()
24
Parameterized Interfaces
  • Note This is not a parameter list (can
    have that too).

module GenericCommM provides interface
SendMsg uint8_t id provides interface
ReceiveMsg uint8_t id implementation

GenericCommM.nc
25
Parameterized Interfaces
ID 1 ID 2
ID 3
Uses SendMsg Interface
Uses SendMsg Interface
Uses SendMsg Interface
Send Msg 1 Send Msg 2
Send Msg 3
SendMsg Interface Provided by some
Component Must know who to respond to
All boxes are components
26
Parameterized Interfaces
ID 1 ID 2
ID 3
Uses Timer Interface
Uses Timer Interface
Uses Timer Interface
Set timer for 200 ms Set timer for 150 ms
Set timer for 75 ms
Timer Interface Provided by some Component Must
know who to respond to
All boxes are components
27
Components/Interfaces
Events
Commands
Interface1 command a command b event
c Interface2 command d
Wire all components that issue commands a, b or
d to this component
Provides
Component
28
Configurations
  • Wire components together
  • Connected elements must be compatible
    (interface-interface, command-command,
    event-event)
  • 3 wiring statements in nesC
  • endpoint1 endpoint2
  • endpoint1 -gt endpoint2
  • endpoint1 lt- endpoint2 (equivalent endpoint2 -gt
    endpoint1)

29
Configuration - Example
  • Blink application
  • Wiring Example

BlinkC
Main
configuration BlinkC implementation
components Main, BlinkM, ClockC, LedsC
Main.StdControl-gtBlinkM.StdControl
BlinkM.Clock-gtClockC BlinkM.Leds-gtLedsC
BlinkM
BlinkC.nc
ClockC
LedsC
ClockC is really ClockC.Clock LedsC is really
LedsC.Leds
30
Configuration
Main.StdControl -gt BlinkM.StdControl
Component Interface
Implementation
Component Interface
USES PROVIDES
31
Equals Sign
A provides I
But A does not implement I but uses what is
provided by B Hence A B
B provides I
Often used for hierarchical Configuration files
see Example later
32
Implementation
  • fn.nc
  • For all source files (interfaces, modules and
    configurations)

33
Concurrency Model
  • Underlying execution model (TinyOS)
  • Tasks and Events
  • Split phase operation

34
Tasks
  • Tasks
  • Deferred computation
  • Non-preemptable by other tasks
  • Scheduled FCFS from task queue
  • When no tasks CPU goes to sleep
  • Returns void
  • Declare tasks with task keyword
  • Schedule tasks with post keyword

35
Task
task void processData() int16_t i,
sum0 atomic for (i0 ilt size i)
sum (rdatai gtgt 7)
display(sum gtgt log2size)
36
Tasks
FCFS Queue
alert
task void abc() . . post
alert() . .
Next task Current task
TinyOS
Non-preemptive
37
Events
  • Events
  • Execution of an interrupt handler
  • Runs to completion
  • Can preempt tasks and can be preempted by other
    events
  • Declare events with event keyword (as part of
    interfaces)
  • Notify events with signal keyword

38
Events
FCFS Queue
alert
P R E E M P T
Event packet here
Upcalls
Event byte Here Signal packet
Can post Tasks/keep Handlers short
Event Bits Signal Byte
HW interrupt/ radio
Asynchronous
39
Commands and Events
  • For those commands and events that can be
    executed by interrupt handlers explicitly mark
    as async
  • async event result_t ADC.ready (uint16_t data)
  • putdata(data)
  • post processData()
  • return SUCCESS

40
Events
  • Signify completion of a split-phase operation
  • Example packet send via send command then
    communication component will signal sendDone
    event when transmission is complete
  • Events from environment
  • Message reception
  • Clock firing

41
Race Conditions
  • Solutions
  • Access shared data exclusively within tasks
  • Have all accesses within atomic statements

Non-preemptive Task queue
X
x
Shared data
Event Handlers
42
Directions of Calls
Event Call use keyword signal
Component
Command Call use keyword call
43
Big Picture
Components (modules) async command
post task call
commands signal events
command

Main Task post tasks call
commands signal events Task
Components (modules) async command
command
async event
HW Interrupts Invoke commands and events
44
Components - nesC
X Y Config notation
  • The nesC model
  • Interfaces
  • uses
  • provides
  • Components
  • modules
  • configurations
  • Application graph of components

Application
Component D
Component A
Component C
Component B
Component F
Component E
configuration
configuration
45
Modules
  • Call commands and Signal events

module TimerM provides interface StdControl
provides interface Timeruint8_t id uses
interface Clock implementation command
result_t StdControl.stop() call
Clock.setRate(TOS_I1PS, TOS_S1PS)
signal xyz.fired()
TimerM.nc
46
Modules
  • Task a task is an independent locus of control
    defined by a function of storage class task
    returning void and with no arguments
  • Posting tasks keyword post

module BlinkM implementation task
void processing () if(state) call
Leds.redOn() else call Leds.redOff()
event result_t Timer.fired () state
!state post processing() return
SUCCESS
BlinkM.nc
47
Atomic Statements
bool busy // gobal . bool
available . atomic available
!busy busy TRUE . atomic busy
false
nesC forbids calling commands or signaling
events in an atomic section
48
Interrupt Handling
  • Keep interrupt handlers short
  • May post tasks
  • Examples
  • Increment counter in atomic statement and then
    done
  • Call LED to set light red done
  • Post task done
  • Call -gt Call -gt Call -gt Call then return, bad
    idea

49
Matching SW and HW
  • Thin veneer of code for HW devices
  • See next slide
  • Assign symbolic names for signals/pins
  • Photo_PWR (to turn on power to photo sensor)
  • Abstract away interrupt vectors

HW defined Interrupt Vectors
Interrupt Handler
50
Matching SW and HW
  • Example LED
  • Red LED on/off
  • Green LED on/off
  • Yellow LED on/off
  • Toggle
  • Turn on/off power
  • LED has no interrupts
  • User has it easy just know interface

51
Components of Interest
  • LED, Clock, UART, ADC, RFM, I2C (hardware
    abstraction components)
  • Other components Chirp, counter, blink,
    AM_Beacon, AM_Echo,
  • Find interfaces in
  • tos/interfaces/

52
Application Example (revisited)
53
ADC
  • init()
  • get-data()
  • Fires separate event for each data port

54
Programming Environment
  • cygwin/Win2000 or gcc/Linux
  • Wireless download of code also available

mote
Code download
mote-PC comms
programming board
55
Summary/Principles/Concepts
  • Single application
  • Wrap HW devices in thin veneer of SW
  • Hide details
  • Components Glue
  • Use only components required
  • Even for OS
  • Interfaces
  • Bi-directional interfaces
  • Tasks and Events
  • Concurrency
  • Split-phase
  • Asynchronous
  • Embedded systems language
  • No dynamic memory
  • Race conditions
  • Atomic sections
  • Pre-compiler for C

56
Message Center
  • Tool for sending and receiving packets into
    actual system
  • Use tool via 2 windows
  • Learn via Lab 2

57
TOSSIM
  • TinyOS Simulator (not typical)
  • Versus ns2 or glomosim or
  • Write your actual code
  • Compile it into TOSSIM framework
  • Once debugged code moved to real platform

58
TOSSIM Features
  • A discrete event simulator runs on a PC
  • High fidelity simulations capture TinyOS
    behavior at a low level
  • Uses TinyOS component based architecture

59
TOSSIM capabilities
  • Simulates large scale sensor networks (e.g.,
    thousands)
  • Simulates network at bit level (bit error per
    link)
  • Simulates repeatable loss rate
  • Simulates asymmetric links
  • Simulates each individual ADC capture
  • Simulates every interrupt in the system
  • Time is kept at 4MHz granularity gt 4 million
    ticks per second

60
TOSSIM non-capabilities
  • Does not simulate single strength
  • Does not model execution time
  • No spin locks or task spin locks
  • A piece of code runs instantaneously
  • Does not model power draw
  • Interrupts are non-preemptive
  • Simulates the 40Kbit RFM mica networking stack
  • Does not simulate the Mica2 ChipCon CC1000 stack

61
TOSSIM Radio Models
  • Simple every mote in one cell, bits perfectly
    transmitted
  • Lossy connectivity determined at startup
  • Radio propagation is not modeled, rather an
    abstraction of it is (bit error rate)
  • Specified in a file .nss (use rfltfilegt
    option)
  • Specified connectivity
  • Specified bit error rate
  • For example
  • ltmote IDgtltmote IDgtbit error rate
  • 010.009

62
Radio Model
my_radio_model.nss
010.001 100.002 020.001 200.9
.001
1
0
.002
.001
x
.9
2
Model an asymmetric link
63
Using TOSSIM
  • Compiling TOSSIM
  • cd apps/Blink
  • make pc
  • make rffname pc
  • Use ./build/pc/main.exe options ltnum_nodesgt
  • options are (see manual for more)
  • -k ltkbgt, -Set radio speed to ltkbgt Kbits/s. Valid
    values 10, 25, 50.
  • -r, specifies a radio model (simple is default)
  • -t, -ltsecgt tells TOSSIM to run for a specified
    number of virtual seconds.
  • ltnum_nodesgt number of nodes to simulate

64
Debugging
Your code dbg(DBG_CRC, crc
check failed) dbg(DBG_BOOT,
Sensor initialized)
65
TOSSIM Debugging
  • Known dbg flags (system/include/dbg_modes.h)
  • all, boot, clock, task, sched, sensor, led,
    route, am, crc, packet, encode, radio, logger,
    adc, i2c, uart, prog, sim, queue, simradio,
    hardware, simmem (found in TinyOS code)
  • For use in applications usr1, usr2, usr3, temp
  • Insert debug statements in source code
  • dbg(DBG_ROUTEDBG_ERROR, "Received control
    message lose our network name!.\n")

66
TOSSIM Debugging
  • Set dbg flags to get the proper debug information
  • When simulator starts it read DBG environment
    variable to enable modes
  • For example export DBGusr1,route
  • Only these debug statements will be active!

67
Important
  • Once you recompile with mote as target instead of
    pc (i.e., TOSSIM)
  • All debug statements are removed from the
    executable for you!

68
Using Debugging
  • Print to screen or file
  • Use Serial Forwarder
  • Can inject messages to mote 0
  • -comm tossim-serial
  • Can snoop all messages in network
  • -comm tossim-radio
  • Run gdb
  • gdb build/pc/main.exe

69
TOSSIM
  • See TOSSIM document (read when you are preparing
    for Lab 3)
  • See TOSSIM paper (sections 1-3 inclusive read
    now)
  • Learn via Lab 3

70
Summary
  • nesC most widely used today for WSN
  • - systems programming language
  • Use naming conventions see handout
  • Lab 0 mechanics of downloading, etc.
  • Lab (Programming) Assignments 1-4
  • Possible Extra Credit Project
About PowerShow.com