Imote2 and TinyOS programming

1. Imote2 and TinyOS programming Tomonori Nagayama Assistant Professor University of Tokyo 07/10/2009

2. Intel Imote2 • Wireless sensor platform designed for data intensive applications (e.g. SHM) • Processor: PXA271 • 13MHz – 416MHz • Deep sleep (0.1mW) • SRAM 256 KB • Fixed point math • SDRAM 32MB • FLASH 32MB • RF: ChipCon CC2420 (802.15.4) 250 kbps • Chip antenna & optional SMA antenna connector • Mini-USB connector • PMIC (Power Management IC) • Sensor board connectors • Basic connector (top) & advanced connector (bottom) • OS: TinyOS, SOS, Linux etc.

3. Comparative advantage of Imote2 • Potentially accurately synchronized sensing • Data processing capability • Open HW/SW

4. networking SHM applications data aggregation Middleware sensing OS CPUMemory Sensor/actuator RF Power Hardware

5. CC2420 RF chip on the Imote2 • Single-chip 2.4 GHz 802.15.4 compliant RF transceiver designed for low-voltage wireless application • 250kbps data rate • Low power consumption • Rx: 18.8mA, Tx: 17.4mA @ (2.1-3.6 V) • Frequency range 2400-2483.5MHz • Programmable in 1MHz steps, 16Ch • Output power -24 to 0 dBm • Receiver sensitivity -95 dBm

6. 2 Antenna Types Onboard Peak Gain ~ 1.8 dBi External Peak Gain ~ 2.2 dBi Communication Options: Communication Channel, Transmission Power Imote 2 Antenna Options

7. Communication Range • Set of loopback tests were conducted in an open field • Environmental factors were kept to a minimum and no 2.4 GHz networks were present • Quantitative performance measure was reception rate – the number of packets received of the number that were sent

8. Communication Range Onboard Antenna • The range depends on the circumstances. 30m on the data sheet. Shorter under certain circumstances. • About 30 m when installed on a steel girder. • About 170 m when one node is installed on a bridge tower. External Antenna

9. Packet collisions • Packet collision • Packet collision is dealt with at lower level. Packet experiencing collision are detected by TinyOS (ex. Cyclic Redundancy Check) and discarded. For users, packet collision is packet loss. • Random backoff • When a packet is transmitted, the channel clearance check is performed. If not clear, wait for a random period of time and try to transmit again

10. Packet structure • typedef struct TOS_Msg • { • uint8_t length; • uint8_t fcfhi; • uint8_t fcflo; • uint8_t dsn; • uint16_t destpan; • uint16_t addr; • uint16_t srcpan; • uint16_t srcaddr; • uint8_t type; • uint8_t group; • int8_t data[28]; • …. } • Active message • Defined at $TOSROOT/beta/platform/imote2/AM.h • 14 byte header + 28 byte payload • You can increase the payload up to 116 B. header payload

11. Packet transfer • Broadcast and unicast • Broadcast: 1-to-”others in the range” • Unicast: 1-to-1 • Specify the destination by node ID • Basically broadcast, but others ignore. Broadcast Unicast

12. USB plug Powering option Pads • PMIC allows 4 options • Primary Battery • Rechargeable battery • USB Plug • Pads on the Imote2 Battery board

13. Powering option • Supply voltage requirement • 3.2-4.5V when nCHARGE_EN PIN position is 1 • 3.2-4.5V from the battery board and 4.6-10 V from USB and Pads on the Imote2 when nCHARGE_EN PIN position is 2

14. Crossbow battery board • Holds 3xAAA • Maximum current 500mA • If the supply voltage is above 4.7V, safety circuit shut off the power supply • Imote2 can be connected via either the basic connectors or the advanced connectors.

15. Powering option for sensor boards • “VBAT” and “GND” are available on pins on the connectors. 1.8V and 3.0V regulated power is also available (max 200mA) 1.8 & 3.0V VBAT and GND

16. Power consumption • Power consumption too large? • Efficient duty-cycle operation reduce power consumption • Impossible with slower CPU nodes. If possible, such nodes end up in long-duty cycle operation. • Advance in battery/energy harvesting technology • Market growth in cellphone/netbook/laptop motivates development of low-power consumption/high performance CPU Ref. IRIS 25mA, MicaZ 32mA, Mica2Dot 16mA

17. System2 Solar panel + Li-ion polymer battery. Power Management IC on the Imote2 is utilized to efficiently store energy on the batteries. System1 Solar panel + NiMH battery Commercially available solar panel + USB adapter. large standby power requirement (being modified to have no standby power requirement) Solar panel

18. ITS400 sensor board • 3-axis Accelerometer • STMicro LISL02DQ Digital accelerometer ±2gResolution ~1mgSampling frequency 280, 560, 1120, 4480Hz • Temperature, humidity, and light sensors • 4 ch 12-bit ADC • Power consumption 1mA @ 3.3V • Relatively large variation in sensitivity, sampling rate, offset, time delay

19. Data sheet

20. Individual difference in fs ITS400 sensor board • Digital accelerometer LISL02DQ :easier for development but does not have sufficient characteristics • Resolution • Sampling timing • Inflexible sampling rate/filter • Large variation in sensitivity/offset

21. SHMA sensor board • 3-axis Accelerometer • STMicro LISL02AL (analog) ±2gnoise level 20-50mg/sqrt(Hz) • Quickfilter • 4-ch, 16-bit ADC with analog/digital filters • Power consumption ~200mW • Accurate sampling rate, small time delay • Relatively large variation in sensitivity, offset 20 MHz Crystal Imote2 Single-pole RC Low-pass AA Filter fc = 1500 Hz 16-bit Analog-to-Digital Converter Op. Amplifier 3-axis Analog Accelerometer SPI Interface Quickfilter = AA filter + ADC + Digital filters

22. OS • The Imote2 works on several operating systems including, TinyOS 1, TinyOS 2, .Net, Linux, SOS. • Many software codes (e.g. drivers and middleware) have been developed on the TinyOS 1. • TinyOS is suitable for low power consumption and small memory footprint applications.

23. TinyOS programming

24. TinyOS Open-source operating system for wireless embedded sensor networks • A component based (modular) operating system • Common abstractions such as packet communication, routing, sensing, actuation, and storage are provided as components. • Components are connected with each other through interfaces. • Component library can be used as-is or be customized. • Written in the nesC language • nesC: a dialect of the C programming language with the support for components. • Lightweight (program size, memory footprint) as small as 400B

25. TinyOS Open-source operating system for wireless embedded sensor networks • Event-driven • Program flow is determined by events • Supports concurrency • Multiple things seem to be happening simultaneously (clock, radio, uart, sensing, etc) • Free & open source • >500 groups are using TinyOS. • Many are actively contributing code. • Ported to over a dozen platforms

26. Brief view on TinyOS directories /TOSROOT apps/ applications beta/ beta contrib/ contributed files doc/ documentation including tutorials tools/ java file and others tos/ tinyos related files. e.g. interface, system, library, sensor boards etc. ISHMP directory includes files developed at UIUC Imote2 related files

27. IF1 interface IF Comp. A component Comp. IF2 IF3 command IF2 IF3 event Comp. B Comp. C Components • A nesC application consists of components linked together to form an executable • Components provide and use interfaces • Interface • declares a set of functions called commands and events. • Commands are implemented by the component providing the interface • Events are implemented by the component using the interface

28. Components • A nesC application consists of components linked together to form an executable • Two types of components • Modules • Provide application code, implementing interfaces • Configurations • Assemble other components together, connecting interfaces used by components to interfaces provided by others (wiring) • One top-level configuration Comp. (module)pseudo-code Define interface 2; Define …. Comp. (configuration) pseudo-code Wire (connect) interface 3 of Comp. C to that of Comp. D Wire …

29. Components • A nesC application consists of components linked together to form an executable (continued) • Three types of files: modules, configurations, and interfaces • You can make your own component/interface or use those provided (see $TOSDIR/interfaces, $TOSDIR/system, $TOSDIR/platform, etc.) • Filename should be component/interface name + “.nc”

30. Blink application Consists of a few components Blinks periodically Interface provided by the lower level components are used by upper level interface. Example – Blink application Located at $TOSROOT/apps/Blink Main StdControl component interface command StdControl event BlinkM Leds Timer Leds Timer StdControl LedsC SingleTimer

31. Interface • Declares a set of functions called commands and events. They are defined (implemented) in module files. • Interfaces are the only point of access to the component and are bi-directional • A single component may use/provide multiple interfaces and multiple instances of the same interface. • Naming convention • Nouns, in mixed case with the first letter of each internal word capitalized. • Ex. Timer.nc, Leds.nc, … interface file format interface IFNAME{ command datatypeCMDNAME(ARGTYPE ARG); event datatypeEVTNAME(ARGTYPE ARG); //list of commands and events follows }

32. Example – interfaces in Blink application • Interface StdControl, Timer • $TOSROOT/tos/interfaces/StdControl.nc • $TOSROOT/tos/interfaces/Timer.nc 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(); }

33. Configuration configuration file format • Configurations wire components together • All the components involved (including “Main” ) need to be listed after “components” keyword. • The common interface of a provider and user are connected by arrow. • (user).(interface) -> (provider).(interface) or (provider).(interface) <- (uer).(interface) You can omit “.interface” of the provider if apparent. • One user interface can be wired (fanned out) to multiple provider interfaces. • Configuration file name is usually xxxC.nc or xxx.nc configuration CFNAME{ } Implementation{ components Main, component1, component2, …, component K; Main.StdControl -> component1.StdControl; component1.ifname1->component2.ifname1; component3.ifname2<-componentK; … } “Main”: only for the top level configuration List of components wiring • Only one top-level configuration which is specified in the make file. • Main.StdControl always needs to be wired in the top configuration file.

34. Configuration configuration file format • You can give local names to components so that you can easily swap components. • Configuration can provide interfaces. • Using “=“, configurations can bounce the responsibility to other components which actually provide interfaces or which again bounce the responsibility configuration CFNAME{ provides interface IFNAME; } Implementation{ components Main, component1 as XXX, component2 as YYY, …, component K as ZZZ; Main.StdControl -> XXX; XXX.ifname1->YYY; IFNAME=ZZZ; } Local name using “as” configuration file providesinterface using “=“

35. Blink application Consists of a few components Blinks periodically Interface provided by the lower level components are used by upper level interface. Example – Blink application Main StdControl component interface command StdControl event BlinkM Leds Timer Leds Timer StdControl LedsC SingleTimer

36. Blink application $TOSROOT/apps/Blink Related files: Blink.nc, BlinkM.nc, SingleTimer.nc, Makefile List of components “components LIST” Configuration name “configuration NAME” Wiring “->” StdControl interface is provided by BlinkM component and used by Main component. Short for “BlinkM.Leds-> LedsC.Leds Example - configuration • Configuration file  wire modules Blink.nc (configuration file) configuration Blink { }implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; } • – User.interface -> Provider.interface • – Provider.interface <- User.interface

37. Wiring to multiple components Single user can be wired to multiple providers StdControl interface is also provided by SingleTimer component and used by Main component. Example – fan out Blink.nc (configuration file) configuration Blink { }implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; }

38. Blink application Consists of a few components Blinks periodically Interface provided by the lower level components are used by upper level interface. Example – Blink application Main StdControl component interface command StdControl event BlinkM Leds Timer Leds Timer StdControl LedsC SingleTimer

39. Configuration file can provide interfaces “=“ bounces responsibilities. Interfaces in configuration can be provided by other component using “=“ Timer is actually provided by TimerCStdControl is provided in TimerC Example – configuration providing interfaces SingleTimer.nc configuration SingleTimer { provides interface Timer; provides interface StdControl; } implementation { components TimerC; Timer = TimerC.Timer[unique("Timer")]; StdControl = TimerC; }

40. Module Module file format module MODULENAME{ provides interface IFNAME; users interface IFNAME; } Implementation{ //main body of the module //implement provided and used interfaces } • Module file name is usually xxxM.nc • Interfaces provided and used must be implemented in the “implementation” block • Multiple interfaces can be provided and used • Commenting • Characters after “//” and those between “/*” & “*/” are considered comments • When more than one interface is provided or used, change • provides/users interface IFNAME; • to • provides/uses { • interface IFNAME1; • interface IFNAME2; • …} • or • provides/users interface IFNAME1; • provides/users interface IFNAME2;

41. Module file implementation Module name “module NAME” interface declaration Example - module BlinkM.nc (module file) module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } (BlinkM.nc continued) command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.yellowToggle(); return SUCCESS; } } The beginning of implementation

42. Module inside “implementation{…}” • Command and event implementation (similar to function definition) • Module must implement commands of interfaces this module provides • Module must implement events of interfaces this module uses • call and signal commands/events (similar to function call) • Module can call commands of interfaces this module uses call IFNAME.CMDNAME(ARGTYPEARG); • Module can signal events of interfaces this module provides signal IFNAME.CMDNAME(ARGTYPEARG); • Commands and events of the interface are declared in the interface file command datatypeIFNAME.CMDNAME(ARGTYPE ARG) { //command implementation return RTNVALUE; } event datatypeIFNAME.EVTNAME(ARGTYPE ARG) { //event implementation return RTNVALUE; }

43. Module file implementation Example - module StdControl.nc (Interface file)interface StdControl {   command result_t init();   command result_t start();   command result_t stop();} All commands of provided interfaces needs to be implemented (defined) BlinkM.nc (module file) module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } (BlinkM.nc continued) command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.yellowToggle(); return SUCCESS; } }

44. Module file implementation Example - module All events of used interfaces needs to be implemented (defined) Timer.nc (Interface file)interface Timer {   command result_t start( char type, unit32_t interval);   command result_t stop();   event result_t fired(); } BlinkM.nc (module file) module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } (BlinkM.nc continued) command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.yellowToggle(); return SUCCESS; } } Leds.nc (Interface file)interface Leds {   async command result_t init();   async command result_t redOn(); async command result_t redOff(); (no event) }

45. Module • Interfaces can be given instance names • to have multiple instances of the same interface, to clarify the interface role by its name, or for other purposes • when the instance name is omitted, instance name is assumed same as the interface name. • File naming convention • Nouns, in mixed case with the 1st letter of each word capitalized. • Terminates with “M” • Ex. TimerM, UARTM interface IFNAME as ISNAME; interface IFNAME as ISNAME2; “interface IFNAME;” is same as “interface IFNAME as IFNAME;”

46. Concurrency model • Event driven programming • As opposed to batch programming where the execution flow is determined by the programmer, the flow of event-driven programming is determined by events. (Ref. Wikipedia) Batch version pseudocode to add two numbers read a number (from the keyboard) and store it in variable A[0] read a number (from the keyboard) and store it in variable A[1] print A[0]+A[1] Event-driven version pseudocode set counter K to 0 repeat { whenever a number has been entered (from the keyboard){ //keyboard-number event store in A[K] and increment K // keyboard-number handler } if K equals 2{ // ready-to-sum event print A[0]+A[1] and reset K to 0 // ready-to-sum handler } }

47. Concurrency model • Two threads of execution: • Task • Declared as task void taskname(){…};Dispatched as post taskname(); • The post operation places the task on an internal task queue which is processed in FIFO order. • Once scheduled, they run to completion and do not preempt one another (FIFO). Preempted by hardware event handler. • used to perform general-purpose "background" processing in an application • Hardware event handler • Executed in response to a hardware interrupt. • May preempt the execution of a task or other hardware event handler. • Commands and events that are executed as part of a hardware event handler must be declared with the async keyword. • Hardware event handler should be short. Time consuming calculations should be performed as tasks.

48. Concurrency model • Most of program code application users need to edit is in tasks. • Hardware event handlers are likely already implemented. These handlers may post tasks to perform non-time-critical operations. Most application users edit these tasks. • Time synchronization related programs may require modification of hardware event handler • Not a real time system • soft real-time system • The hardware event handler has priority over the task Ref. A hard real-time system: guarantee that critical real time tasks be completed within their deadlinesA soft real-time system: critical real-time task will receive priority over other tasks.

49. Execution flow • When the mote starts up, Main.StdControl.init() and then Main.StdControl.start() are called. Lines defined in the corresponding command implementation are executed. • When hardware events (RF receive, timer firing, etc) happen, corresponding hw event handlers are called and operations described in the implementation are performed. • Tasks posted are executed in FIFO order after the handler operations are all completed. • Commands and events execution is just like normal functions: when function is called, the flow goes to the called function. The flow comes back with the return value. • When tasks are posted, the task is placed on an internal task queue and the flow comes back. The body of the task is executed after the caller’s execution is completed.

50. Blink application flow Execution flow – example- Main.StdControl.init(); Main.StdControl.start(); + Event driven BlinkM.nc (module file) module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } (BlinkM.nc continued) command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.yellowToggle(); return SUCCESS; } }