DOC PREVIEW
Duke CPS 296.1 - Programming Platform for Sensor Networks: TinyOS

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Programming Platform for Sensor Networks: TinyOSJun YangCPS 296.1, Spring 2007Sensor Data ProcessingWith contents from D.-O. Kim, D. Culler, W. Xu2Announcements (Feb. 27) Course project milestone 1 this Thursday I need to know your team members and project ideas 10% of total grade Reading for next Tuesday: MauveDB (review due) Next Thursday (Mar. 8): project proposal talk 15 minutes per group; 20% of total grade What is it? Why do we care? Hasn’t it been done before? Plans, thoughts, and preliminary results?3Challenges in programming sensors WSN usually has severe power, memory, and bandwidth limitations WSN must respond to multiple, concurrent stimuli At the speed of changes in monitored phenomena WSN are large-scale distributed systems4Traditional embedded systems Event-driven execution and real-time scheduling General-purpose layers are often bloated → microkernel Strict layering often adds overhead → expose hardware controls5Node-level methodology and platform Traditional design methodologies are node-centric Node-level platforms Operating system• Abstracts the hardware on a sensor node• Provides services for apps such as, traditionally, file management, memory allocation, task scheduling, device drivers, networking… Language platform• Provides a library of components to programmers6TinyOS Started out as a research project at Berkeley Now probably the de facto platform Overarching goal: conserving resources No file system No dynamic memory allocation No memory protection Very simple task model Minimal device and networking abstractions Application and OS are coupled—composed into one image Both are written in a special language nesC27TinyOS components Components: reusable building blocks Each component is specified by a set of interfaces Provide “hooks” for wiring components together A component C can provide an interface I C must implement all commands available through I Commands are methods exposed to an upper layer• An upper layer can call a command A component C can use an interface J C must implement all events that can be signaled by J These are methods available to a lower layer• By signaling an event, the lower layer calls the appropriate handler Components are then wired together into an applicationCIJ8Component specificationmodule TimerModule {provides {interface StdControl;interface Timer01;}uses interface Clock as Clk;}…interface StdControl {command result_t init();command result_t start();command result_t stop();}interface Timer01 {command result_t start(char type, uint32_t interval);command result_t stop();event result_t timer0Fire();event result_t timer1Fire();}interface Clock {command result_t setRate(char interval, char scale);event result_t fire();}TimerModule9Module vs. configurations Two types of components Module: implements the component specification (interfaces) with application code Configuration: implements the component specification by wiring existing components10Module implementationmodule TimerModule {provides { interface StdControl; interface Timer01; } uses interface Clock as Clk;}implementation {bool eventFlag;command result_t StdControl.init() {eventFlag = 0;return call Clk.setRate(128, 4); // 4 ticks per sec}event result_t Clk.fire() {eventFlag = !eventFlag;if (eventFlag) signal Timer01.timer0Fire();else signal Timer01.timer1Fire();return SUCCESS;}…}Just like method calls (unlike raising exceptions in Java, e.g.)Internal state11Configuration implementation = (equate wire) At least one must be external → (link wire) Both internal; goes from user to providerconfiguration TimerConfiguration {provides {interface StdControl;interface Timer01;}}implementation {components TimerModule, HWClock;StdControl = TimerModule.StdControl;Timer01 = TimerModule.Timer01;TimerModule.Clock → HWClock.Clock;}TimerModuleHWClockTimerConfiguration12Commands vs. events{…status = call UsedInterfaceName.cmdName(args);…}event UsedInterfaceName.eventName(args) {…return status;}command cmdName(args) {…return status;}{…status = signal ProvidedInterfaceName.eventName(args);…}313FieldMonitor example14So… why wiring? C/C++/Java? Allow use of function pointers Allow binding to be resolved at runtime Flexibility Less flexibility, but now call graph can be determined at compile time! Can inline calls cross components (5-6) into a flat instruction stream with no function calls Lots of static analysis and optimization possible15Concurrency modelTwo types of execution contexts Tasks Longer running jobs Time flexible (Currently) simple FIFO scheduling Atomic w.r.t. other tasks, i.e., single-threaded But can be preempted by events Events (an overloaded term) More precisely, hardware interrupt handlers Time critical Shorten duration as much as possible• By issuing tasks for later execution LIFO semantics; can preempt tasks and earlier events16Tasks A task is always posted for later execution; control returns to poster immediately Scheduler supports a bounded queue of pending tasks Node sleeps when the queue is empty For simplicity, tasks don’t take args and don’t return values Typical use Event necessitates further processing• Wrap it up in a task Event handler simply posts the task and can return immediatelyimplementation {task void TaskName() {…}…… {…post TaskName(); …}}17Execution exampleTask A Task B Task C…Task queueTask BTask C…Event 1Event 2Event 3Hardware interrupts18A more complex example Timer01.Timer0Fire() triggers data acquisition (through ADC) and transmission to base station (through Send)module SenseAndSend {provides interface StdControl;uses { interface ADC; interface Timer01; interface Send; }}implementation {bool busy; norace unit16_t sensorReading;…command result_t StdControl.init() { busy = FALSE; }event result_t Timer01.Timer0Fire() {bool localBusy;atomic { localBusy = busy; busy = TRUE; }if (!localBusy) { call ADC.getData(); return SUCCESS; }else { return FAILED; }}task void sendData() {…adcPacket.data = sensorReading;…call Send.send(&adcPacket, sizeof(adcPacket.data));return SUCCESS;}event result_t ADC.dataReady(uint16_t data) {sensorReading = data;post sendData();atomic { busy = FALSE; }return SUCCESS;}…}419Split-phase operation Data acquisition doesn’t take place


View Full Document

Duke CPS 296.1 - Programming Platform for Sensor Networks: TinyOS

Documents in this Course
Lecture

Lecture

18 pages

Lecture

Lecture

6 pages

Lecture

Lecture

13 pages

Lecture

Lecture

5 pages

Load more
Download Programming Platform for Sensor Networks: TinyOS
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Programming Platform for Sensor Networks: TinyOS and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Programming Platform for Sensor Networks: TinyOS 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?