Announcement
 Teams for course projects have been announced
 8 teams formed by students themselves
 2 randomly assigned teams
 http://web.eecs.utk.edu/~weigao/ece455/fall2015/project_tea
m.html
 Next milestone: project proposal & presentation
 9/14 and 9/16
 Make appointment and discuss your project ideas with me
 10-minute presentation each group
• What are you planning to work on?
• Major objectives / Design challenges / Experimentation plan
 Submit your 1-page proposal document before presentation
 Lab will start this Wednesday 9/2
 Each student should check in with the TA and get one TelosB
mote
ECE 455/555 Embedded System Design
1
ECE 455/555
Embedded System Design
TinyOS Introduction
Wei Gao
Fall 2015
2
Hardware Evolution
 Miniature hardware devices manufactured
economically in large numbers
 Microprocessors
 MEMS sensors/actuators
 Wireless communication
Smart Dust
5’’X3’’
1’’X1’’
1 mm2
ECE 455/555 Embedded System Design
1 nm2
3
MEMSIC TelosB
 Processor
 MSP430: 16 bit RISC, bus 8 MHz
 Memory: 10KB data, 48 KB program
 Radio
 IEEE 802.15.4, Max 250 Kbps, up to
75m outdoor
 Sensors
 light, temperature, humidity
 Power
 Days of lifetime on two AA batteries in regular mode
 > 1 year battery life using sleep modes!
ECE 455/555 Embedded System Design
4
Hardware Constraints
 Severe constraints on power, size, and cost 
 Slow processor
 Short-distance, low-bandwidth radio
 Limited memory
 Limited hardware parallelisms
• CPU hit by many interrupts!
 Support sleep modes in hardware components
ECE 455/555 Embedded System Design
5
Software Challenges
 Small memory footprint
 Efficient in power and computation
 Support concurrency-intensive operations
 Real-time
 Diversity in applications and design  efficient modularity
 Support reconfigurable
hardware and software
ECE 455/555 Embedded System Design
6
TinyOS Solutions


Support concurrency: event-driven architecture
Modularity: application = scheduler + graph of components
 Compiled into one executable
 Efficiency: Get done quickly and sleep
 Event/command = function calls
 Fewer context switches: FIFO/non-preemptable scheduling
 No kernel/application boundary: completely open-source
Main (includes Scheduler)
Application (User Components)
Actuating
Sensing
Communication
Communication
Hardware Abstractions
Modified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001
ECE 455/555 Embedded System Design
7
Two-level Scheduling

Tasks do intensive computations
 Scheduler is simple FIFO, tasks don’t preempt each other

Events handle interrupts
 Interrupts trigger lowest level events
 Events can signal events, call commands, or post tasks
 Event can preempt each other, once enabled

Two priorities: events and tasks,
 Events can preempt tasks
POST
events
main {
…
while(1) {
while(more_tasks)
schedule_task;
sleep;
}}
Tasks
Preempt
FIFO
commands
commands
Interrupts
Hardware
ECE 455/555 Embedded System Design
Time
8
Scheduling Policies
 An interrupt preempts a task
 A task cannot preempt another task
 First-In-First-Out (FIFO)
 Scheduler puts processor to sleep when
 no event/command is running and
 task queue is empty
ECE 455/555 Embedded System Design
9
TinyOS Programming: nesC
 Programming language for TinyOS and applications
 Support TinyOS components and event/command
interfaces
 Whole-program analysis at compile time
 Detect race conditions
 Optimizations, e.g., function inlining
 Static language
 no malloc, no function pointers
 Function call graph and variable access are known at
compile time
ECE 455/555 Embedded System Design
10
Application Development
 Component model
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;
ECE 455/555 Embedded System Design
11
nesC Programming model
 Component model
 An application consists of
Application
Component
D
wired components
Component
A
 Application = graph of
components
 Components are wired
through interfaces
 Wiring specified by
configurations
configuration
 Configuration can be
hierarchical
Component
C
Component
B
Component
F
Component
E
ECE 455/555 Embedded System Design
configuration
12
Interfaces
 List of exposed events and commands
 Like ordinary C function declarations
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);
}
 command needs to implemented by components
providing the interface
 event needs to be handled by components using the
interface
ECE 455/555 Embedded System Design
13
Modules
 Modules provide the implementation of interfaces
 Modules or configurations are used in another application
as components
 They may use interfaces provided by other modules
module ExampleModuleP {
provides interface SplitControl;
uses interface Receive;
uses interface Receive as OtherReceive;
}
implementation
{
...
}
 “Rename” interfaces with the as keyword: use multiple
interfaces of the same type
ECE 455/555 Embedded System Design
14
An Example: Surge
module SurgeP {
provides interface StdControl;
Boot
uses interface ADC;
uses interface Timer;
StdControl.start ADC.get
ADC
uses interface Send;
Component
Data
}
SurgeP
implementation {
bool busy; norace uint16_t sensorReading;
Timer.fired
Timer
async event result_t Timer.fired() {
bool localBusy;
Component
Event handler
atomic {
localBusy = busy;
busy = TRUE;
}
if (!localBusy)
call ADC.getData();
Calling command
return SUCCESS;
}
async event result_t ADC.dataReady(uint16_t data) {
...
}
command error_t StdControl.start() {
Command specified in StdControl
...
is implemented
}
}
ECE 455/555 Embedded System Design
15
Surge
ECE 455/555 Embedded System Design
16
Hierarchical structure
 Component TimerC
ECE 455/555 Embedded System Design
17
A Simple Example: Blink
 Blink: a simple LED toggler
 /opt/tinyos-2.x/apps/Blink
 Toggling the 3 on-board LEDs at different frequencies
 Configuration file: BlinkAppC.nc
 Module file: BlinkC.nc
ECE 455/555 Embedded System Design
18
Blink Configuration
/opt/tinyos-2.x/apps/Blink/BlinkAppC.nc
Events
Events
configuration BlinkAppC
{
}
implementation
{
components MainC, BlinkC, LedsC;
commands components new TimerMilliC() as Timer0;
components new TimerMilliC() as Timer1;
components new TimerMilliC() as Timer2;
BlinkC -> MainC.Boot;
You need to: Handle all events in the
components you use
Commands provided by a component
are implemented in that component
BlinkC.Timer0 -> Timer0;
BlinkC.Timer1 -> Timer1;
BlinkC.Timer2 -> Timer2;
BlinkC.Leds -> LedsC;
}
ECE 455/555 Embedded System Design
19
Blink Module
/opt/tinyos-2.x/apps/Blink/BlinkC.nc
Start timer in numbers
of miliseconds
module BlinkC @safe()
{
uses interface Timer<TMilli> as Timer0;
uses interface Timer<TMilli> as Timer1;
uses interface Timer<TMilli> as Timer2;
uses interface Leds, Boot;
}
implementation
{
event void Boot.booted()
{
call Timer0.startPeriodic( 250 ); call Timer1.startPeriodic( 500 );
call Timer2.startPeriodic( 1000 );
}
event void Timer0.fired()
{
dbg("BlinkC", "Timer 0 fired @ %s.\n", sim_time_string());
call Leds.led0Toggle();
}
event void Timer1.fired()
{
//similar to Timer 0
}
event void Timer2.fired()
{
//similar to Timer 0
}
}
ECE 455/555 Embedded System Design
20
Principles Revisited
 Write TinyOS components: interface, modules,
configuration
 Whole-program analysis
 Enforce global properties (e.g. no race conditions)
 Optimization, e.g., inlining
 “Static language”
 no malloc, no function pointers
ECE 455/555 Embedded System Design
21
Next class
 Android installation & introduction
 You may want to use Android smartphones for your
course projects
 You are encouraged to bring your own smartphone
to course projects
ECE 455/555 Embedded System Design
22