TinyOS and UC Berkeley Motes

1. TinyOS and UC Berkeley Motes Hardware and Programming Tools Some slides and information was taken from Boot1.ppt and Boot2.ppt on the Berkeley TinyOS website. Some other information was taken from Lesson1 in the nest distribution

2. UC Berkeley Motes • Many Types • Current Version of TinyOS(TOS) supports • Mica • Rene • Dot

3. TinyOS flow Model Tasks events commands Interrupts

4. Example { ... status = TOS_CALL_COMMAND(name)(args) ... } TOS_COMMAND(name)(args) { ... return status; } TOS_EVENT(name)(args) { ... return status; } { ... status = TOS_SIGNAL_EVENT(name)(args) ... }

5. TOS Component • A TOS component consists of an implementation and an interface, described by a .c file and a .comp file

6. Component Implementation • A TOS component implementation may contain • a frame • Event handlers • Commands • Tasks • local procedures.  • The commands and events must match the commands and events it claims to accept in the interface.

7. TOS Component Frame • Contains all the static variables for the component • Variables in the frames are accessed by using the VAR macro.Examples of VAR macro: x = VAR(superX); y = VAR(array)[VAR(index)].item; VAR(count)++; VAR(z) = 10;

8. TOS Command • Declared as char TOS_COMMAND(cmd_name)(cmd_param_list). • Called called using TOS_CALL_COMMAND(cmd_name)(cmd_args_list) • The return value is the status of the request: • 0 => failure.  • A command may call commands, or post tasks, but may not signal events.  • It cannot block or spin waiting for state changes.

9. TOS event • Declared as char TOS_EVENT(evnt_name)(evnt_arg_list) • Signaled using TOS_SIGNAL_EVENT(evnt_name)(evnt_arg_list) • Lowest level events are connect directly to hardware interrupts by the system hardware abstraction layer.  • An event may signal events, call commands, or post tasks.  • It must complete in a short amount of time, bounded by the jitter requirements of the overall application.

10. .comp Interface TOS_MODULE name; ACCEPTS{ command_signatures}; HANDLES{ event_signatures}; USES{ command_signatures}; SIGNALS{ event_signatures};

11. TOS Component Interface • Implemented in .comp file • Specifies the name of the component module • Describes • the set of commands the component accepts • the commands that the component uses • the events that the component handles • and the events the component signals

12. TinyOS Application • A TOS application consists of a graph of components • A textual representation of this graph is contained in the ) file for the application. • The TinyOS component approach separates creation of the components from their composition.  • very easy to swap components in and out • limits the interactions between components to very narrow channels.

13. TOS Description File • Specifies the set of component modules used in the application and the wiring of commands and events across component interfaces.  • The wiring must be a subset of the interface elements associated with the components.  • There is a search path associated with resolution of module, typically consisting of "., tos/system, tos/platform, tos/shared".  include modules{ module list}; connection list

14. MAIN COUNTER CLOCK Alternative output device include modules{ MAIN; COUNTER; INT_TO_RFM; CLOCK; }; MAIN:MAIN_SUB_INIT COUNTER:COUNTER_INIT MAIN:MAIN_SUB_START COUNTER:COUNTER_START COUNTER:COUNTER_CLOCK_EVENT CLOCK:CLOCK_FIRE_EVENT COUNTER:COUNTER_SUB_CLOCK_INIT CLOCK:CLOCK_INIT COUNTER:COUNTER_SUB_OUTPUT_INIT INT_TO_RFM:INT_TO_RFM_INIT COUNTER:COUNTER_OUTPUT_COMPLETE INT_TO_RFM:INT_TO_RFM_COMPLETE COUNTER:COUNTER_OUTPUT INT_TO_RFM:INT_TO_RFM_OUTPUT INT_TO_RFM apps/cnt_to_rfm.desc

15. cnt_to_rfm.desc expanded MAIN CLOCK COUNTER INT_TO_RFM hardware.h AM PACKETOBJ SEC_DED_RADIO_BYTE RFM hardware.h

16. TinyOS Summary • TOS_FRAME_BEGIN, TOS_FRAME_END to declare a component frame • VAR(foo) to access a variable (foo) in the frame • TOS_COMMAND to declare a command • TOS_CALL_COMMAND to call a command • TOS_EVENT to declare an event handler • TOS_SIGNAL_EVENT to signal and event • TOS_TASK to declare a task (part II) • TOS_POST_TASK to post a task

17. TinyOS compiler tools • tools/desc2objs • Generates the list of components that need to be compiled into an application • tools/mkheader • Generates “C” header files from .comp files • tools/mksuper_desc • Generates the super.h linkage file that wires components together • tools/mk_amdisp • Generates the mappings between handler ID’s and handler function names for the AM_MSG macro

18. Starting a Program • By convention, TinyOS provides a MAIN component which starts up on hardware reset and invokes an INIT command followed by a START command.  This allows the collection of components forming an application to come up cleanly. • The TOS_LOCAL_ADDRESS is also defined in the .c of this component

19. Implementation Details • The .c file must #include the “tos.h” and “NAME.h”. • The .comp file must contain “TOS_MODULE NAME” at the top. It must also have “JOINTLY_IMPLEMENTED_BY NAME” if the component has a .desc file, and the .desc is not the application .desc but a sub node. • Where NAME is the name of the component

20. Debugging Tools • LEDS • dgb (which is printf basically) • TOSSIM – TinyOS simulator

21. Packets • Packets length can be specified • The default length is 36 bytes • 4 bytes of header • 30 bytes of data • 2 bytes of checksum • 2 bytes for signal strength • Reserved Addresses • #define TOS_BCAST_ADDR 0xffff • #define TOS_UART_ADDR 0x7e

22. Interpreting the Packet struct MSG_VALS{ short addr; (destination id) char type; (handler type) unsigned char group; (group id) char data[DATA_LENGTH];(data, length = 30) short crc; (check sum) short strength; (signal strength) };