Motes: Prototype Embedded Sensors

1
Motes Prototype Embedded Sensors
http//lecs.cs.ucla.edu/vladimir/pub/motetalk_jan
16.ppt

• CS213
• January 16, 2003
• slides by Vladimir Bychkovskiy

some pictures are borrowed from other
presentations
2
Philosophy

• Why Motes?
• Prototyping platform for 1mm2 sensors
• Hardware MICA mote
• Atmel ATMEGA103
• 4 Mhz 8-bit CPU
• 128KB Instruction Memory
• 4KB RAM
• 4 Mbit flash (AT45DB041B)
• SPI interface
• 1-4 uj/bit r/w
• RFM TR1000 radio
• 50 kb/s ASK
• Future goal
• Mote-on-chip

3
Capabilities

• Motes can
• blink LEDs
• send/receive short (30-200B) radio messages
• communicate with PC over a serial port
• with additional hardware
• sample digital and analog sensors
• temperature, light, pressure, etc.
• emit acoustic noise
• control a small robot
• Some successful projects
• simplified Directed Diffusion routing
• MoteNIC mote as a radio
• RoboMote a robotic chassis for a mote
• simplified ASCENT topology adaptation
• acoustic localization
• synchronized sensor sampling

4
Limitations

• Only 4MHz
• radio-handling is the only real-time task
• a bit every 50 uS _at_ 19Kbps
• ex radio was turned off during acoustic signal
  emission
• Only 4KB of RAM
• system variables buffers take up to 2KB
• Only 3 hardware timers
• The only real-time timer used by the radio
• need software demultiplexing gt jitter
• Result
• Only one serious application per mote
• Real-time functionality needs to be integrated
  with OS

5
Software Support for Motes

• TinyOS (J. Hill D. Culler)
• first in, first out (FIFO) task scheduler
• device drivers
• ADC, Radio, EEPROM, external senor boards
• communication stack
• PHY/MAC, CRC, DC-Balancing
• Active Messages demultiplexing layers

6
Scheduling

• Almost all system calls are asynchronous
• Program is an explicit state machine
• Execution scheduling
• Interrupts, for real-time processing
• Tasks, delayed execution (bottom-half handler)
• Caveat some times it is impossible to schedule a
  task

7
Procedure-based vs. Event-based

• while( )
• sleep()
• datareadSensor()
• msgrecvMsg()
• newData
• combine(msg.data, data)
• sendMsg(newData)

• init() setTimer()
• timerExpired() startReadSensor()
• doneReadSensor(int data)
• newDatacombine(data, ext_data)
• startSendMsg(newData)
• doneSendMsg()
• // free up memory
• msgRecvd(Msg msg)
• ext_datamsg.data

8
TinyOS Component Stack
sensor application
application
Active Messaging Layer
Serial Packet
Radio Packet
packet
temp
photo
Software
Hardware (device drivers)
UART
Radio byte
ADC
byte
clocks
RFM
bit
comm. stack
based on a diagram from jan02 retreat slides by
D. Culler
9
Timing diagram of event propagation
diagram from TinyOS Overview slides by J. Hill
10
Debugging Applicationson Motes

• Means for debugging
• LED debugging
• pro easy to use, do not change timing
• con only 8 states, hard to track changes of
  states
• UART debugging
• pro can do printf
• con
• drastically changes timing of events
• can not use in interrupt context
• not available if application uses it for
  communication

11
FIFO Scheduler and Ordering of Events

• Must be very careful when posting tasks based on
  some conditions
• By the time the new task gets to run, the
  condition may have changed
• Example
• Task A
• if (a0)
• POST_TASK(C)
• Task B
• a1
• Task C
• blink_red_led()
• Task C should run immediately after task A
• Not always the case! (non-preemptive FIFO)

12
TinyOS Philosophy

• Work around hardware limitations
• avoid doing extra work
• no memory management ( malloc(), free() )
• pass fixed buffer directly b/w components instead
• con potential race conditions
• do as much as possible at compile time
• no dynamic binding ( static callbacks )
• con loss of flexibility, convoluted code
• take advantage of a smart compiler (NesC)
• automatic function in-lining to save stack memory