diffusion libre développement d'un driver radio pour réseau de capteurs orange labs matthieu...

diffusion libre

Développement d'un driver radiopour réseau de capteursOrange Labs

Matthieu ANNE & Julien TOUS, Recherche & Développement jeudi 23 octobre 2008, présentation pour le Master 2 « Electronique des Télécommunications » de l'Université de Savoie

Orange Labs - Recherche & Développement – Driver radio EM2420 – 23/10/2008 2 diffusion libre

sommaire

partie 1 Présentation générale du projet

partie 2 Think : Infrastructure de développement de logiciels à base de composants

partie 3 Exemple : eNose

partie 4 Objectifs du projet


Partie 1 :Présentation générale du projet


Orange

Le groupe Orange c’est:

– Dans le monde:– Une présence dans

220 pays– 170 millions de clients

– En Europe:– Le troisième opérateur

mobile– Le premier fournisseur

d’accès ADSL– Un chiffre d’affaire de 52,9

milliards d’euros en 2007 La division R&D : Orange Labs

– 16 sites répartis sur 4 continents

– 3800 chercheurs et ingénieurs– 8500 brevets


Réseaux de capteurs

Chaque nœud possède :

– Des capacités d'acquisition d'information sur son environnement

– Des ressources de calculs– Un système de communication sans fils

Principale contrainte : autonomie


Matériel

Cognichip Extension EM2420

DKcarrierBoardEM2420 RCM


Driver EM2420

Implémenter un driver pour les puces radio EM2420

Le driver devra respecter la norme 802.15.4

Driver sous la forme d'un ensemble de composants Think

Architecture du driver devra faciliter son utilisation sur différentes plateformes (cognichip, EM2420 RCM, …)


sommaire






Partie 2 :ThinkInfrastructure de développement de logiciels à base de composants


Think en bref

Implémentation "C" du modèle à composant Fractal

Projet "Open source" (GPL) hébergé par Object Web

Langages :

– ADL : Architecture Description Language

– IDL : Interface Description Language

– NuptC: C + annotations Chaîne de compilation

Bibliothèque de composants Kortex (LGPL):

– Composants systèmes : ordonnanceurs, pilots matériels, files d'attentes …

– Plateformes : AVR, ARM, MPS 430


Le modèle Fractal – en bref

Modèle de composants au développement et à l'exécution

Composant = brique logiciel, unité de composition de déploiement et d'administration

Modèle réflexif

– Introspection : connaître la constitution d'un système à l'exécution

– Intercession : modification de l'architecture Modèle récursif

– Un composant peut être constitué d'autres composants Implémentations

– Java : Julia (implémentation de référence)– C : Think

– Nuptse (V4) : simplification et prise en compte des contraintes relatives à l'embarqué – travaux réalisés et exploités à FT

– …


Les composants Think (1/3)

Un composant :

– Fournie des interfaces serveurs

– Requière des interfaces clientes

– A des attributs

composant

interfacecliente 1

interfaceserveur n

interfaceserveur 1

att1, attl,

interfacecliente m

interfaces decontrôles



Le contenu :

– Implémente les interfaces serveur

– Code fonctionnel NuptC– Sous-composants

La membrane :

– Implémente les interfaces de contrôles (ContentController, LifeCycleController,…)

– Est facultative

Implem.c

Impl

composant

membrane

contenu

interfacecliente 1

interfaceserveur n

interfaceserveur 1


att1, attl,

interfacecliente msous-

composant



Les liaisons :

– Canal de communication d'une interface client vers une interface serveur

– Permettent le transfert entre l'interface d'un composant et celle d'un de ses sous-composants

C

Implem.c

Impl

composant

membrane

contenu

interfacecliente 1

interfaceserveur n

interfaceserveur 1


att1, attl,

interfacecliente m

liaison

sous-composant


La compilation

Haut niveau:

– Transformations d'architecture (AST), optimisations (propriétés)

– Transforme et génère du code "C" Bas niveau

– Utilisation de gcc pour produire l'image binaire du système ou d'une partie du système pour téléchargement dynamique

gcc/ldCCC elfThinkIDLIDL

ADLADL

NuptCNuptCNuptC

ADL

IDL


Architecture Description Language ADL (1/2)

component main { contains boot = boot.lib.boot contains wtsh = helloWorld.lib.wishToSayHello contains hw = helloWorld.lib.helloWorld assigns hw.repeat = 3 binds boot.entry to wtsh.main binds wtsh.hello to hw.hello}

main.adl

component helloWorld.lib.wishToSayHello { provides activity.api.Main as main requires helloWorld.api.SayHello as hello content wishToSayHello}

wishToSayHello.adl

component helloWorld.lib.helloWorld { provides helloWorld.api.SayHello as hello attribute int repeat content helloWorld}

helloWorld.adl

wishToSayHello.c

main hello

wtsh

helloWorld.c

hello

hw

boot.c

entry

boot

main


ADL - extension de définition (2/2)

abstract component helloWorld.lib.helloWorld { provides helloWorld.api. as hello attribute int repeat}

helloWorld.adl

frenchHello.adl

hello

hw

component englishHello extends helloWorld.lib.helloWorld { content englishHello}

englishHello.adl

englishHello.c

hello

englishHello

component frenchHello extends helloWorld.lib.helloWorld { content frenchHello} frenchHello.c

hello

frenchHello


Interface description Language (IDL) (1/2)

Les interfaces des composants sont définies en utilisant l'IDL

Déclaration du type de interface hello (helloworld.api.SayHello.idl)

package helloWorld.api;

public interface SayHello { void printHello ();}

SayHello.idl


Interface description Language (IDL) (2/2)

type et typedef dans l'IDL

package helloWorld.api;

Typedefs myTypes;

public interface SayHello { void printHello (char* info, myType2 moreInfo);}

SayHello.idl

typedef int myType1;

typedef struct { myType1 toto;} * myType2;

myTypes.h


Programmation des composants (1/2)

nuptC : langage utilisé pour le code fonctionnel

nuptC : langage C + annotations

Annotation = correspondance entre ADL et code C

/** @@ ClientInterfacePrefix(hello, HELLO_) @@* @@ DefaultServerMethods @@*/void main (int argc, char* argv) { HELLO_printHello();}

wishToSayHello.c

component helloWorld.lib.wishToSayHello { provides activity.api.Main as main requires helloWorld.api.SayHello as hello content wishToSayHello}

wishToSayHello.adl


Programmation des composants (2/2)

Plus d'une 10ème d'annotations

– DefaultServerMethods

– DefaultClientMethods

– DefaultAttributes

– PrivateData

– PrivateMethod

– … Annotations par défaut

– SRV_itf__methodName(…)

– CLT_itf__methodName(…)

– PRV_methodName(…)

– …


sommaire






Partie 3 :Exemple eNose


eNose


Architecture générale


Architecture : driver eNose


Lego logiciel & matériel

sensorBoardsensorBoard

muxsensors

layout

leds

dataProcessor

manager

boot


leds

dataProcessor

manager

boot

Lego logiciel & matériel

sensorBoardsensorBoard

muxsensors

layout


Chip ltc2408 : description

component adc.ltc2408.lib.ltc2408 { provides adc.ltc2408.api.MuxChannelControl as channelControl provides adc.ltc2408.api.GetAdcData as getData requires activity.api.Delay as wait requires hw.api.BitControl as sck // synchro clock requires hw.api.BitControl as chipSelect //CS requires hw.api.BitControl as channelSelect //DIN requires hw.api.BitControl as data //SDO (Serial Data Output) …}

ltc2408.adl

package hw.api;

public interface BitControl { void set(); void unset(); kt_native get();}

BitControl.idl

chanelControl

getData

wait

sck

chipSelect

channelSelect

data

ltc2408


Chip ltc2408 : code fonctionnel (convertisseur) …

//@@ PrivateMethod @@kt_native getDataBit(){ kt_native dataBit;

SCK_set(); WAIT_udelay(CLOCK_LENGTH); dataBit = DATA_get(); SCK_unset(); WAIT_udelay(CLOCK_LENGTH); return dataBit;}…// getData server methodltc2408_data_t getData(){ kt_u8 i; … for(i=0; i<DATA_SIZE; i++){ muxData.data = muxData.data << 1; muxData.data |= getDataBit(); } … return muxData;}

/** * @@ DefaultServerMethods @@ * @@ ClientInterfacePrefix (wait, WAIT_) @@ * @@ ClientInterfacePrefix (sck, SCK_) @@ * @@ ClientInterfacePrefix (chipSelect, CS_) @@ * @@ ClientInterfacePrefix (data, DATA_) @@ */…

ltc2408.c

ltc2408.c


Composant Layout

component cognichip2561.eNose.eNoseLayout { provides fractal.api.LifeCycleController as lcc provides hw.api.BitControl as sck // synchro clock provides hw.api.BitControl as chipSelect //CS provides hw.api.BitControl as channelSelect //DIN provides hw.api.BitControl as data //SDO //(Serial Data Output) requires hw.api.GPIO as porta requires hw.api.GPIO as portd content cognichip2561.eNose.eNoseLayout}

layout.adl

//@@ ServerInterfacePrefix (sck, SCK_) @@//@@ ClientInterfacePrefix (porta,PORTA_) @@

#define SCK_BIT 0x02…void SCK_set(){ PORTA_set_POUT(PORTA_get_POUT() | SCK_BIT);}

void SCK_unset(){ PORTA_set_POUT(PORTA_get_POUT() & ~SCK_BIT);}

kt_native SCK_get(){ if (PORTA_get_POUT() & SCK_BIT) return 1; else return 0;}…

// @@ DefaultServerMethods (lcc) @@void start(){//defining ios //out xxxx 111xPORTA_set_PDIR(PORTA_get_PDIR() | 0x0E); //in xxxx 0xxxPORTD_set_PDIR(PORTD_get_PDIR() & ~0x08);}

void stop(){}

layout.c

sck

chipSelect

channelSelect

data

lcc

porta

portd

gpio

porta

gpio

portd

layout

sck

chipSelect

channelSelect

data

wait

ltc2408


sommaire






Partie 4 :Objectifs du projet


I/ Driver bas niveau EM2420

Faire communiquer deux 2 cartes Ember EM2420 RCM [7](DkcarrierBoard.pdf [8]) par liaison radio hadhoc (couche MAC et supérieur). A ce niveau, les deux composants logiciels principaux à fournir sont les composants « phy-cc2420 » et « layout ». Le composant phycc2420 est en charge de l'implémentation de la couche physique du protocole 802.15.4 [9]. Quand au composant layout, il doit permettre l'abstraction du matériel afin de facilité la portabilité.

– Définition des interfaces et du composant phy-cc2420 ainsi que son implémentation.

– Assemblage du composant layout pour la carte EM2420 RCM à partir des composants bas niveau existants dans la bibliothèque Kortex (gpio...).


II/ Driver multi-plateformes

L’objectif est de faire communiquer un Cognichip (carte d'expérimentation d'Orange (Atm2561 + extension EM2420)) et la carte EM2420 RCM par une liaison radio hadhoc (couche MAC et supérieur).

– Définition d'un composant layout pour le Cognichip à partir des composants bas niveau existants dans la bibliothèque Kortex (gpio...).


III/ Sur-couche 802.15.4

L'objectif visé ici est l'implémentation de la couche MAC de la norme 802.15.4. Cet objectif est divisé en trois étapes. Ci-dessous un schéma représentant les applications correspondant à l'objectif 3.

– Étape 1 : Implémentation partielle (Reduced Function Device) capable de s'insérer dans un réseau 802.15.4 existant. L’objectif est de faire communiquer le Cognichip et/ou la carte EM2420 RCM avec un device 802.15.4 banalisé, par exemple la carte EM2420 RCM avec le logiciel propriétaire fournis par Ember. Pour cela il faudra définir les interfaces et le composant MAC-802.15.4 ainsi que son implémentation.

– Étape 2 : Création d'un réseau 802.15.4 aux fonctionnalités partielles Utiliser le Cognichip comme coordinateur 802.15.4 (Full Function Device) avec la carte Ember comme end-device. (Note malgré la dénomination « Full Function Device » cet implémentation pourra se limiter à un sous ensemble de 802.15.4 commun avec le « Reduce Function Device » développé précédemment.)

– Étape 3 : Implémentation complète de la norme 802.15.4 Cognichip coordinateur, capable de supporter n'importe quel EndDevice 802.15.4


Organisation du travail

Prise en main de Think

– http://think.objectweb.org/getting_started.html Travaux pratiques

– Vendredi 7 novembre 2008– Leds, buzzer, boutons… (DKcarrierBoard)

Subversion

– Création de comptes sur ObjectWeb– Branche du projet dans kortex

Contact:

– [email protected]– [email protected]– [email protected]

diffusion libre

Bon courage!

diffusion libre développement d'un driver radio pour réseau de capteurs orange labs matthieu...

Documents