European Master on Critical Networked Systems · piattaforma hardware utilizzata (per gli Atmel, avr-gcc), ottenendo l’immagine eseguibile da caricare in memoria. www mobilab unina

Napoli, Maggio-Giugno 07Mobilab European Master on Critical Networked Systems

European Master on Critical Networked SystemsModulo su Mobile Systems

Parte : titolo parte

Lezione x: titolo lezione

Docente: nome docente

info@mobilab unina itwww mobilab unina it

Dipartimento di Informatica e SistemisticaVia Claudio 21, 80125 Napoli

[email protected]

Mobile SystemsS. Russo


::. Contenuti della lezione

Modello di programmazione di TinyOSNesCNesCInvio e ricezione su reteLettura sensoriLettura sensoriEs. di debug

info@mobilab unina itwww mobilab unina it [email protected]



::. Introduzione a NesC

TinyOS è implementato in NesC (Network Embedded System C), un dialetto dellinguaggio di programmazione C

NesC adott il il modello di concorrenza event-based e la nozione dicomponente propri di TinyOS

NesC è un linguaggio statico : non prevede alcun meccanismo per l’allocazionedinamica della memoria.

Il grafo delle chiamate è pienamente noto in fase di compilazione consentendodi analizzare in dettaglio l’applicazione prodotta, riconoscere gran parte dellecorse critiche ed ottimizzare le performance


corse critiche ed ottimizzare le performance.

[email protected]



::. generalità

f è b d l ’ f d fOgni interfaccia è bidirezionale : un’interfaccia consente di specificare:

le funzioni che devono essere implementate da chi esporta l’interfaccia(comandi),funzioni che devono essere implementate dagli utilizzatori della stessainterfaccia (eventi).( )

Tipicamente i comandi sono invocazioni verso il basso, ovvero da uncomponente applicativo ad un altro più vicino allo strato hardware;componente applicativo ad un altro più vicino allo strato hardware;

gli eventi sono, invece, invocazioni di funzioni verso l’alto.




Ci d ti i di ti i C d li fi i i

::. Componenti di base

Ci sono due tipi di componenti in nesC: moduli e configurazioniI moduli provvedono al codice dell’applicazione e all’implementazione di una o piùinterfacceLe configurazioni sono usate per assemblare insieme componenti connettendoLe configurazioni sono usate per assemblare insieme componenti, connettendointerfacce usate da componenti ad interfacce fornite da altri. (Wiring delle interfacce)Ogni applicazione nesC è descritta da una top-level configuration che “cabla” insiemei componenti.i componenti.

comp1:module

comp3

Components:implementation

- module: C behaviourfi timodule

comp4

configuration:select and wire interfacesprovides interface

i i t f


comp4

comp2:configuration application:

configuration

requires interface

[email protected]



::.Programming Model

I commands devono essere implementati dal componente che forniscel’interfacciaGli events “pilotano” l’interfaccia : devono essere implementate dalGli events pilotano l interfaccia : devono essere implementate dalcomponente utilizzatore dell’interfacciUn componente se vuole utilizzare un command di un interfaccia deveprovvedere ad un event su quella interfacciaprovvedere ad un event su quella interfaccia

{...status = call CmdName(args)...

command CmdName(args) {...return status;}

C1 C2

}

{...event EvtName)(args) {

C1C1 C


status = signal EvtName(args)...}

...return status;}C2

2

[email protected]



::. Processo di Compilazione di un’applicazione nesc

Il compilatore NesC accetta in ingresso il sorgente NesC dell’applicazione e lelibrerie di componenti di sistema di TinyOS (anche esse scritte in NesC) egenera in uscita un singolo file sorgente scritto in C.Il sorgente C viene, compilato da un compilatore C specifico per lapiattaforma hardware utilizzata (per gli Atmel, avr-gcc), ottenendol’immagine eseguibile da caricare in memoria.g g




::. Concetti di base

concetti base del linguaggio di programmazione NesC sono:

S i d ll i d ll i iSeparazione della costruzione dalla composizione

Un’applicazione NesC è una composizione di componenti, assemblatimediante una specifica di wiring.

Ciascun componente è caratterizzato da una specifica, definitap pattraverso le interfacce, e da un’implementazione.

I componenti possiedono una concorrenza interna nella forma di task.


I componenti possiedono una concorrenza interna nella forma di task.

[email protected]



::. Specifica del comportamento mediante le interfacce

Le interfacce di un componente si articolano in due diversecategorie:

l i f ( id d)le interfacce esporatate (provided)e quelle importate (used).

Le interfacce esportate consentono di specificare le funzionalitàche il componente fornisce ai suoi utilizzatori;

Le interfacce importate definiscono le funzionalità di cui ilcomponente necessita per espletare le sue mansioni.


p p p

[email protected]



::. Specifica del comportamento mediante le interfacce

Poichè i comandi sono non bloccanti (asincroni), gli eventi sono resi necessarial fine di segnalarne l’espletamento.

La bidirezionalità dell’interfaccia è un meccanismo particolarmente espressivoper la realizzazione di complessi meccanismi di interazione tra componenti.

I componenti sono assemblati staticamente attraverso le interfacce.

Questo approccio consente di accrescere:Questo approccio consente di accrescere:l’efficienza a run-timela robustezzaConsente di realizzare una migliore analisi statica delle applicazioni


Consente di realizzare una migliore analisi statica delle applicazioni(rilevamento delle corse critiche).

[email protected]



I componenti sono legati insieme connettendo le

::. Specifica del comportamento mediante le interfacce p g

proprie interfacceE’ possibile formare una gerarchia

Commands:Fluiscono verso il bassoIl ritorno ritornato subito al chiamanteIl ritorno ritornato subito al chiamante

Events:Fluiscono verso l’altoIl t ll è it t l t h hIl controllo è ritornato al componente che hagenerato l’evento


Gli eventi possono invocare comandi

Non vale il [email protected]



::. Interfacce

Le interfacce sono lo strumento attraverso il quale si realizza la specifica di uncomponente.

Ogni componente è definito, in termini delle interfacce esportate ed importate.

Ciascuna interfaccia è a sua volta definita da un insieme di

comandi (generalmente richieste di servizi)di eventi (generalmente notifiche dell’esecuzione di servizi)di eventi (generalmente notifiche dell esecuzione di servizi).L’insieme dei comandi descrive il servizio offerto dal componente,l’insieme degli eventi descrive il servizio utilizzato dal componente.


Il componente implementa i gestori degli eventi per ogni interfaccia importataed i comandi per ogni interfaccia esportata.

[email protected]



::. Interfacce

La dichiarazione di un’interfaccia segue la sintassi:

interface nome_interfaccia {command retunt_type nome_comando(parametri);. . .event retunt_type nome_evento(parametri);. . .}




::. Interfacce

La parola chiave async può essere anteposta ad event o command perspecificare che l’evento o il comando possono essere eseguiti all’interno di uninterrupt handlerinterrupt handler.

La descrizione di un’interfaccia deve essere contenuta in un file .nc con lot d ll’i t f istesso nome dell’interfaccia.

Un esempio di interfaccia è il seguente:

interface SendMsg {command result_t send(uint16_t add, uint8 t le, TOS MsgPtr msg);


u t8_t e, OS_ sg t sg);event result_t sendDone(TOS_MsgPtrmsg, result_t success);}

[email protected]



::. Moduli

Un modulo implementa la specifica di un componente TinyOS

Ogni modulo ha due blocchi distinti:Ogni modulo ha due blocchi distinti:

una specifica, che riporta l’elenco delle interfacce esportate ed importate

Un’implementazione, che riporta:

la definizione di tutti i comandi di tutte le interfacce esportatela definizione di tutti i comandi di tutte le interfacce esportatela definizione di tutti i gestori degli eventi di tutte le interfacce importateeventuali task del componente.




::. Moduli

La specifica delle interfacce utilizzate dal componente è realizzata attraversole parole chiavi uses e provides.

module nome_modulo { module nome_modulo {uses {uses interface X; interface X;uses interface Y; interface Y;uses interface Y; interface Y;} provides {provides interface Z; interface Z;provides interface W; interface Z;


}} }

[email protected]



::. Moduli

Per indicare un comando/evento A, appartenente all’interfaccia X, siPer indicare un comando/evento A, appartenente all interfaccia X, siutilizza la notazione puntata X.A.

E’ ibil li d ’i f i l i iE’ possibile assegnare un alias ad un’interfaccia con la sintassiinterface Y as X;

se si utilizza un alias il riferimento è, ovviamente, Y.A.




::. Moduli

Alla specifica segue l’implementazione del componente.

L’i l i è l d ll k d i l i d èL’implementazione è segnalata dalla keyword implementation ed èracchiusa tra parentesi graffe.

Ogni comando previsto dalle interfacce esportate dal modulo èimplementato in modo del tutto analogo ad ogni evento delle interfacceimportate.p

implementation {command return_type nome_comando(parametri){. . .};command return type nome evento(parametri){ };


command return_type nome_evento(parametri){. . .};}

[email protected]



::. Moduli

E’ possibile invocare comandi attraverso la parola chiave call esollevare eventi tramite signal.

L’esecuzione dei comandi e degli eventi è immediata:

ovvero la chiamata a call e signal è semanticamente identica aduna chiamata a funzione C.




::. Creazione di Task

accanto ad eventi e comandi, è possibile definire task la cui esecuzionesegue il modello di tinyos.

I task sono definiti come funzioni senza parametri di ingresso nè di ritornoseguendo la sintassi:

task void nome_task(){...}

Un componente invoca l’esecuzione di un task, o, meglio, invia il task alloscheduler, mediante la keyword post:


post nome_task()

[email protected]



::. Atomic

E’ possibile definire dei blocchi atomici con lagaranzia che le operazioni al loro interno nonsaranno interrotte ma eseguite come una

bool busy;//global variablevoid f() {

sequenza indivisibile.

Per realizzare un blocco atomico è sufficiente

bool available;atomic {available = !busy;b s TRUE

inserire le operazioni critiche all’interno di:

atomic{ }

busy=TRUE;}if(availbale) do_something;atomic busy=FALSE;atomic{...}

I blocchi atomici sono utilizzati per realizzareforme di mutua esclusione tipicamente

y}


forme di mutua esclusione, tipicamentedurante l’aggiornamento concorrente distrutture dati.

[email protected]



::. Atomic: attenzione!

Gli ambienti atomici devono essere molto brevi, pena una fortelimitazione alla concorrenza del sistema.

A tale ragione è da ricondursi il fatto che NesC non consentel’in oca ione di comandi o la segnala ione di e enti al lo o inte nol’invocazione di comandi o la segnalazione di eventi al loro interno.




L k i t /t /i t f /S dM

::. Sintassi dell’interfaccia

Look in <tos>/tos/interfaces/SendMsg.nc

Multiple components may provide and usethis interface




L k i t /t /i t f /StdC t l

::. Interfaccia StdControl

Look in <tos>/tos/interfaces/StdControl.nc

Every component should provide this interface– This is good programming technique, it is not a


language specification

[email protected]



L k i t /t / t /AMSt d d

::. Sintassi di un modulo: interfaccia

Look in <tos>/tos/system/AMStandard.nc




::. Sintassi di un modulo: Implementazione




::. Configuration Syntax: Interface

le configurazioni abilitano alla composizione di moduli (operazione diWiring)

In un’applicazione TinyOS le configurazioni sono di gran lunga piùnumerose dei moduli giacchè si tende a realizzare gran parte deicomponenti complessi attraverso l’aggregazione di componenti di bassop p gg g plivello.

Il meccanismo della composizione consente di:Il meccanismo della composizione consente di:

esportare le interfacce ( ovvero di delegare ad altri componentil’implementazione di interfacce dichiarate dalla configurazione stessa)


l implementazione di interfacce dichiarate dalla configurazione stessa)di rinominare le interfacce (ovvero di collegare un’interfaccia

importata dalla configurazione ad un interfaccia esportata)[email protected]




Come i moduli, le configurazioni si articolano in due blocchi: una signatureed un’implementazione.

La signature riporta l’elenco delle interfacce esportate ed importate dallaconfigurazione

Il blocco implementativo elenca prima i componenti che si intendonoutilizzare nelle operazioni di assemblaggio, esportazione e rinominazione

Poi specifica i cosiddetti vincoli di wiring, ossia i legami tra i componentiprima dichiarati





endpoint1 -> endpoint2 : realizza l’assemblaggio tra componenti (linkwires)wires).

La direzione delle frecce è convenzionalmente quella dall’interfacciaimportata verso l’interfaccia esportata.

endpoint1<- endpoint2 : equivale allo statement endpoint2 ->endpoint1< endpoint2 : equivale allo statement endpoint2 >endpoint1.




::. Configuration Syntax: Esempiocomposizione tra i componenenti C1 e C2composizione tra i componenenti C1 e C2.Tale configurazione rappresenta, nel suocomplesso, l’astrazione di un componente dilivello superiorelivello superiore

configuration SuperComponent{g p p {provides interface I1;provides interface I2;}implementation {

t C1 C2components C1, C2;I1=C1.I1 //esportazione;I2=C1.I2 //esportazione;C1.I3 -> C2.I3 //assemblaggio;


// gg ;}

[email protected]



::. Es: Blink

Target: far lampeggiare il led rosso con frequenza di 1 volta al secondo

configuration Blink {}implementation {components Main BlinkM SingleTimer LedsC;components Main, BlinkM, SingleTimer, LedsC;Main.StdControl -> SingleTimer.StdControl;Main.StdControl -> BlinkM.StdControl;BlinkM.Timer -> SingleTimer.Timer;BlinkM Leds -> LedsC;BlinkM.Leds -> LedsC;

}




::. Es: Blinkmodule BlinkM { command result tmodule BlinkM {provides {interface StdControl;

}

command result_tStdControl.start() {

return callTimer.start(TIMER REPEAT, }

uses {interface Timer;interface Leds;

e .sta t( _ ,1000);}

command result t}

}implementation {

_StdControl.stop() {

return call Timer.stop();}

command result_tStdControl.init() {

event result_t Timer.fired(){call Leds.redToggle();


call Leds.init(); return SUCCESS;

}

return SUCCESS;}

}[email protected]



::. Fan-Out and Fan-In

A user can be mapped to multiple providers (fan-out)– Open <tos>\apps\CntToLedsAndRfm\CntToLedsAndRfm.nc

info@mobilab unina itwww mobilab unina it • A provider can be mapped to multiple users (fan-in) [email protected]


p pp p ( )


::.Top-Level Configuration

All applications must contain a top-level configuration that usesMain.StdControl

Open <tos>/apps/BlinkTask/BlinkTask.ncOpen <tos>/apps/BlinkTask/BlinkTask.nc




::. Operazioni split-phase

In TinyOS, ogni operazione è una split-phase operation:l’invocazione di un servizio e l’operazione di ritorno sono, in realtà, duefunzioni separate.

Per richiedere un servizio ad un componente la procedura seguita è quella diinvocare un comando sul componenteIl comando avvia un task e ritorna immediatamente il controllo al componentepchiamante.Al termine del task viene notificato un evento sul componente che ha richiestoil servizioil servizio.




::. Operazioni split-phase

il componente chiamante non attende attivamente la risposta delcomponente chiamato (busy waiting), ma prosegue nelle proprieelaborazionielaborazioni.

Ricevuta poi la notifica dell’espletamento del servizio con un evento(all’interno del quale possono essere incapsulati dei dati), interrompel’esecuzione di eventuali task ed elabora l’evento ricevuto




::. TinyOS: l’ambiente di sviluppo

Convert NesC into Cand compile to execModify exec withplatform-specificplatform specificoptionsSet the mote IDReprogram the moteReprogram the mote




::.Inter-Node Communication

General idea:Sender




::. Inter-Node CommunicationGrafo dei componenti di un generica applicazione per WSNGrafo dei componenti di un generica applicazione per WSN




::. Group IDs and Addresses

Group IDs create a virtual networkGroup ID is an 8 bit value specified in<tos>/apps/Makelocal<tos>/apps/Makelocal

The address is a 16-bit value specified by the make commandmake install.<id> mica2Reserved addresses:0x007E - UART (TOS_UART_ADDR)0xFFFF - broadcast (TOS BCAST ADDR)0xFFFF - broadcast (TOS_BCAST_ADDR)

Local address: TOS_LOCAL_ADDRESS




::. TOS Active Messages

• TOS uses activemessages as defined in<tos>/system/types/AM.h<tos>/system/types/AM.h• Message is “active”because it contains thedestination addressdestination address,group ID, and type• TOSH_DATA_LENGTH =29 bytes29 bytes– Can change viaMSG_SIZE=x in Makefile

M 36


– Max 36

[email protected]



::. TOS Active Messages




::. Message Buffer Ownership

Transmission: AM gains ownership ofthe buffer until


the buffer untilsendDone(…) is signaled• Reception: Application’s eventhandler gains ownership [email protected]


handler gains ownershipof the buffer, but it must return a freebuffer for the next


::.Sending a message (1 of 3)

First create a .h file with a struct definingthe message data format, and a uniqueactive message number– Open <tos>/apps/Oscilloscope/OscopeMsg.h




::.Sending a Message (2 of 3)

info@mobilab unina itwww mobilab unina itQuestion: How does TOS know the AM number?

[email protected]



::.Sending a Message (3 of 3)

The AM number is determined by theconfiguration file–Open <tos>/apps/OscilloscopeRF/Oscilloscope.ncOpen <tos>/apps/OscilloscopeRF/Oscilloscope.nc




::.Receiving a Message




::.Obtaining Sensor DataE h h t th t idEach sensor has a component that provides one or moreADC interfacesMTS300CA:components in <tos>\tos\sensorboards\micasbInclude in Makefile: SENSORBOARD=micasbMTS400/420:components in <tos>\tos\sensorboards\micawbInclude in Makefile: SENSORBOARD=micawb




::.Obtaining Sensor Data

Sensor components usually provideStdControlB i i i li i b f iBe sure to initialize it before trying totake measurements!!Same goes with GenericCommInitializing it turns on the power AndLedsC




::.Debug

What’s wrong with the code?

Symptom: data saved in globalData islostReason: Race condition between twotasks

Solution: Use a queue, or never rely oninter-task communication




::.Potentially Nasty Bug 2

What’s wrong with the code?

Symptom: message is corrupt

Reason: TOS_Msg is allocated in thestack, lost when function returns

Solution: Declare TOS_Msg msg incomponent’s frame.





What’s wrong with the code?– Symptom: some messages are lostSymptom: some messages are lost

Reason: Race condition between twocomponents trying to share networkcomponents trying to share networkstack (which is split-phase)

Solution: Use a queue to store pendingSolution: Use a queue to store pendingmessages





Symptom: Some messages are consistentlycorrupt and TOSBase is working Your appcorrupt, and TOSBase is working. Your appalways works in TOSSIM.

Reason: You specified MSG_SIZE=x wherex > 29 in your application but forgot to setx 29 in your application but forgot to setit in TOSBase’s makefile





Your app works in TOSSIM, but never works onthe mote. Compiler indicates you are using 3946the mote. Compiler indicates you are using 3946bytes of RAM.

Reason: TinyOS reserves some RAM for theStack. Your program cannot use more than 3.9KRAM.



Documents

European Master on Critical Networked Systems · piattaforma hardware utilizzata (per gli Atmel, avr-gcc), ottenendo l’immagine eseguibile da caricare in memoria. www mobilab unina