DOC PREVIEW
BU CS 580S - Programming Motes

This preview shows page 1-2-24-25 out of 25 pages.

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

Unformatted text preview:

Programming MotesThe monsters:TinyOS OverviewTinyOS featuresWhat TinyOS does not provide…TinyOS program architectureTinyOS Components can provide...Tasks in TinyOS and SchedulingTinyOS developmentTinyOS installation notesComponent DevelopmentBlink: A component exampleCode walkthroughCode walkthrough continued…StdControl InterfaceCode walkthrough continued pt2…BlinkM.nc – module implementationBlinkM.nc continued…BlinkM.nc continued pt2…Running TinyOS code - TOSSIMDebuggingTinyViz – A visualization programTinyVizMica2 module uploading…And they all lived happily ever afterProgramming MotesA TinyOS and TOSSIM TutorialBy: Brent RoodThe monsters:Programming BoardMICA2 MOTETinyOS OverviewOperating system developed at UC Berkeley for use with sensor motesSupport sensor motes and ease development of sensor applicationsEvent-driven architectureUtilizes new programming language called nesCCurrently the standard in sensor OSTinyOS featuresExtensibility–Allows components to be “wired” together thereby allowing for flexibility and ease of development through use of a wide array of components able to be wired in many configurationsSpecifically designed for use in sensors–Low power overhead–Requires little processing power–Small memory footprintWhat TinyOS does not provide…In order to accommodate the unique resource requirements of sensors, TinyOS has sacrificed:–Kernel – programmer deals with hardware directly–Process Management – only one process–Multiple stacks – only a single shared stack–Virtual Memory – physical memory used–Dynamic Memory Allocation – assigned at compile timeTinyOS program architectureA program consists of a set of components “wired” together–Each component can provide “interfaces” which can be wired to and allow use of that component’s functions (it exports these functions)–The component can also export events to which a component wired to it can respond toNote: These components are statically wired together at compile timeTinyOS Components can provide...Events–An event is a “happening” that is produced by a component and that can be responded to by any components wired to this component–Events are generated in response to a given happening and can call other commands, generate other events or post a taskCommands–Provided by a component, these provide functionality into that component–A command of a component may be invoked by a component wired to it and is akin to a member function of a class–Can also call other commands, trigger events or post tasksTasks in TinyOS and SchedulingTasks–A function that once called is put in a FIFO queue awaiting execution–Usually used for longer processing errands because these can be preempted (by an incoming event for example)Scheduling–Commands and Tasks (FIFO queued) are non-blocking and non-preemptive (tasks cannot preempt each other)–Events are preemptive and blocking–Hence, responses to events must be kept as short as possible (e.g. post a task and return)TinyOS developmentDownload and Install TinyOS http://www.tinyos.net/tinyos-1.x/doc/install.html–Windows:Uses Cygwin environment to simulate Linux environmentMore complex than Linux installation (this took some time)WARNING: TinyOS has problems with newer versions of Cygwin and prefers older versions for proper functioning–Linux:Preferred as it’s native and faster; Easier setupSimply involves installing several RPMs (for Red Hat)Note that nesc-1.1-1.i386.rpm should be used (the recommended nesc-1.1.2b-1.i386.rpm gives many compiler errors)TinyOS installation notesInstalls –nesC compiler and AVR package (processor dependant)–Java JDK and Communications package–TinyOS software/modulesTinyOS installation (Red Hat) can be found in /opt/tinyos-1.x/–/opt/tinyos-1.x/apps contains example components (such as Blink)–/opt/tinyos-1.x/tools/java contains many java applications that will be useful later–/opt/tinyos-1.x/tools/scripts contains toscheck which can be used to check installation for correctnessAlso ensure that you change your PATH variable to includeComponent DevelopmentComponents consist of two files–Configuration file (e.g. mycomponent.nc)Specifies how and to which other components this particular component is wired toAlso allows the component to “provide” various interfaces to other components (that can wire to it)–Module file (e.g. mycomponentM.nc)This is the actual implementation of the component itselfDeals with event handling, command implementation, task posting, etc.Blink: A component exampleBlink.nc consists of:configuration Blink {}implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC;}Code walkthrough configuration Blink { }–Specifies this is a configuration file whose name is Blinkimplementation { –Indicates that this is where we specify the actual configuration of the componentcomponents Main, BlinkM, SingleTimer, LedsC; – A listing of the set of components that this configuration file references (makes use of)Code walkthrough continued… Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; –Main is a component and StdControl is an interface it uses–-> symbol indicates that the component on the left “is wired to” (OR the component on the left “uses”) the component on the right and carries with it two conditions:The component on the right must implement all the functions provided by the component’s interface on the leftThe component on the left must implement event handlers for all the events that the component on the right exportsHence, Main’s StdControl interface uses (is wired to) the StdControl interfaces provided by (implemented by) both BlinkM and SingleTimerStdControl InterfaceAnyone who provides the StdControl Interface must implement the following 3 functions:–StdControl.init(), StdControl.start() and StdControl.stop()When a mote is started, the first two functions called are Main.StdControl.init() and Main.StdControl.start()–Any modules who implement this interface and are wired to Main in such a way also have their init and start functions called–The last function called is Main.StdControl.stop() and it will call all the stop


View Full Document

BU CS 580S - Programming Motes

Download Programming Motes
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 Motes 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 Motes 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?