rahav tinyos-lectures 2014lu/cse467s/slides/tinyos... · 2014. 1. 28. · detached from the hive....

Embedded computing projects, Learning TinyOS & nesC

Rahav Dor Spring 2014

Kevin Klues started this lecture series in 2007. It has been inherited and kept up to date with advancements in TinyOS, nesC, and their development environments by Chien-Liang Fok, Gregory Hackmann, Mo Sha, and now Rahav Dor.

Lecture topics Ø  Embedded Compu9ng projects Ø  Coding style, coherent and useful programming Ø  Installing TinyOS and compiling your first app Ø  Introduc9on to motes Ø  Basic nesC syntax Ø  Advanced nesC syntax Ø  Network communica9on Ø  Sensor data acquisi9on Ø  Debugging tricks and techniques

2


3

Robobees, Harvard university

Cool projects out there Ø  Good night lamp. Ø  Plantduino Greenhouse. Ø  TwiQer mood light. Ø  LED cube. Ø  Shoe that lace itself. Ø  Turn signal biking jacket. Ø  Secret knock door lock. Ø  Tree climbing robot. Ø  Sigh collector.

4

Cool projects in here Ø  Compare TinyOS and Con9ki. Ø  Turn your mote into a web server, have it support AllJoin

(AllSeen), Bonjour, CoAP, NLNA, MQTT, nanoIP, REST, etc. Ø  Empirical study of any number of above protocols Ø  Develop you own transport protocol, discovery protocol, … Ø  Turn RaspberryPi into a 802.15.4 base sta9on (this is one

of the few projects that are allowed on RPi). Ø  Compara9ve study of security for IoT devices

q  New ideas?

Ø  Make your smartphone into a 802.15.4 remote control q  Support querying, proximity, and simple commands

Ø  Develop an IoT search engine

5

Get inspired Ø  hQp://makezine.com/ Ø  hQp://www.instructables.com/

Ø  hQp://www.raspberrypi.org/forums/viewforum.php?f=15 q  Note that you cannot use the Raspberry Pi as the main pla`orm in

this course without my prior approval

6

Projects – requirements Ø  Embedded system Ø  Design, Code, and evalua9on – evenly divided among team Ø  Project scope must be approved by me (Rahav) Ø  Can repeat past projects as long as they have a twist

q  But you need to design and author your own code

Ø  You will be subject to academic disciplinary ac9ons, including failing this course, if you (see course full policy) q  Submit program code wriQen outside this course without proper cita9on q  Simply copy code not wriQen by you q  Use code of another student not on your team q  Collabora9on and discussions are great explora9on vehicles and are

encouraged, but you must aQribute the ideas to their originator

7

Projects – artifacts Ø  All ar9facts will count toward your grade Ø  Design (diagrams and discourse authored in any tool)

q  Specifica9ons q  Data flow q  Logical interac9ons between the components or func9ons q  Design considera9ons

•  What you have considered (op9onal) •  What you have decided to do

Ø  README.txt (or readme.txt) q  See the readmeFD.txt example, which includes q  A short descrip9on of the app q  How to install, compile, and run your project (including a

command line sec9on, e.g. java MIG) q  Hardware dependencies

8

Equipment Ø  Equipment, motes, … must be returned in good condi9on

q  -‐10% automa9c reduc9on otherwise q  Physical interfacing must be done via connectors q  Past evils can be undone

•  Up to a full grade leQer (on the project part) of extra credit for good ci9zenship: Soldering, Double sided tape, Cleaning

Ø  See course site for exis9ng equipment q  Within reason and 9me we can buy staff to support your inven9on

9

Header comment (1 of 2) Ø  Author a header comment at the top of all source files. Use

the following format: Ø  The name of the file (e.g., HelloWorldC.nc) Ø  The name of the deliverable (e.g., Midterm demo. RFID

reader.) Ø  Name of the chief author and email address Ø  Class: CSE 467S – Embedded Compu9ng Systems Ø  WUSTL, Spring 2014 Ø  The date on which the first release of the code was ready Ø  Invariants

10

Header comment (2 of 2) Ø  A short paragraph describing the func9onality. This should

include, for example the purpose of the file or its role in the project. Be crisp, precise, and informa9ve. Communicate your approach to solving the problem.

Ø  Version log with q  Date q  Who made the change, email address, and why q  What was the change

11

Header example

12

HelloWorldC.nc Purpose: Final project. Agent updater. Author : Rahav Dor

[email protected] Course : CSE 467S -- Embedded Computing Systems WUSTL, Spring 3017 Date : Jan. 2, 3017 Invariants:

10 Hz <= updateFrequency <= 50 Hz Description:

Maintain communication between agents and keep a local state when agents are detached from the hive. If communication channels are open this code guarantees information exchange according to the invariant.

Version log: 2/1/2013, Jean-Luc Picard Fixed the remote agent bug. 3/10/2013, Seven of Nine An agent can now be detached from the collective, while still maintaining its basic operations.


13

Style Ø  Write self documen9ng code:

if (lowTemperature(temp)) work = force * displacement * cos(moteToFloorAngle)

Ø  Indent 3 spaces or equal sized tab stop Ø  Use DESCRIPTIVE_CONSTANTS Ø  And self explanatory variablesNames Ø  FileNames, ClassNames, e.g

q  Modules are named FallDetectionC q  Configura9on is named FallDetectionAppC

14

Style Ø  curlyFunctionBraces {

… }

Ø  if (youFollow) { your are in a good starting place; } else { you start from less than optimal condition; }

Ø  Func9ons must have specs above them that describe the func9on, invariants if any, parameters, and return value

Ø  Use inline comments as needed

15

Style – TinyOS / nesC Ø  Each app has a Configura9on (the wiring)

and one ore more Modules (the code) Ø  Wiring file are named: HelloWorldAppC.nc

q  This file name is the one specified in the Makefile as the source to be compiled

Ø  Code files are named : HelloWorldC.nc Ø  Can also end with a P to denote Private

16


17

TinyOS community q  hQp://www.9nyos.net/

18

TINYOS INSTALLATION – LINUX

The next number of slides go over the general concepts of installing TinyOS (my recommenda9ons as of Jan. 2014). To install the system use the handout available on the course web site.

19

TinyOS recommended installation Ø  We will be installing TinyOS, on Linux, running on a VM,

that runs on a Host OS Ø  Follow the installa9on instruc9ons handout Ø  I recommend you do the large downloads while on campus

and while connected to a wired network Ø  VMware (Fusion version is the one for OS-‐X and cost 49$),

or VirtualBox (free) q  Known problems: Cut and Paste, Bluetooth

Ø  Ubunto 12.x (LTE) or 13.x (other debian flavors may work equally well) q  Considera9on for 32 and 64 bit versions: Memory, TinyOS will not

compile on 64, and OS response 9me

20

TinyOS directory structure Ø  Aser TinyOS is installed you will have a new tree branch

under your home directory: /$HOME/9nyos-‐main (this must correspond to $TOSROOT) q  apps q  doc q  licenses q  README q  release-‐notes.txt q  support q  tools q  tos

Ø  Checkout TinyOS README file for details

21

Before motes are connected Ø  Learn which devices are aQached to Linux before you

connect any mote to your machine. It will allow you to iden9fy what is the address of motes when you eventually connect them. Use the ls /dev/tty* command to capture data similar to the following:

22

When motes are connected Ø  When you connect a mote, the Virtual Machine will ask

you where do you want to connect it – chose Linux Ø  The ls command as shown on the previous slide, or the

command motelist will show you the aQached motes Ø  Change the permissions on any 9nyOS related

q  serial (/dev/QyS<N>) q  usb (/dev/Qs/usb<N>, /dev/QyUSB<N>) q  or parallel (/dev/parport)

devices you are going to use, using the following command: sudo chmod 666 /dev/<devicename> Example: sudo chmod 666 /dev/ttyUSB0

Ø See a beQer alterna9ve in the handout 23

TinyOS installation veriRication Ø  To check your TinyOs installa9on run tos-‐check-‐env Ø  If you did everything properly you will see only one

WARNING about graphviz not being version 1.10 (it will appear twice)

Ø  This is actually OK because you will have a newer version (likely 2.x). To check run dot –V

Ø  Later in this lecture, and on the installa9on handout, we will also build Blink to conclude the verifica9on

24

TinyOS installation Problems Ø  If you try to run make micaz sim and it gives you a long

error message star9ng with: ...: error: inttypes.h: No such file or directory

Ø  then you need to install the C library/header files for your own architecture

Ø  On Ubuntu/Debian, run apt-‐get install build-‐essential

25

TINYOS INSTALLATION – LINUX

26

This concludes the general details about installing TinyOS

make System Ø  TinyOS includes lots of Makefiles to support the build process Ø  Create a simple stub Makefile in your app directory that points

to main component, and invokes TinyOS make system. COMPONENT=[MainComponentAppC] # the name of your …AppC file SENSORBOARD=[boardtype] # if needed include $(MAKERULES)

Ø  Two real examples:

27

make System

28

make System Ø  To compile an app without installing it on a mote, run in

the app directory: make [platform] Where pla`orm is one of mote names (e.g. micaz, telosb, shimmer2r) defined in $TOSROOT/tos/platforms

Ø  make clean Ø  make docs [platform]

q  Generates HTML documenta9on in $TOSROOT/doc/nesdoc/[platform]

29

make System make [re]install.[node ID] [platform] [programmingBoard,address]

q  node ID : 0 – 255, for radio transmissions q  platform: as defined in $TOSROOT/tos/platforms q  Programming Board:

•  For mica2/micaz use: mib510 •  For telosb use : bsl

q  Address (as reported by ls /dev/tty* or motelist). For example: /dev/ttyXYZ ttyUSB0 /dev/tty.usbserial-‐FTVCZRNVA

30

Useful commands Ø  motelist

q  See the list of motes physically connected to your pc Ø  make telosb

q  Compile your code for the telosb mote Ø  make telosb install.1

q  Compile your code for telosb, install it on a mote, give it the network id 1

Ø  make telosb reinstall.7 q  Use exis9ng runnable, install it on telosb, give it a

network id of 7 Ø  make docs telosb

q  Generate docs for your applica9on 31

Build stages

32

Set AM address and node ID in binary

Program mote

Preprocess .nc to .c, then compile .c to binary

Our Rirst TinyOS experience

33

Provided with TinyOS Blink’s README.txt: Blink is a simple application that blinks the 3 mote LEDs. It tests that the boot sequence and millisecond timers are working properly. The three LEDs blink at 1Hz, 2Hz, and 4Hz. Because each is driven by an independent timer, visual inspection can determine whether there are bugs in the timer system that are causing drift. Note that this method is different than RadioCountToLeds, which fires a single timer at a steady rate and uses the bottom three bits of a counter to display on the LEDs.

The provided make file: COMPONENT=BlinkAppC include $(MAKERULES)


34


35

Project 0 Ø  Install your favorite VM or your favorite host OS Ø  Install ubuntu 12.x or 13.x Ø  Install TinyOS 2.1.2 Ø  Run tos-‐check-‐env Ø  Build Blink Ø  Answer the ques9ons on the following slide Ø  Due Feb. 5 Ø  Email me the following screen captures

q  Full window capture of ubuntu running inside a VM and Terminal open, lis9ng the /dev/Qy* files

q  What you typed and compila9on results of Blink q  Full browser window (including all panes) showing BlinkAppC

documenta9on as it was generated by the nesC docs system 36

How to earn an A on project 0? Ø  Example for first two deliverables are in this lecture Ø  Here is the third deliverable:

37

How to get Help Ø  TinyOS Documenta9on Wiki: hQp://docs.9nyos.net Ø  Text book, TinyOS Programming

hQp://www.amazon.com/TinyOS-‐Programming-‐Philip-‐Levis/dp/0521896061

Ø  TinyOS Programming Manual: PDF intro to nesC and TinyOS 2.x: hQp://www.9nyos.net/9nyos-‐2.x/doc/pdf/9nyos-‐programming.pdf

Ø  TinyOS Tutorials: short HTML lessons on using parts of TinyOS (sensors, radio, TOSSIM, etc.): hQp://docs.9nyos.net/9nywiki/index.php/TinyOS_Tutorials

38

How to get Help Ø  nesdoc: annotated API for all interfaces and components in TinyOS:

hQp://docs.9nyos.net/9nywiki/index.php/Source_Code_Documenta9on

39

The nesC code: call Leds.led1Toggle(); // Yellow

How to get Help Ø  TinyOS Enhancement Protocols (TEP): formal documenta9on for

TinyOS features: hQp://docs.9nyos.net/9nywiki/index.php/TEPs Ø  My office hours (Bryan 502D)

q  By email [email protected] q  Subject line MUST start with [CSE467] or [CSE467S]

40

Reminders Ø  Team up Ø  Projects need approvals

q  Itera9ons may be needed before you can work on the proposals

Ø  Design is part of a successful project (and life aser school) Ø  Start early and spread the work evenly throughout the

semester Ø  I am here to make you successful and enjoy the course

41


42

Terms we need to know Ø  Synchronous

q  Agreed Nming for the sending of ones and zeroes (bits) q  Requires sender-‐receiver coordina9on

Ø  Asynchronous q  Ones and zeros can be sent at any point in 9me

Ø  Baud q  symbols / second

Ø  BUS q  Transfers data between components

Ø  UART (Universal Asynchronous Receiver/TransmiQer) q  Translates data between parallel and serial forms q  Universal = format and transmission speeds are configurable

43

Terms… Ø  Mul9-‐master

q  Mul9ple nodes can be the master (can ini9ate transfer) q  E.g. allows DMA to work wo the CPU

Ø  SPI (Serial Peripheral Interface) q  Synchronous serial bus (pronounced as either ess-‐pee-‐eye or spy)

Ø  I2C q  Synchronous two wire mul9-‐master bus q  For low-‐speed peripherals

Ø  ADC q  Analog to Digital Converter

Ø  DAC q  Digital to Analog converter

Ø  JTAG q  Today JTAG is used as the primary means of accessing sub-‐blocks

of ICs, or programming devices

44

Interrupts

45

Available Hardware Ø  Motes, sensor boards, sensors, etc. Ø  With proper jus9fica9on and 9me we will be happy to buy

addi9onal equipment Ø  Most up to date list here:

hQp://wsn.cse.wustl.edu/index.php/Equipment_for_course_projects

46

Tmote Sky (aka TelosB) Ø  IEEE 802.15.4 Radio (2.4 GHz)

q  250kbps

Ø  TI MSP430 microcontroller q  16MHz, 16 MIPS, 10kB RAM

Ø  Integrated antenna & USB interface Ø  SBT80: light, IR, acous9c, temperature, magnetometer, and

accelerometer sensors, all of dubious accuracy Ø  Low power u9liza9on

q  1.8mA/5.1µA

Ø  So how many hours can it work on two AA baQeries?

47

Wifi’s 802.11n max is between 54 Mbits/s to 600 Mbits/s

Tmote front

48

Tmote back

49

MICAz Mote (MPR2400)

50

512KB External Flash

Memory 802.15.4 radio,

250 kbps 2.4 to 2.48 GHz

(ISM)

51 pin I/O Connector

2 AA

UART, SPI I2C Bus

3 LEDs

To Light, Temp, Barometric, Accel, Acous9cs, Magne9c, etc. Or Programming Board

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

4KB config. EEPROM

128KB Instruc9on EEPROM

UART

Atmel ATmega128L μP

7.3827MHz (8 MIPS)

8 ADC

MICAz Programming board (MIB510)

51

Mote JTAG

Serial interface to laptop

MICA2Dot interface

Mote interface

ISPJTAG

Block data to laptop

Reset 5V Power

MTS310CA Sensor board

52

4.6KHz Speaker

Magnetometer

2 Axis Accelerometer

51 pin MICA2 Interface

Microphone

Light and Temperature

Tone Detector

NSLU2 Network Storage Link (“Slug”) Ø  266MHz Xscale CPU, 32MB SDRAM, 8MB

flash, 1x Ethernet port Ø  Wired power Ø  No built-‐in radio, but 2x USB 2.0 ports for

add-‐on 802.11/Bluetooth/mote interface Ø  Can be easily converted to an embedded Linux

box with third-‐party firmware q  Our testbed uses the OpenWrt distribu9on

(hQp://openwrt.org)

53


54

TinyOS Execution model Ø  To save energy, node stays asleep most of the 9me Ø  Computa9on is kicked off by hardware interrupts Ø  Interrupts may schedule tasks to be executed at some 9me

in the future Ø  TinyOS scheduler con9nues running un9l all tasks are

cleared, then sends mote back to sleep

55

HandlePacket ReadSensor TimerFired

zZz

App Bootstrapping Ø  Each app has a “main” configura9on file which wires

together the app’s cons9tuent components Ø  But how do these components start running? Ø  TinyOS includes a MainC component which provides the

Boot interface:

  interface Boot {   event void booted();   }

56

App Bootstrapping Ø  Create one module which ini9alizes your applica9on, then

wire MainC’s Boot interface into it:

57

Configuration RoutingAppC { } implementation { components RoutingC; components MainC; ... RoutingC.Boot -‐> MainC; }

module RoutingC { uses interface Boot; } implementation { event void Boot.booted() { // Initialize here } ... }

TinyOS Component model

58

ActiveMessageC

Provides Split Control

Provides Send

Provides Receive

Upper Layer


59

ActiveMessageC


Provides Send

Provides Receive

Upper Layer

command Start()


60

ActiveMessageC


Provides Send

Provides Receive

Upper Layer

event Startdone()

Components != Objects

61

Ac9veMessageC Ac9veMessageC

NetworkHandlerC AnotherHandlerC AppLogicC

✓ ✗ Ac9veMessageC

Interfaces Ø  List of exposed events and commands Ø  Like ordinary C func9on declara9ons, except with event or

command in front

62

interface Receive { event message_t * Receive(message_t * msg, void * payload, uint8_t len); command void * getPayload(message_t * msg, uint8_t * len); command uint8_t payloadLength(message_t * msg); }

Points to any data type

void *

Ø  Modules provide the implementa9on (code, logic) of one or more interfaces

Ø  They may consume (use) other interfaces:

Ø  “Rename” interfaces with the as keyword -‐-‐ required if you are using/providing more than one of the same interface!

module ExampleModuleC { provides interface SplitControl; uses interface Receive; uses interface Receive as OtherReceive; } implementation { ... }

Modules

63

Modules Ø  The implementation block may contain:

q  Variable declara9ons q  Helper func9ons q  Tasks q  Event handlers q  Command implementa9ons

64

Modules: Variables and Functions Ø  Placed inside implementation block exactly like standard C

declara9ons:

65

... implementation { uint8_t localVariable; void increment(uint8_t amount); // declaration ... void increment(uint8_t amount) { // implementation localVariable += amount; } }

Modules: Tasks Ø  Look a lot like func9ons, except:

q  Prefixed with task q  Can’t return anything q  Can’t accept any parameters

66

implementation { ... task void legalTask() { // OK } task bool illegalTask() { // Error: can’t have a return value! } task void anotherIllegalTask(bool param1) { // Error: can’t have parameters! } }

Modules: Task Scheduling Ø  Tasks are scheduled using the post keyword

Ø  Can post from within commands, events, and other tasks Ø  For longer computa9on, background data processing, etc. Ø  Can be preempted by interrupts, but not by other tasks

q  So, design considera9on: Break a series of long opera9ons

Ø  TinyOS guarantees that task will eventually run q  Default scheduling policy: FIFO

Ø  Cannot post the same task while its on the queue

67

task1 ✓ task2 task3 ... ✗ task1 task1

post handlePacket();

Modules: Commands and Events Ø  Commands and events also look like C func9ons, except:

q  they start with the keyword command or event q  the “func9on” name is in the form

InterfaceName.commandOrEventName

68

implementation { command error_t SplitControl.start() { // Implements SplitControl’s start() command } event message_t * Receive.receive(message_t * msg, void * payload, uint8_t len) { // Handles Receive’s receive() event } }

Modules: Commands and Events Ø  Commands are invoked using the call keyword:

Ø  Event handlers are invoked using the signal keyword:

69

call Leds.led0Toggle(); // Invoke the led0Toggle command on the Leds interface

signal SplitControl.startDone(); // Invoke the startDone event handler on the SplitControl interface

Modules: Commands and Events Ø  A command, event handler, or func9on can call or signal any other

command or event from any interface wired into the module:

70

module ExampleModuleC { uses interface Receive; uses interface Leds; } implementation { event message_t Receive.receive(message_t * msg, void * payload, uint8_t len){ // Just toggle the first LED call Leds.led0Toggle(); return msg; } ... }

configuration NetworkHandlerC { provides interface SplitControl; } implementation { components NetworkHandlerC as NH, ActiveMessageP as AM; // NH.Receive -‐> AM.Receive; // SplitControl = NH.SplitControl; NH.Receive -‐> AM; SplitControl = NH; }

wire interfaces among external components using arrow

ConRigurations

71

External interface list

Components list Rename components to give them more convenient names whenever the wiring is

unambiguous, you don’t have to include the interface name

wire internal interfaces using =

Quote from the people who made it Ø  Modules implement program logic*1 Ø  Configura9ons compose modules into larger abstrac9ons*1

72

*1 Philip Levis

Race conditions Ø  Use atomic blocks to avoid race condi9ons, they do not

get preempted.

73

implementation { uint8_t sharedCounter; async event void Alarm.fired() { ... sharedCounter++; } event void Receive.receive(...) { ... sharedCounter++; } }

Race conditions Ø  Use atomic blocks to avoid race condi9ons

74

Interrupts are disabled here -‐-‐ use sparingly and make as short as prac9cal

implementation { uint8_t sharedCounter; async event void Alarm.fired() { atomic { sharedCounter++; } } event void Receive.receive(...) { ... sharedCounter++; } }

Race conditions Ø  Tasks are always synchronous Ø  If 9ming isn’t crucial, defer code to tasks to avoid race condi9ons

75

implementation { uint8_t sharedCounter; task void incrementCounter() { sharedCounter++; } async event void Alarm.fired() { post incrementCounter(); } event void Receive.receive(...) { ... sharedCounter++; } }

Task is scheduled immediately, but executes later

nesC and Race conditions Ø  nesC can catch some, but not all, poten9al race condi9ons Ø  If you’re absolutely sure that there’s no race condi9on (or

don’t care if there is), use the norace keyword:

76

implementation { norace uint8_t sharedCounter; async event void Alarm1.fired() { sharedCounter++; call Alarm2.start(200); } async event void Alarm2.fired() { sharedCounter-‐-‐; call Alarm1.start(200); } }

Race condi9on is impossible; these

Alarms are mutually exclusive

TOSThreads Ø  New in TinyOS 2.1: the TOSThreads threading library Ø  Threads add a third execu9on context to TinyOS’s

concurrency layer q  Lowest priority: only run when TinyOS kernel is idle q  Threads are preemptable by everything: sync, async, or other

threads

Ø  Also adds a library of synchroniza9on primi9ves (mutex, semaphore, etc.) and blocking wrappers around non-‐blocking I/O

Ø  Described in TOSThreads Tutorial (hQp://docs.9nyos.net/ index.php/TOSThreads_Tutorial) or TEP 134

77

Example-‐Blink (…\tinyos-‐main\apps\Blink)

78

Three files: 1. Makefile 2. BlinkC.nc (module = logic) 3. BlinkAppC.nc (configura9on = wiring)

Make%ile

79

COMPONENT=BlinkAppC include $(MAKERULES)

BlinkC.nc (the logic or code)

80

#include "Timer.h" module BlinkC { uses interface Timer<TMilli> as Timer0; uses interface Timer<TMilli> as Timer1; uses interface Timer<TMilli> as Timer2; uses interface Leds; uses interface Boot; }

Implementation { event void Boot.booted() { call Timer0.startPeriodic(250); call Timer1.startPeriodic(500); call Timer2.startPeriodic(1000); } event void Timer0.fired() { call Leds.led0Toggle(); } event void Timer1.fired() {…} event void Timer2.fired() {…} }

BlinkAppC.nc (the wiring)

81

configuration BlinkAppC { } implementation { components MainC, BlinkC, LedsC; components new TimerMilliC() as Timer0; components new TimerMilliC() as Timer1; components new TimerMilliC() as Timer2; BlinkC -> MainC.Boot; BlinkC.Timer0 -> Timer0; BlinkC.Timer1 -> Timer1; BlinkC.Timer2 -> Timer2; BlinkC.Leds -> LedsC; }


82

High-‐Level Summary Ø  nesC includes a lot of complex features that try to alleviate

design problems with TinyOS 1.x Ø  The good news: you will probably never have to write code

that incorporates these features Ø  The other news: you’re almost certain to use code that

incorporates these features

83

Interfaces with Arguments Ø  Crea9ng new interfaces to support different data types can

get redundant fast

  interface ReadUint16 {   command error_t read();   event void readDone(error_t error, uint16_t value);   }

  interface ReadBool {   command error_t read();   event void readDone(error_t error, bool value);   }

84

Interfaces with Arguments Ø  If you want to make an interface adapt to different

underlying types, then put a placeholder in angle brackets: interface Read<type> {

  command error_t read();   event void readDone(error_t error, type value);   }

  module SixteenBitSensorP {   provides interface Read<uint16_t>;   }

  module BooleanSensorP {   provides interface Read<bool>;   }

85

Fan-‐In: No big deal

86

NetworkHandlerP AnotherHandlerP AppLogicP

RadioP

provides Receive

uses Receive uses Receive uses Receive

Many-‐to-‐one calls may work like you’d expect.

Ø  Behavior of shared component depends on its design. Can return FAILURE (requests rejected), buffer them, or screw the data up.

Fan-‐Out: Bad things happen

87

NetworkHandlerP AnotherHandlerP AppLogicP

provides Receive


… but what about one-‐to-‐many calls?

RadioP

return &buffer1; return &buffer2; return &buffer3;

Fan-‐Out: When bad things happen Ø  If different return values come back, nesC may not be able

to make sense of the contradic9on and will arbitrarily pick one

Ø  Avoid designs where this is possible Ø  If you can’t avoid it, see TinyOS Programming Guide 5.2 for

more info on combining return values

88

Parameterized Wiring Ø  Consider the following way to avoid fan-‐out:   module RadioP {   provides interface Receive as Receive0;   provides interface Receive as Receive1;   provides interface Receive as Receive2;   uses interface LowLevelRadio;   ...   }

  implementation {   event void LowLevelRadio.packetReceived(   uint8_t * rawPacket) {   ...   uint8_t type = decodeType(rawPacket);   if(type == 0)   signal Receive0.receive(...);   else if(type == 1)   signal Receive1.receive(...);   ...   }   ...   }

89

Network HandlerP

Another HandlerP AppLogicP

RadioP


Parameterized Wiring Ø  The idea works in concept, but isn’t maintainable in prac9ce Ø  nesC can yield the desired behavior in a more maintainable way:

  module RadioP {   provides interface Receive[uint8_t id];   ...   }

  implementation {   event void LowLevelRadio.packetReceived(uint8_t * rawPacket) {   ...   uint8_t type = decodeType(rawPacket);   signal Receive[type].received(...);   }   ...   }

90

Using Parameterized Wiring Ø  You can wire parameterized interfaces like so:

AppLogicP -‐> RadioP.Receive[0]; NetworkHandlerP -‐> RadioP.Receive[1]; AnotherHandlerP -‐> RadioP.Receive[2];

Ø  If each component is wired in with a unique parameter, then fan-‐out goes away

91

Unique parameters Ø  In most cases, it’s unreasonable to expect the user to count the

number of 9mes (s)he is using the interface and wire accordingly Ø  nesC can automa9cally generate a unique parameter for you using

the unique() macro:

  AppLogicP -‐> RadioP.Receive[unique(“RadioP”)];   // unique(“RadioP”) expands to 0   NetworkHandlerP -‐> RadioP.Receive[unique(“RadioP”)];   // unique(“RadioP”) expands to 1

  AnotherHandlerP -‐> RadioP.Receive[unique(“RaadioP”)];   // unique(“RaadioP”) expands to 0 (oops)

92

uniqueCount() Ø  What if your component needs to store different state for

each unique parameter? q  We can use an array. But of what size?

  module RadioP {

  ...   }   implementation {   int16_t state[ ];

  ...   }

93

uniqueCount(“RadioP”)

uniqueCount(“strName”) expands to # of 9mes

unique(X) appears in the applica9on

Defaults Ø  If you provide a parameterized interface and signal an event on

it, you must also give a default event handler:  

module SharedComponentP {   ...   }

  implementation {   event void LowLevelRadio.packetReceived(uint8_t * rawPacket) {

  ...   signal Receive[type].received(...);   }

  default event void Receive.received[uint8_t id](...) {   // e.g., do nothing   }   ...   }

94


95

error_t data type Ø  TinyOS defines a special error_t data type that describes

several error codes Ø  Osen given as return values to commands or event

handlers Ø  Commonly used values:

q  SUCCESS (everything is OK) q  FAIL (general error) q  EBUSY (subsystem is busy with another request, retry later) q  ERETRY (something weird happened, retry later)

Ø  Others defined in $TOSROOT/types/TinyError.h

96

Message Addressing Ø  Each node can have a unique 16-‐bit address (am_addr_t)

specified on the make command make install.[address] platform

Ø  Two special constants available for code authoring: q  TOS_BCAST_ADDR (0xFFFF) is reserved for broadcast traffic q  TOS_NODE_ID always refers to the node’s own address

Ø  Each message also has an 8-‐bit Ac9ve Message ID (am_id_t) analogous to TCP ports q  Determines how host should handle received packets, not which

host receives it q  0 - 126 are reserved for TinyOS internal use

97

TinyOS Active Messages (AM) Ø  message_t structure defined in

$TOSROOT/tos/types/message.h Ø  Each pla`orm defines pla`orm-‐specific header, footer, and

metadata fields for the message_t Ø  Applica9ons can store up to TOSH_DATA_LENGTH bytes

payload in the data field (28 by default, 114 max)

98

typedef nx_struct message_t { nx_uint8_t header[sizeof(message_header_t)]; nx_uint8_t data[TOSH_DATA_LENGTH]; nx_uint8_t footer[sizeof(message_footer_t)]; nx_uint8_t metadata[sizeof(message_metadata_t)]; } message_t; Header Payload (TOSH_DATA_LENGTH) Footer Metadata

Split-‐Phase operation Ø  Many networking commands take a long 9me (ms) for

underlying hardware opera9ons to complete -‐-‐ blocking would be bad

Ø  TinyOS makes these long-‐lived opera9ons split-‐phase q  Applica9on issues start...() command that returns immediately q  An event is signaled when it’s actually done

99

 interface SplitControl {   command error_t start();   event void startDone(error_t error);

  command error_t stop();   event void stopDone(error_t error);  }

Error code here indicates how TinyOS completed processing the request

Error code here indicates how TinyOS started processing the request

Active Message interface

interface AMSend { command error_t send(am_addr_t addr, message_t * msg, uint8_t len); event void sendDone(message_t * msg, error_t error); command error_t cancel(message_t * msg); command uint8_t maxPayloadLength(); command void* getPayload(message_t * msg, uint8_t len); } interface Receive { event message_t* receive(message_t * msg, void * payload, uint8_t len); }

100

send is a Split-phase operation

Fired on another mote when packet arrives

interface Packet { command void clear(message_t * msg); command void* getPayload(message_t * msg, uint8_t len); command uint8_t payloadLength(message_t * msg); command void setPayLoadLength(message_t * msg, uint8_t len); command uint8_t maxPayloadLength(); }

Packet interface

101

interface AMPacket { command am_addr_t address(); command am_group_t localGroup(); command am_addr_t destination(message_t* amsg); command am_addr_t source(message_t* amsg); command am_group_t group(message_t* amsg); command bool isForMe(message_t* amsg); }

AMPacket interfaces Ø  For querying packets

102

Other networking interfaces

Ø  Default behavior: no ACKs Ø  Even with ACKs enabled, no automa9c retransmissions Ø  Op9onal packet link layer can handle retransmissions;

#define PACKET_LINK and see TEP 127

103

interface PacketAcknowledgements { async command error_t requestAck(message_t* msg); async command error_t noAck(message_t* msg); async command bool wasAcked(message_t* msg); }

Ac9ve Messaging

Applica9on

Message buffer ownership Ø  Transmission: Radio driver gains ownership of the buffer

un9l sendDone(...) is signaled Ø  Recep9on: Applica9on’s event handler gains ownership of

the buffer, but it must return a free buffer for the next message

104

msg msg

nx_ (network external) types Ø  Radio standards like 802.15.4 mean that you could have

communica9on among different types of motes with different CPUs

Ø  nesC defines network types (nx_uint16_t, nx_int8_t, etc.) that transparently deal with issues for you

Ø  nesC also defines an nx_struct analogous to C structs

105

typedef struct { uint16_t field1; bool field2; } bad_message_t; // Can have endianness problems // if sent to a host with a // different architecture

typedef nx_struct { nx_uint16_t field1; nx_bool field2; } good_message_t; // nesC will resolve endian // issues for you

Sending a Message Ø  First create a .h file with an nx_struct defining the

message data format, and a unique ac9ve message ID (127–255)

106

enum { AM_SENSORREADING = 240, }; typedef nx_struct sensor_reading { nx_int16_t temperature; nx_uint8_t humidity; } sensor_reading_t;

structure name

new type name

implementation { ... message_t output; task void sendData() { sensor_reading_t * reading = (sensor_reading_t *)call Packet.getPayload(&output, sizeof(sensor_reading_t)); reading-‐>temperature = lastTemperatureReading; reading-‐>humidity = lastHumidityReading; ... } }

Sending a Message Ø  Declare a message_t variable to store the packet’s contents Ø  Get the packet’s payload using the Packet interface

q  Note the sizeof() func9on q  Cast it to your message type

Ø  Set your data

107

Ø  Finally, use the AMSend interface to send the packet

task void sendData() { ... if(call AMSend.send(AM_BROADCAST_ADDR, &output, sizeof(sensor_reading_t)) != SUCCESS) post sendData(); // Try to send the message, and reschedule the task if it // fails (e.g., the radio is busy) }

Sending a Message

108

To all nodes

event void AMSend.sendDone(message_t * msg, error_t err) { if(err == SUCCESS) { // Prepare next packet if needed } else { post sendTask(); // Resend on failure } }

Sending a Message Ø  The AM subsystem will signal AMSend.sendDone() when

the packet has been completely processed, successfully or not

109

Ø  When messages with the correct AM ID are received, the Receive interface fires the receive() event

implementation { ... event message_t * Receive.receive(message_t * msg, void * payload, uint8_t len) { am_addr_t from = call AMPacket.source(msg); sensor_reading_t * data = (sensor_reading_t *)payload; ... return msg; } }

Receiving a Message

110

components new AMSenderC(AM_SENSORREADING); components new AMReceiverC(AM_SENSORREADING); MyAppP.AMSend -‐> AMSenderC; // AMSenderC provides AMSend interface MyAppP.Receive -‐> AMReceiverC; // AMReceiverC provides Receive interface MyAppP.Packet -‐> AMSenderC; MyAppP.AMPacket -‐> AMSenderC; // AMSenderC and AMReceiverC provide Packet and AMPacket // interfaces (pick one or the other)

Networking components Ø  Note that we didn’t men9on the packet’s AM ID anywhere in the code Ø  That’s because TinyOS includes generic components to manage the

AM ID for you when you send/receive:

111

Networking components Ø  Before you can send/receive, you need to turn the radio on Ø  ActiveMessageC component provides a SplitControl

interface to control the radio’s power state

Ø  Think about design when you have both radio and periodical sensing (how does your boot process should processed?)

112

components ActiveMessageC; MyAppP.RadioPowerControl -‐> ActiveMessageC;

What about Multi-‐Hop? Ø  Un9l recently, TinyOS did not include a general-‐purpose,

point-‐to-‐point mul9-‐hop rou9ng library Ø  Two special-‐purpose algorithms instead:

q  Collec9on Tree Protocol (CTP) q  Dissemina9on

Ø  Experimental TYMO point-‐to-‐point rou9ng library added to TinyOS 2.1 (hQp://docs.9nyos.net/index.php/Tymo)

Ø  blip: IPv6 stack added to TinyOS 2.1.1 (hQp://docs.9nyos.net/index.php/BLIP_Tutorial)

113

Collection Tree Protocol (CTP) Basic Opera9on

114

Collection Tree Protocol (CTP) Ini9alizing CTP

115

configuration MyCtpAppC { } implementation { components AppLogicP; components CollectionC; ... MyAppP.RoutingControl -‐> CollectionC; MyAppP.RootControl -‐> CollectionC; ... }

module AppLogicP { uses interface StdControl as RoutingControl; uses interface RootControl; ... } implementation { ... event void RadioControl.startDone( error_t err) { ... if(TOS_NODE_ID == 100) call RootControl.setRoot(); call RoutingControl.start(); } ... }

Collection Tree Protocol (CTP) Sending/Receiving Packets

116

configuration MyCtpAppC { } implementation { components AppLogicP; components CollectionC; ... MyAppP.Send -‐> CollectionC. Send[MY_MSG_ID]; MyAppP.Receive -‐> CollectionC. Receive[MY_MSG_ID]; MyAppP.Packet -‐> CollectionC; ... }

module AppLogicP { ... uses interface Send; uses interface Receive; uses interface Packet; ... } implementation { ... task void sendPacket() { result_t err = call Send.send( &msg, sizeof(MyMsg)); ... } event message_t * Receive.receive( message_t * msg, void * payload, uint8_t len) { // Only signaled on root node ... } }

Collection Tree Protocol (CTP) Ø  To link into your app, include these lines in your Makefile:

CFLAGS += -‐I$(TOSDIR)/lib/net CFLAGS += -‐I$(TOSDIR)/lib/net/4bitle CFLAGS += -‐I$(TOSDIR)/lib/net/ctp

Ø  CTP automa9cally turns on packet ACKs, retransmits up to 30 9mes at each hop q  But no end-‐to-‐end acknowledgments;

PacketAcknowledgments.wasAcked() only tells you if the packet made it to the first hop

117

Dissemination Basic Opera9on

118

For More Information Ø  TinyOS Tutorial 12: Network Protocols

(hQp://docs.9nyos.net/index.php/Network_Protocols) Ø  TEP 123: Collec9on Tree Protocol (hQp://www.9nyos.net/

9nyos-‐2.x/doc/html/tep123.html) Ø  TEP 118: Dissemina9on (hQp://www.9nyos.net/

9nyos-‐2.x/doc/html/tep118.html)

119

Sending Data to a PC Ø  TinyOS apps can also send or receive data over the serial/

USB connec9on to an aQached PC Ø  The SerialActiveMessageC component provides an Ac9ve

Messaging interface to the serial port: components SerialActiveMessageC; MyAppP.SerialAMSend -‐> SerialActiveMessageC.Send[AM_SENSORREADING]; MyAppP.SerialReceive -‐> SerialActiveMessageC.Receive[AM_SENSORREADING]; // SerialActiveMessageC provides parameterized AMSend and // Receive interfaces MyAppP.SerialPowerControl -‐> SerialActiveMessageC;

120

Interfacing With Motes Ø  TinyOS includes a Java-‐based SerialForwarder u9lity that

implements PC side of TEP 113 q  java net.tinyos.sf.SerialForwarder -‐comm

serial@[port]:[speed] q  [speed] may be a specific baud rate or a pla`orm name (e.g., telosb)

Ø  Listens on TCP port and sends/receives TinyOS messages from local or remote applica9ons

121

Interfacing With Motes Ø  Java SDK connects to SerialForwarder and converts TinyOS

messages to/from na9ve Java objects Ø  mig applica9on auto-‐generates these classes from your

app’s header files q  mig java -‐java-‐classname=[classname] [header.h]

[message-‐name] –o [classname].java

122

SomeMessage

OtherMessage

MoteIF . . .

SDK Support for Other Languages Ø  C/C++

q  C reimplementa9on of SerialForwarder (sf) and a few test apps found in $TOSROOT/support/sdk/c/sf

q  Building sf also builds libmote.a for accessing the motes in your own code

q  See sfsource.h and serialsource.h to get started

123

SDK Support for Other Languages Ø  Python

q  Python classes in $TOSROOT/support/sdk/python closely mirror Java SDK

q  Not completely stand-‐alone; Python MoteIF implementa9on talks to Java or C SerialForwarder

q  See tinyos/message/MoteIF.py to get started

Ø  C# q  mig can generate C# classes to parse/generate raw TinyOS packets q  But it’s up to the user to actually get those packets from the serial

port or SerialForwarder

124

CC2420Config Interface interface CC2420Config { command uint8_t getChannel(); command void setChannel(uint8_t channel);

async command uint16_t getShortAddr(); command void setShortAddr(uint16_t address);

async command uint16_t getPanAddr(); command void setPanAddr(uint16_t address);

command error_t sync(); event void syncDone(error_t error); }

125

(Provided by CC2420ControlC component)


126

Obtaining Sensor Data Ø  Each sensor has components that provides one or more

split-‐phase Read interfaces interface Read<val_t> { command error_t read(); event void readDone(error_t result, val_t val); }

Ø  Some sensor drivers provide addi9onal interfaces for bulk (ReadStream) or low-‐latency (ReadNow) readings q  See TEPs 101 and 114 for details

127

module MyAppP { uses interface Read<uint16_t> as AccelX; ... } implementation { ... task void readAccelX() { if(call AccelX.read() != SUCCESS) post readAccelX(); } event void AccelX.readDone(error_t err, uint16_t reading) { if(err != SUCCESS) { post readAccelX(); return; } // Handle reading here } ... }

configuration MyAppC { } implementation { components MyAppP; components new AccelXC(); // X axis accelerator component // defined by mts300 sensorboard MyAppP.AccelX -‐> AccelXC; ... }

Sensor Reading Example

128

Sensor Components Ø  Sensor components are stored in:

q  $TOSROOT/tos/platform/[platform] •  for standard sensors •  Note that telosb “extends” telosa, so look in both directories if

you’re using a TelosB or Tmote Sky mote! q  $TOSROOT/tos/sensorboard/[sensorboard]

•  for add-‐on sensor boards

Ø  Addi9onal sensor board components may be available from TinyOS CVS in tinyos-‐2.x-‐contrib q  Unfortunately, some third-‐party sensor board drivers have yet to

be ported from TinyOS 1.x to 2.x

129

External Sensors

130

interface HplMsp430GeneralIO { command void makeInput(); command void makeOutput(); command bool get(); command void clr(); command void set(); command void toggle(); }

External Sensors Ø  Digital I/O: wire directly into HplMsp430GeneralIOC component component HplMsp430GeneralIOC { provides interface HplMsp430GeneralIO as ADC0; provides interface HplMsp430GeneralIO as ADC1; provides interface HplMsp430GeneralIO as ADC2; provides interface HplMsp430GeneralIO as ADC3; provides interface HplMsp430GeneralIO as ADC4; provides interface HplMsp430GeneralIO as ADC5; provides interface HplMsp430GeneralIO as ADC6; provides interface HplMsp430GeneralIO as ADC7; provides interface HplMsp430GeneralIO as DAC0; provides interface HplMsp430GeneralIO as DAC1; ... }

Ø  I2C: read TEP 117 (Low-‐Level I/O) Ø  Analog I/O: read TEP 101 (Analog-‐to-‐Digital Converters)

131


132

Hard-‐Learned Lessons Ø  Be sure to check return values -‐-‐ don’t assume SUCCESS!

q  At the very least, set an LED when something goes wrong

Ø  The TinyOS toolchain doesn’t always warn about overflowing integers

Ø  Not all the Tmote Sky motes have sensors

133

uint8_t i; for(i = 0; i < 1000; i++) { ... } // This loop will never terminate

msp430-‐gcc Alignment Bugs Ø  If you’re unlucky, msp430-‐gcc will crash with internal

errors like these:

Ø  It’s almost always because of alignment bugs (msp430-‐gcc doesn’t always like it when fields straddle 16-‐bit boundaries)

134

/opt/tinyos-‐2.x/tos/interfaces/TaskBasic.nc: In function `SchedulerBasicP$TaskBasic$runTask': /opt/tinyos-‐2.x/tos/interfaces/TaskBasic.nc:64: unable to generate reloads for: (call_insn 732 3343 733 (set (reg:SI 15 r15) (call (mem:HI (symbol_ref:HI ("AsyncQueueC$1$Queue$dequeue")) [0 S2 A8]) (const_int 0 [0x0]))) 14 {*call_value_insn} (nil) (nil) (nil)) /opt/tinyos-‐2.x/tos/interfaces/TaskBasic.nc:64: Internal compiler error in find_reloads, at reload.c:3590 typedef nx_struct my_msg

{ nx_uint8_t field1;

nx_uint16_t field2;

} my_msg_t;

nx_uint8_t pad;

802.15.4 Radio Channels

Ø  The CC2420 chip on the Tmote and MicaZ supports 802.15.4 channels 11 -‐ 26

Ø  802.15.4 uses 2.4 GHz spectrum Ø  This can lead to interference between motes and with 802.11,

Bluetooth, and all sorts of other things

135

802.15.4 Radio Channels

136

802.15.4 Radio Channels Ø  If you’re seeing weird network behavior, set your CC2420

channel to something else: q  Defaults to 26 q  Command-‐line: CC2420_CHANNEL=xx make [platform] q  Makefile: PFLAGS = -‐DCC2420_DEF_CHANNEL=xx

137

Active Message Groups Ø  To avoid address collision with other applica9ons or

networks, you can also change the AM group: q  Defaults to 0x22 q  Makefile: DEFAULT_LOCAL_GROUP=xx (any 16-‐bit value)

Ø  On 802.15.4 compliant chips, maps to PAN ID

Ø  Does not prevent physical interference of packets: only instructs radio chip/driver to filter out packets addressed to other groups

138

LEDs Ø  The easiest way to display run9me informa9on is to use

the mote’s LEDs: interface Leds { async command void led0On(); async command void led0Off(); async command void led0Toggle(); async command void led1On(); async command void led1Off(); async command void led1Toggle(); async command void led2On(); async command void led2Off(); async command void led2Toggle(); async command uint8_t get(); async command void set(uint8_t val); }

Ø  Provided by the components LedsC and NoLedsC

139

printf() Ø  You can use printf() to print debugging messages to the

serial port Ø  Messages are buffered and sent to serial port in bulk;

printfflush() asks TinyOS to flush buffer

Ø  DON’T USE printf() FOR CRITICAL MESSAGES Ø  When its buffer fills up, printf() starts throwing away

data

140

printf() Ø  To enable the printf library, add the following line to your

Makefile:

CFLAGS += -‐I$(TOSDIR)/lib/printf Ø  Note: this automa9cally turns on SerialActiveMessageC

subsystem

Ø  Included PrintfClient u9lity displays printed messages to console java net.tinyos.tools.PrintfClient [-‐comm serial@[port]:[speed]]

141

BaseStation Ø  The BaseStation app in $TOSROOT/apps/

BaseStation will sniff all wireless traffic and forward it to the serial port

Ø  Listen tool prints hex-‐dump of packets to console: java net.tinyos.tools.Listen [-‐comm serial@[port]:[speed]]

Ø  Extremely helpful for figuring out what data is being sent!

142

gdb Ø  The CPU on the Tmote Sky motes supports interac9ve

debugging using gdb Ø  Set breakpoints, inspect the contents of variables, etc.

Ø  The catch: it needs a special cable and modified motes -‐-‐ and they don’t make the motes anymore q  We have 5 motes and one cable

143

TOSSIM Ø  make micaz sim compiles applica9on to na9ve C code for

your own machine, which can be loaded into Python or C++ simulator (“TOSSIM”)

Ø  Good way to rapidly test applica9on logic, at the cost of some realism q  e.g., does not emulate sensing and does not reproduce 9ming of

real microcontrollers

Ø  Besides app code, need two configura9on details: q  Topology of simulated network q  Noise trace from simulated environment

144

TOSSIM ConRiguration: Topology

Ø  List of links in the network and associated gain (signal strength in dBm)

Ø  Several sources: q  Real measurements q  Samples included in TinyOS ($TOSDIR/lib/

tossim/topologies) q  Generate one based on various parameters

(hQp://www.9nyos.net/ 9nyos-‐2.x/doc/html/tutorial/usc-‐topologies.html)

145

0 1 -‐90.80 1 0 -‐95.95 0 2 -‐97.48 2 0 -‐102.10 0 3 -‐111.33 3 0 -‐115.49 0 4 -‐104.82 4  0 -‐110.09 ...

(from 15-‐15-‐sparse-‐mica2-‐grid.txt)

TOSSIM ConRiguration: Noise Trace

Ø  Trace of ambient noise readings in dBm Ø  Must contain at least 100 entries; more

is beQer, but RAM consump9on increases with larger traces

Ø  Two sources: q  Real measurements q  Samples included in TinyOS ($TOSDIR/lib/

tossim/noise)

146

-‐39 -‐98 -‐98 -‐98 -‐99 -‐98 -‐94 -‐98 ...

(from meyer-‐heavy.txt)

Other TOSSIM Features Ø  Log debug messages to console or to a file Ø  Inject packets into network Ø  Debugging support

q  Python TOSSIM: read variables’ contents q  C++ TOSSIM: use gdb

Ø  TOSSIM Live fork: TOSSIM acts as SerialForwarder, send/receive serial packets to simulated motes q  hQp://docs.9nyos.net/index.php/TOSSIM_Live

Ø  See TinyOS Tutorial 11 for more details

147

Avrora + MSPsim Ø  Avrora: cycle-‐accurate Mica2 and MicaZ emulator

hQp://compilers.cs.ucla.edu/avrora/

Ø  MSPsim: MSP430 (TelosB) emulator hQp://www.sics.se/project/mspsim/

Ø  Profile and benchmark apps, monitor packet transmissions, or interface with gdb

Ø  Slower than TOSSIM, but highly accurate

148

Safe TinyOS Ø  New in TinyOS 2.1: make [platform] safe Ø  Augments code to enforce pointer and type safety at

run9me (bad casts, out-‐of-‐bounds array accesses, NULL pointer dereferences, etc.)

Ø  When safety viola9ons detected, LEDs blink error code

Ø  hQp://www.cs.utah.edu/~coop/safe9nyos/ Nathan Cooprider, Will Archer, Eric Eide, David Gay, and John Regehr, “Efficient Memory Safety for TinyOS,” Proceedings of 5th ACM Conference on Embedded Networked Sensor Systems (SenSys 2007), 2007.

149

Demo: Putting it All Together

150

Demo Example Ø  See the zip file on the course site

151

rahav tinyos-lectures 2014lu/cse467s/slides/tinyos... · 2014. 1. 28. · detached from the hive....

Documents