[go: up one dir, main page]

0% found this document useful (0 votes)
26 views19 pages

TinyOS Manual Ver 1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views19 pages

TinyOS Manual Ver 1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

TINY OS

Tiny OS Installation
Installation of TinyOS using Virtual Machine.

Requirements:

• Ensure the Virtualization (VxT) is enabled in BIOS of your system.


• Install VMware workstation player from the following link:

https://my.vmware.com/en/web/vmware/free#desktop_end_user_computing/vmware_workst
ation_player/14_0

• Collect Ubuntu virtual disk from the instructor and copy it in your system.
• Open VMware workstation and add the virtual disk.
• Power ON the Ubuntu virtual machine.

The following snapshots will help you in installation.

Run the VMware installation setup,

Select next
Check in the box and click next

Click next
Enter the password: z.

The installation steps are now complete.


Task 1 – Getting started with Programming TelosB mote
using nesC
This task provides necessary steps for programming TelosB mote. Open the folder
“TinyOS_Guide(available on desktop)-->Demo --> 1_Blink”.

The following files will be available

• AppC.nc
• C.nc
• Makefile.

The programming language used in TinyOS is nesC (extension of C language. A nesC program is built
out of components, which are assembled (“wired”) to form whole programs. Components define
two scopes, one for their specification (containing the names of their interfaces) and one for their
implementation. The provided interfaces are intended to represent the functionality that the
component provides to its user, the used interfaces represent the functionality the component
needs to perform its job.

Interfaces are bidirectional: they specify a set of functions to be implemented by the interface’s
provider (commands) and a set to be implemented by the interface’s user (events). This allows a
single interface to represent a complex interaction between components (e.g., registration of
interest in some event, followed by a callback when that event happens). This is critical because all
lengthy commands in TinyOS (e.g. send packet) are non-blocking; their completion is signaled
through an event (send packet done). The interface forces a component that calls the “send packet”
command to provide an implementation for the “send packet done” event.

• Right click in the file window and select Open a terminal.


• In the terminal, enter “motelist” to identify the telosb mote. The device is connected at
/dev/ttyUSB0.

• Enter “sudo chmod 777 /dev/ttyUSB0” to enable read, write, execute permission for
the device. Enter password as ‘z’ (without quotes).

• Lets take a look inside the 1_Blink folder, you find three files, BlinkAppC.nc, BlinkC.nc and
Makefile. The application constructed using these three files toggles three LEDs (red, green
and blue) on the telosb board with a time interval of 1s, 2s and 4s. Blink application is
composed of two components: a module, called "BlinkC.nc", and a configuration, called
"BlinkAppC.nc". All applications require a top-level configuration file, which is typically
named after the application itself. In this case BlinkC.nc is the configuration for the Blink
application and the source file that the nesC compiler uses to generate an executable file.
BlinkAppC.nc, on the other hand, actually provides the implementation of the Blink
application. Lets take a look at each file:
BlinkAppC.nc:

configuration BlinkAppC
{
//Making use of standard functionality so keep it blank
}
implementation
{
//Define components for the application

components MainC; //To provide boot functionality


components BlinkC as App; //Initialization of module
components LedsC; //To provide Led interface

components new TimerMilliC() as Timer0; //To Provide timer interface


components new TimerMilliC() as Timer1;
components new TimerMilliC() as Timer2;

//Wiring

App -> MainC.Boot;


App.Timer0 -> Timer0;
App.Timer1 -> Timer1;
App.Timer2 -> Timer2;

App.Leds -> LedsC;


}
The first thing to notice is the key word configuration, which indicates that this is a configuration file.
The first two lines,
configuration BlinkAppC {
}
simply state that this is a configuration called BlinkAppC. Within the empty braces here it is possible
to specify uses and provides clauses. The actual configuration is implemented within the pair of curly
bracket following key word implementation. The components line specifies the set of components
that this configuration references, in this case Main, BlinkC as App (renaming BlinkC program as
App), TimerMilliC, and LedsC. Three instances of TimerMilliC have been created as Timer0, Timer 1
and Timer 2. The remainder of the implementation consists of connecting interfaces used by
components to interfaces provided by others.
The first line App -> MainC.Boot wires the App with the MainC.Boot so that on bootup the telosb
will execute the Blink application.
The second line wires the App.Timer0 -> Timer 0 is used to wire the Timer0 interface used by
BlinkAppC to the Timer0 interface provided by TimerMilliC. The arrow binds interfaces (on the left)
to implementations (on the right).
BlinkC.nc:

#include "Timer.h"

module BlinkC
{
uses interface Timer<TMilli> as Timer0;
uses interface Timer<TMilli> as Timer1;
uses interface Timer<TMilli> as Timer2;
uses interface Leds;
uses interface Boot;
}
implementation
{
event void Boot.booted()
{
call Timer0.startPeriodic( 1000 );
call Timer1.startPeriodic( 2000 );
call Timer2.startPeriodic( 4000 );
}

event void Timer0.fired()


{
call Leds.led0Toggle();
}

event void Timer1.fired()


{
call Leds.led1Toggle();
}

event void Timer2.fired()


{
call Leds.led2Toggle();
}
}

The first part of the code states that this is a module called BlinkC and declares the interfaces it uses.
The BlinkC module also uses five interfaces: 3 interfaces of TimerMilli , Leds and Timer. This means
that BlinkC may call any command declared in the interfaces it uses and must also implement any
events declared in those interfaces. The Leds interface defines several commands like led1On( ),
led1Off( ), led2Toggle( ) and so forth, which turn the different LEDs (red, green, or yellow) on the
mote on and off. Because BlinkC uses the Leds interface, it can invoke any of these commands. Keep
in mind, however, that Leds is just an interface: the implementation is specified in the Blink.nc
configuration file.

Under implementation, the first line event void Boot.booted is executed after successful
initialization of telosb mote. The “call” commands imolementedd in the event schedules various
events in the telosb mote. IN this case, they are timers and are triggered at time intervals of 1s, 2s
and 4s.

How does an application know that its timer has expired? The answer is when it receives an event.
The Timer interface provides an event:

event result_t fired( );

An event is a function that the implementation of an interface will signal when a certain event takes
place. In this case, the fired() event is signalled when the specified interval has passed. This is an
example of a bi-directional interface: an interface not only provides commands that can be called by
users of the interface, but also signals events that call handlers in the user. Think of an event as a
call-back function that the implementation of an interface will invoke. A module that uses an
interface must implement the events that this interface uses.

What you observer on the board would be three LEDs toggling at intervals of led 0 --1s, led1 -- 2s
and led2 -- 4s.

Makefile

COMPONENT=BlinkAppC // define component as name of the configuration file

include $(MAKERULES) // include standard syntax for Makefile

Running the code:


• Open terminal window and type : make telosb to compile the code. If it compiles successfully,
type make telosb install (for programming the board). The three LEDs on the board should
toggle every 1s, 2s and 4s.
• Expected output from the terminal should be:
Task 2: Printing data from board onto serial terminal
Open folder 2_Print. Compile and program the files. To view the output, open the application called
‘moserial’ available.

Click on ‘port setup’ and put settings as per below snapshot.

Click ok.
At the end of this program, we see current time since the board was booted on serial terminal.

When reset button on the mote is pressed – the timer will start again.
Task 3: Implementing packet broadcast
The aim of this experiment is to setup mote-to-mote communication using wireless transceiver. Go
to folder 3_BlinktoRadio. Please go through all the three files and understand the logic. Insert the
first board, compile and program the board. Remove the first board. Insert the second board,
compile and program it. Power up both the boards now. Observe the outputs on the LEDs. If both
boards are communicating then the LEDs on both the boards should toggle in the same sequence.

Task 4: Implementing unicast communication


The aim of this experiment is to setup unicast communication between two motes. Go to folder
4_unicast. The objecctive is to send the packets from a source mote to a desitnation mote with
destination address in the packet. The desitination node checks the packet after receiving and saves
the packet after successful match between the destination address in the packet and it’s own ID.
(Hint: Add destination node id entry in the packet structure present in the header file and
compare this ID with node ID in receive event in the program).

Task 5: Implementing multihop communication


The aim of this experiment is to setup multi-hop network among three motes. Go to folder
5_multihop. The objective is to forward message from source mote to destination mote via
intermediate mote.

You might also like