Communications dans les systèmes embarqués

Guillaume Normand, Benjamin Bonny, Loïc Raucy, Theodoros Theodoropoulos

24 mars 2011
Table des matières

1 L'USB dans les systèmes embarqués 3

1.1 Présentation générale de l'USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Une architecture arborescente . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Un bus qui transmet une alimentation . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Diérentes vitesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Les connecteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 L'USB On-The-Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 L'USB en détail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Le protocole de communication . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Les endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Les diérents types de endpoints . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 L'USB dans un STM32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 L'implémentation de l'USB dans un STM32 . . . . . . . . . . . . . . . . . 6
1.3.2 Les buers dans un STM32 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Comment utiliser l'USB dans un STM32 ? . . . . . . . . . . . . . . . . . . 7

2 Les cartes SD dans l'embarqué 8

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 L'interface électrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Les fonctionnalités de la carte SD . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 La phase d'initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 La phase de transfert de données . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Les modes de communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Mode SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Mode SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Application à un STM32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 IP Embarqué 12
3.1 Présentation de TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Ethernet et les STM32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 STM32F103 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 STM32F105/107 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Piles TCP/IP gratuites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 uIP/lwIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 NicheLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1
4 6LowPan 16
4.1 Introduction à 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Introduction à 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Topologies de réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 Principes de la couche physique dénie par 802.15.4 . . . . . . . . . . . . 18
4.2.3 Principes de la couche MAC du 802.15.4 . . . . . . . . . . . . . . . . . . . 18
4.3 Transmission des données via des reseaux 802.15.4 . . . . . . . . . . . . . . . . . 20
4.3.1 Interoperabilite de 6LowPan . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2 Routage de 6LowPan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Implémentation du 6LowPan sur les processeurs de la famille STM32 - Nanostack 22
4.5 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.2 Cartes SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.3 IP & Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.4 6lowPan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2
Chapitre 1

L'USB dans les systèmes embarqués

1.1 Présentation générale de l'USB

L'USB possède une architecture arborescente, autorise les branchements à chaud, transmet
une alimentation.

1.1.1 Une architecture arborescente

Dans un bus USB, il y a un hôte, ou maître, et des périphériques, ou esclaves. Généralement,
l'hôte est un PC, toutefois, il est possible que ce soit un système embarqué : la carte Gumstix
Overo, par exemple, possède un USB hôte. Les périphériques sont, par exemple, une souris,
un disque dur externe, une webcam, ou bien une carte de développement intégrant un STM32.
L'architecture permet ainsi d'avoir jusqu'à 127 périphériques connectés en même temps, et qui
peuvent fonctionner à diérentes vitesses, des hubs se chargeant de ltrer les échanges en fonction
des vitesses, et d'alimenter correctement l'ensemble des périphériques. C'est l'hôte qui se charge
d'initier tous les échanges, les périphériques ne peuvent qu'attendre que l'hôte leur adresse la
parole.

1.1.2 Un bus qui transmet une alimentation

Le bus USB délivre une alimentation en même temps que les données. Il possède 4 broches :
celui d'alimentation (+5 V), la masse, et D+ et D- qui servent à la transmission des données,
de manière diérentielle. L'alimentation fournie est de 5 V, et chaque périphérique est autorisé à
utiliser de 100 mA à 500 mA. L'USB utilise le terme d'"unité d'alimentation", qui vaut100 mA.
Un périphérique peut soit :
 Nécessiter peu d'énergie, et consommer une unité d'alimentation
 Nécessiter plus d'énergie, et après conguration, consommer jusqu'à 5 unités
 Avoir une source externe d'alimentation, et n'utiliser ainsi qu'une unité d'alimentation du
bus USB

Le mode veille Chaque périphérique doit nécessairement avoir un mode veille. La norme USB
veut que s'il n'y a plus de trac sur son bus USB durant 3 ms, un périphérique doit se mettre en
mode veille dans les 7 ms qui suivent. Dans ce mode veille, il doit consommer moins de courant.
Le courant qu'il est autorisé à consommer est proportionnel au courant en mode normal : il est de
500 µA par unité d'alimentation. Ainsi, un périphérique qui consomme 3 unités d'alimentation

3
en temps normal, doit consommer moins de 1.5 mA en mode veille. Il est possible qu'il fonctionne
tout de même avec une alimentation plus élevée, mais il ne respectera pas les standards de l'USB,
et donc rien n'est garanti concernant le fonctionnement global.

1.1.3 Diérentes vitesses

L'USB propose plusieurs vitesses de transfert. L'USB 1.1 proposait le Low Speed et le Full
Speed, orant des débits théoriques respectifs de 1.5 Mbit/s et de 12 Mbit/s. L'USB 2.0 a
introduit le High Speed, permettant un débit théorique de 480 Mbit/s. Il faut bien noté que les
débits annoncés ne sont que théoriques. Cela sera expliqué un peu plus tard. Il ne faut pas non
plus perdre de vue que le débit annoncé correspond à celui de l'hôte, qui réparti ensuite ce débit
entre tous les périphériques.
La détection de la vitesse à utiliser se fait lors de la connexion du périphérique. Si l'on veut
que le périphérique communique en Full Speed, celui-ci doit passer la broche D+ à 3.3 V. Si
le périphérique doit communiquer en Low Speed, c'est la broche D- qui doit être au potentiel
de 3.3 V. Cela se fait en plaçant une résistance de pull up au niveau de la prise USB du pé-
riphérique, sur la broche devant être placée à 3.3 V. Concernant les périphérique High Speed,
ceux-ci commencent par communiquer en Full Speed, puis au moment du reset qui a lieu lors de
la connexion d'un périphérique, ils doivent préciser qu'ils désirent communiquer en High Speed.

De l'intérêt du Low Speed On pourrait se demander pourquoi, dans la première version

de l'USB, le Low Speed était présent, alors que le Full Speed était déjà disponible. En fait,
d'une part des périphériques tels qu'une souris ou un clavier se contentent amplement d'un
débit de 1.5 Mbit/s, et d'autre part, il coûte plus cher de fabriquer un périphérique Full Speed
qu'un périphérique Low Speed, car il nécessite des composants de meilleure qualité, an d'avoir
la précision nécessaire pour communiquer à plus grande vitesse. Il est donc économiquement
avantageux de construire une souris dialoguant en Low Speed.

1.1.4 Les connecteurs

Les connecteurs ont une importance dans l'USB. En eet, d'après la norme, les périphériques
doivent avoir un connecteur de type B femelle, et les hôtes un connecteur de type A femelle,
les cables reliant les deux étant toujours du type A mâle/B mâle. Ainsi, il est impossible de
brancher deux hôtes ou deux périphériques ensemble. Toutefois, les périphériques ont souvent un
connecteur A mâle directement au bout d'un cable (souris, clavier), ou on peut même être amené
à placer un connecteur A mâle sur un périphérique, et l'utiliser avec une rallonge, par facilité.

Figure 1.1  Connecteur de type A USB in a Nutshell

1.1.5 L'USB On-The-Go

L'USB 2.0 a apporté une alternative au classique modèle hôte/esclave : L'USB On-The-Go.
Avec cette nouvelle norme, deux périphériques peuvent dialoguer pour s'attribuer dynamique-
ment un rôle de maître ou d'esclave, alors que dans le modèle classique, cela était xé en dur.

4
 Figure 1.2  Connecteur de type B USB in a Nutshell

Ainsi, de nouvelles possibilités sont ouvertes : on peut échanger directement des photos entre
un appareil photo et une imprimante, par exemple. L'USB On-The-Go ne sera toutefois pas
développé dans ce document.

1.2 L'USB en détail

1.2.1 Le protocole de communication

Comme cela a déjà été spécié auparavant, c'est l'hôte qui dirige tous les échanges. Ainsi,
chaque échange se déroule comme suit :
 Émission d'un paquet jeton par l'hôte
 Émission/réception de la charge utile
 Acquittement
Le paquet jeton sert à préciser à quel périphérique s'adresse l'hôte, et à préciser le sens de
l'échange à venir. L'acquittement, lui, a lieu, soit pour conrmer que la charge a été reçue
correctement, sans erreurs, soit pour prévenir qu'au contraire, il y a eu des erreurs (grâce à des
mécanismes tels quel le CRC). En plus de ces paquets classiques, l'hôte envoie des paquets SoF
(Start of Frame) environ toutes les millisecondes, an de maintenir le périphérique dans son état
normal, et qu'il ne se mette pas en veille.

1.2.2 Les endpoints

Les endpoints ont un rôle prépondérant dans le transfert de données dans la norme USB. En
eet, ceux-ci sont l'unique interface de dialogue entre l'hôte et ses périphériques. Le périphérique
implémente un certain nombre de endpoints. Lorsque l'hôte va s'adresser à un périphérique, il va
en réalité s'adresser à un endpoint de ce périphérique, dans lequel il va écrire ou lire. Pour cela,
l'adresse utilisée dans le paquet jeton décrit plus haut, est l'adresse d'un endpoint (l'adresse se
décomposant en diérents niveaux, comme les adresses IP). Comme les endpoints sont créés par
le périphérique, l'hôte, en soit, n'est pas capable de connaître à l'avance quels sont les endpoints
avec lesquels il peut dialoguer. Il est donc nécessaire que tout périphérique ait un endpoint par
défaut, avec lequel l'hôte sait qu'il peut communiquer, au moins pour la première communication.
C'est le endpoint 0.

1.2.3 Les diérents types de endpoints

An d'adapter les protocoles de dialogue du mieux que possible aux diérents types de don-
nées, l'USB prévoit diérents types de endpoints, qui fonctionnent chacun diéremment.

Endpoint de contrôle Ceux-ci servent à congurer les périphériques, à dialoguer avec eux
pour tout ce qui est de l'ordre de l'administration, de la conguration. Par exemple, l'endpoint
par défaut est un endpoint de contrôle.

5
Endpoint d'interruption Les périphériques sont amenés à pouvoir déclarer des interruptions.
Problème : L'hôte a la main, et la seule chose que puissent faire les périphériques est d'attendre
que l'hôte veuille bien les écouter. Cela pose donc problème pour les interruptions. L'endpoint
d'interruption sert à contourner ce problème : l'hôte garantit qu'il consultera régulièrement cet
endpoint, avec une latence maximum de x ms. Ainsi, le périphérique peut placer ses interruptions
dans cet endpoint, et a la garantie que d'ici moins de x ms, l'hôte considérera son interruption.
La latence maximale est dénie par le périphérique, qui peut demander une valeur entre 10 et
255 ms en Low Speed, entre 1 et 255 ms en Full Speed, et entre 125 µs et 4 s pour du High Speed.

Endpoint de transfert isochrone Certain périphériques sont très sensibles à la bande pas-
sante et à la latence, beaucoup plus qu'à l'erreur. Ainsi, une carte son, ou une webcam, vont
avoir besoin d'une bande passante garantie, et d'une latence faible. La correction d'erreur n'a par
contre que peu d'intérêt, l'erreur n'étant pas très grave, la correction risquant d'arriver trop tard.
Ainsi, avec un endpoint de transfert isochrone, l'hôte va faire en sorte de lui attribuer une grande
bande passante, une faible latence, mais ne tiendra pas compte de ses accusés de réception.

Endpoint de transfert bulk D'autres transferts, par contre, n'ont que peu de contrainte
de temps, mais on attend d'eux qu'ils fournissent une information able. On pourra citer par
exemple, l'acquisition d'une image avec un scanner, l'envoi d'une tâche à une imprimante. Avec ce
type d'endpoint, l'hôte va donc faire en sorte que tous les paquets qui transitent soient arrivés,
et corrects : contrôle du CRC et prise en compte des acquittements, avec renvoi des données
erronées ou manquantes sont donc de rigueur.

Retour sur les vitesses théoriques Maintenant que nous avons vu les diérents types de
transferts possibles en USB, revenons sur les vitesses théoriques que nous avions annoncé. L'hôte
réserve au moins 10% de la bande passante pour les transferts de contrôle. Ensuite, le reste est
donné en priorité aux transferts périodiques (isochrones & d'interruption), et enn, la bande
passante restante peut être utilisée par les transferts de type bulk.

1.3 L'USB dans un STM32

1.3.1 L'implémentation de l'USB dans un STM32

Le STM32 propose l'USB directement en hardware, en 2.0 Full Speed. Il propose aussi la
norme USB On-The-Go. Il gère en hardware la génération et le décodage de CRC, la mise en
forme des transactions. Il est possible d'avoir de 1 à 16 endpoints, selon leur nature. Le STM32
gère la mise en veille de l'USB, et propose les transferts bulk et isochrones avec un système de
double buers.

1.3.2 Les buers dans un STM32

Au moins un buer est associé à chaque endpoint. Les endpoint bidirectionnels utilisent deux
buers, un pour la réception, et un pour la transmission : ainsi, le périphérique ira lire régulière-
ment dans le buer de réception, et on écrira dans le buer de transmission pour transmettre
des données à l'hôte. Le STM32 ore aussi la possibilité d'utiliser deux buers pour un endpoint
monodirectionnel, dans le cas d'un transfert isochrone ou bulk, pour maximiser la bande pas-
sante. En eet, si le STM32 est encore en train de traiter l'échange précédent alors qu'un autre
arrive, il va refuser l'échange, occasionnant ainsi une perte de bande passante. D'où l'intérêt

6
de travailler avec deux buers : l'un sera rempli de données avec lesquelles le STM32 pourra
travailler, l'autre sera libre pour que l'hôte le remplisse.

1.3.3 Comment utiliser l'USB dans un STM32 ?

Du point de vue physique, il faut brancher un port correspondant à un périphérique sur des
pins adaptés du STM32. Au niveau du software, toute la conguration de l'USB se fait via des reg-
istres. Pour aider le développeur, STMicroelectronics met à disposition une bibliothèque destinée
à l'utilisation de l'USB Full Speed sur STM32F10xxx, contenant de nombreux exemples. Celle-ci
est disponible à l'adresse suivante :http://www.st.com/internet/com/SOFTWARE_RESOURCES/
SW_COMPONENT/FIRMWARE/um0424.zip. Un manuel pour l'utilisation de cette bibliothèque est
disponible à cette adresse : http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_
LITERATURE/USER_MANUAL/CD00158241.pdf (consultez directement le site de ST si vous voulez
être sûr d'avoir les versions les plus récentes).

7
Chapitre 2

Les cartes SD dans l'embarqué

2.1 Introduction

Les cartes SD orent des possibilités de stockage importantes (aujourd'hui jusqu'à 64Go)
et cela pour un coût relativement faible, de plus l'interface utilisée pour la lecture et l'écriture
depuis un microcontrôleur est simple à mettre en ÷uvre , c'est probablement pour ces raisons
qu'elles sont devenues les cartes les plus utilisées dans le domaine de l'embarqué on en trouve
dans les téléphones portables, dans les GPS, dans les appareils photos, dans les caméras etc.
Elles peuvent utiliser un système de chier type FAT ce qui les rends compatible avec un
ordinateur "classique". Il existe plusieurs formats pour la carte SD (SD, miniSD, microSD), elles
sont rangées en trois classes de capacités (SDSC, SDHC, SDXC) qui dénissent l'espace mémoire
disponible sur la carte.
Cet article a pour but de permettre au lecteur de comprendre le fonctionnement général des
cartes SD an de donner des pistes pour l'implémentation dans un système embarqué, pour
plus d'informations il faudra se référer à la spécication disponible sur www.sdcard.org . Nous
détaillerons dans un premier temps l'interface électrique utilisé par les cartes SD avec un hôte,
typiquement un microcontrôleur. Une fois la carte connectée à l'hôte nous verrons comment
hôte et carte communiquent entre eux en expliquant les fonctionnalités de la carte SD puis en
décrivant les particularités des modes SPI et SD. Finalement et an de faciliter l'utilisation de
la SD avec un microcontrôleur STM32 nous donnerons des pistes à suivre pour la mise en place
de cette fonctionnalité.

2.2 L'interface électrique

L'interface d'une carte SD se fait généralement grâce à neuf broches, dont 3 (1bit), 4 (SPI) ou
6 (4bits) sont utilisées pour la communication selon les diérents modes les autres étant destinées
à l'alimentation, des interruptions ou inutilisées. Elle est capable de fonctionner à une fréquence
maximum de 50MHz et nécessite une alimentation entre 2.7V et 3.6V. Elle communique avec
l'hôte en 3.3V et peut atteindre une vitesse de transfert théorique de 25MB/s pour une fréquence
de 50MHz en utilisant les 4 lignes de données.
Selon la spécications de la carte SD une résistance de pull up entre 50 et 100k ohms de-
vrait être placé sur la première ligne du bus de donné. Les broches des cartes SD possèdent
des noms et des rôles diérents suivant le mode utilisé (g1), en eet il est possible de comman-
der la carte SD de 3 façons diérentes, suivant le mode SPI ou suivant les modes SD 1bit et 4bits :

8
 (1) Le mode SPI utilise le bus générique SPI (serial peripheral interface) c'est un bus très
utilisé et multi-duplex (plusieurs périphériques esclaves connectés) et la plupart des microcon-
trôleurs le supportent nativement. Il utilise 4 lignes : une pour l'horloge (CLK), une pour les
échange hôte->carte (DI), une pour les échanges carte -> hôte (DO) et une pour la sélection de
la carte (CS). Ce mode ne reconnait pas toute les commandes du SD Card Protocol, cependant
les commandes reconnues susent pour une utilisation fonctionnelle de la carte.

(2) Le mode SD 1bits est un protocole synchrone utilisant une seule ligne de donnée (DAT0)
une ligne pour l'horloge(CLK) et une pour les commandes/réponses(CMD). Il est possible de
partager le bus de donné et celui d'horloge entre plusieurs cartes SD. Ce mode utilise un système
de vérication de l'intégrité des données (CRC) qui permet de detecter la présence de bits inversés.

(3) Le mode SD 4bits est identique à celui 1 bits mis à part qu'il utilise 4 lignes de données
en parallèles. Cela permet théoriquement de quadrupler le débit.

Figure 2.1  Rôle des broches pour les modes SD et SPI

Source
1

2.3 Les fonctionnalités de la carte SD

Lors d'une communication, c'est l'hôte qui contrôle tous les échanges, pour le mode SD il existe
deux types de commandes les adressées et les non-adressées (broadcast). Toutes les commandes
adressées nécessites une réponse de la carte concernée, pour les non-adressées une réponse est
parfois requise. Dans le mode SPI chaque commande attend une réponse, l'adressage se fait grâce
aux lignes CS.
C'est grâce à ces commandes que l'hôte contrôle les échanges, elles sont constituées d'un
identiant et d'arguments. Il en existe un grand nombre qui permettent d'envoyer diérentes
requètes telle que reset de la carte, lecture de blocs multiples, changement de la taille des blocs
etc.
Une carte SD possède un contrôleur, c'est ce contrôleur qui communique avec l'hôte, traite
les commandes et renvoi les réponses et les données. Ce contrôleur est une machine à état, les
états sont par exemple : "Inactive State", "Ready state", "disconnect state" etc.

2.3.1 La phase d'initialisation

Lors de la phase d'initialisation hôte et cartes vont s'échanger des informations suivant une
séquence d'initialsation particulière via les lignes de commandes (une pour chaque carte) grâce à

1. http://elm-chan.org/docs/mmc/mmc_e.html

9
un système de commande/réponse (voir la spécication pour plus de détail) . Cette phase permet
de connaitre le mode de communication (SD ou SPI) de vérier que la tension utilisée par l'hôte
est compatible avec l'utilisation de la carte, elle permet de placer le contrôleur de carte dans
l'état initialisé et de positionner la fréquence de communication au maximum.

2.3.2 La phase de transfert de données

L'envoi de commande aux cartes par l'hôte va modier les états des contrôleur de cartes,
par exemple si l'hôte veut écrire sur une carte A il va devoir lui envoyer la commande CMD7
qui la fera passer de l'état "Stand-by State" à "transfer state" puis la commande CMD6 qui la
fera passer dans l'état "Sending data state" puis de nouveau la commande CMD7 pour arrêter
l'envoi et refaire passer le contrôleur de la carte A dans l'état "Stand-by State" (le détail des
commandes est disponible dans la spécication).
Les données sont par défaut transférées sous forme de bloc de 512 octets, de bit de start et
de stop et d'un CRC.
La lecture peut se faire de deux façons : soit l'hôte demande l'envoie d'un bloc en transmettant
l'adresse du bloc soit il demande l'envoi de n blocs depuis une adresse, si n n'est pas spécié la
carte enverra continuellement les blocs à partir de celui dont l'adresse a été transmise, le transfert
s'arrêtera seulement sur réception d'une commande spécial.
Pour l'écriture c'est le même principe, l'hôte spécie l'adresse à partir de laquelle il veut
écrire, attend une réponse positive de la carte (elle n'est pas déjà occupée) et envoi le premier
bloc.

2.4 Les modes de communications

2.4.1 Mode SD
Mode SD 1 bit Pour utiliser ce mode il faut que le microcontrôleur possède une interface
SDIO. A la diérence du mode SPI, commandes et réponses sont échangées sur la même ligne.
Ce mode ore un panel de commande plus large que le mode SPI.
Lors d'une requête d'écriture de l'hôte par exemple, il envoi une commande sur la ligne CMD,
attend une réponse de la carte toujours sur la ligne CMD cette réponse fourni l'information sur
l'état courant de la carte. Si la réponse précise que la carte est prête pour une écriture, l'hôte
doit alors envoyer les données par bloc de 512 octets (par défaut) à la carte sur la ligne de donnée
DAT0.

Mode SD 4bits 4 blocs de données sont envoyés simultanément sur les 4 lignes de données,
le reste se passe de la même façon que pour le mode 1 bit.

2.4.2 Mode SPI

2
Plus simple que le mode SD, le mode SPI a de plus la propriété de pouvoir être intégré à un
système ne possédant pas d'interface SDIO nativement. C'est donc ce mode là que l'on utilise
forcément lorsque notre microcontrôleur ne gère pas l'interface SDIO.
Lors de la mise sous tension de la carte elle est en mode SD, elle passera en mode SPI si lors
de l'envoi de la commande de reset CMD0, la ligne CS est maintenue à 0. La carte répondra
alors en mode SPI, sinon elle considérera que le mode est le mode SD.

2. http://www.sdcard.org/

10
 Figure 2.2  Lecture d'un bloc en mode SPI

L'hôte envoi ses commandes et les données à écrire sur la ligne DI (dataIn) et les cartes
répondent et envoient les données à lire sur la ligne DO (dataOut). La ligne CS permet de
signaler à la carte si c'est avec elle que l'hôte communique.

2.5 Application à un STM32

Certains des microcontrôleurs de la famille STM32 possèdent une interface SDIO, le stm32f103ret6
par exemple. Ils orent tous la possibilité d'utiliser le mode SPI. Ces microcontrôleurs sont donc
tout à fait capable de communiquer avec une carte SD. Pour mettre en ÷uvre le support des cartes
SD sur un microcontrôleur STM32 il existe plusieurs bibliothèques implémentant ces fonctions :
En mode SPI : La bibliothèque ChaN's FAT-Module qui est téléchargeable accompagnée
d'exemples d'utilisation et qui permet d'utiliser le système de chier FAT32.
En mode SD : La bibliothèque STM32F10xFWLib de STMicroelectronics, très dicile à
trouver, fourni les fonctions nécessaires à l'utilisation du mode SD.

11
Chapitre 3

IP Embarqué

3.1 Présentation de TCP/IP

Généralités Le protocole TCP/IP est un protocole pour se connecter sur Internet. On a l'habi-
tude de décomposer l'ensemble de la chaîne en 4 couches :

1. Application (ex : POP3, HTML)

2. Transport (ex : TCP, UDP)

3. Reseau (ex : IP, ICMP)

4. Physique (ex : Ethernet, modem, Wi)

Ici nous nous préoccuperons du cas de l'Ethernet sur les STM32. L'Ethernet se compose de
deux couches : une couche physique (nommée couche PHY) et une couche MAC.
 La couche PHY s'occupe de la transmission eective des signaux électriques. C'est le lien
entre le câble RJ45 (et donc l'extérieur) et le reste du système.
 La couche MAC s'occupe de délimiter les trames entrantes et sortantes ; de plus, c'est au
niveau de cette couche que l'on ajoute l'adresse MAC.

TCP/IP embarqué Il est nécessaire de porter le protocole TCP/IP sur les systèmes embar-
qués car de plus en plus les applications ont besoin d'un accès Internet ou désirent stocker et
récupérer des données. Par exemple, il est désormais inimaginable de concevoir un téléphone
portable sans accès Internet. Pour les données que l'on stocke, beaucoup de systèmes embarqués
ont une mémoire limité d'où l'intérêt d'avoir un serveur à distance qui garde durant un certain
laps de temps les données et qui les envoie seulement quand le système embarqué a besoin de ces
informations.
Comme dit précédemment, on va s'occuper ici uniquement des cas où le système embarqué
communique via Ethernet. C'est donc pour les composants xes et proches d'un réseau laire
que la présente présentation est destinée.

3.2 Ethernet et les STM32

Regardons les STM32 que nous utilisons usuellement : Nous avons les familles des STM32F103,
des STM32F105 et celle des STM32F107. Les STM32F103 et F105/F107 n'intègrent pas les
mêmes composants et cela a une inuence sur la gestion d'Ethernet.

12
 Figure 3.1  Schéma du support Ethernet sur STM32F105/107
Source : STM32 Seminar : Connectivity Line (Nov 2010)

3.2.1 STM32F103
Les STM32F103 ne possèdent ni la couche MAC ni la couche PHY. Pour avoir un accès
Internet, il faut donc ajouter un composant tel que le Microchip ENC28J60.
Ce module est l'un des moins cher du marché avec des caractéristiques très intéressantes. Il
communique avec la carte STM32 par le bus SPI (l'ENC est toujours esclave dans cette relation)
et possède un buer de 8ko de RAM pour garder les informations temporairement. Il fonctionne
sous 3.3 V et sous 5 V et a besoin d'une horloge de 25MHz pour la synchronisation.
Le buer est divisé en deux parties : la partie qui reçoit les données et celle qui les transmet.
Quand le ENC28J60 reçoit des informations de l'extérieur, il envoie un message (il met le Chip
Select du SPI à 1) au STM32 le prévenant qu'il a des informations à donner et quand le STM32
accepte, il les envoie. Dans l'autre sens, le microcontrôleur prévient le ENC28J60 qu'il enverra
des données et les lui envoie. L'hôte peut envoyer des commandes comme Je veux lire à telle
adresse, quel est l'état des registres.

3.2.2 STM32F105/107
Les STM32F105/107 possèdent une couche MAC mais il leur faut ajouter la couche PHY.
Ainsi, il faut un PHYceiver qui se branchera à un cable RJ45, tel le ICS 1890.
La communication entre le PHYceiver et la couche MAC se fait par protocole MII ou RMII.
De plus, le protocole MDIO s'occupe des registres de la PHY. Pour se connecter au MII, on a
besoin de 16 pins : 8 de data, 8 de contrôle ; pour RMII (reduced), il n'en faut que 7 pins : 4 de
data, 3 de contrôle.
La couche MAC peut avoir un taux de transfert de 100 Mbits/s avec des opérations en full-
duplex. Elle intègre une détection des trames entrantes et une vérication de checksum pour
chaque trame.
Le STM32 possède un contrôleur DMA (Direct Memory Access) avec un buer pour envoyer
et recevoir les données. En envoi, le buer stocke les données et quand le seuil de remplissage
du buer est atteint, les données sont envoyées à l'adresse IP précisée. En reception, les données
sont gardées dans le buer tant que le bus AHB n'est pas prêt. Ce bus sert de liaison entre les
diérents composants de la carte.

3.3 Piles TCP/IP gratuites

Désormais, nous avons accès à Internet depuis le STM32. Il faut cependant traiter les in-
formations pour en tirer les données utiles. Soit on fait ça à la main, soit on utilise une pile
déjà faite. Une pile c'est un ensemble de fonctions et bibliothèques programmées pour gagner du
temps. Sur STM32, il existe de nombreuses piles TCP/IP dont deux sont gratuites.

13
3.3.1 uIP/lwIP
Explications Les piles uIP / lwIP (microIP / light weight IP) sont deux piles TCP/IP simi-
laires. Je parlerai principalement de lwIP. lwIP est une pile gratuite développée par un univer-
sitaire suédois, Adam Dunkels. C'est une pile open source qui supporte les protocoles IP (v4 et
v6), UDP, TCP, ICMP, PPP et ARP. Cependant, les protocoles d'applications sont à développer
par soi-même (tel HTTP ou FTP). Sur Internet, il existe de nombreux exemples si vous en avez
besoin. lwIP possède 3 API pour développer ses applications :
 raw API : API native, puissante mais un peu complexe.
 Netconn API : API plus haut niveau
 socket API : Proche du BSD Socket.
Adam Dunkels a écrit une documentation pour programmer avec lwIP. Le document s'appelle
Design and Implementation of the lwIP TCP/IP Stack.

Sur STM32F107 Pour porter la pile lwIP sur un microcontrôleur, il faut créer son driver
Ethernet. Cependant, la pile lwIP possède de nombreux chiers de congurations dont les chiers
ethernetif.c et stm32eth.c. Ces chiers sont à compléter et servent à faire le lien entre la pile et
le contrôleur Ethernet de la STM32.
Il est possible de suspendre certains protocoles de lwIP ou certaines propriétés hardware du
STM32. Pour cela, il faut modier certains chiers. Par exemple, la vérication du checksum peut
être annulée si on modier une ligne dans lwipopts.h. Pour plus de détails sur la conguration
en générale de la pile lwIP avec les STM32, se référer à la note d'application AN 3102.

3.3.2 NicheLite
Explications NicheLite est une pile TCP/IP rapide,complète et optimisée pour les applications
embarquées. Depuis quelques temps, elle est gratuite sur STM32.
Le schéma ci-dessous montre les capacités de cette pile ainsi que les possibilités d'applications
à développer.

Figure 3.2  Protocoles supportés par NicheLite

Source : Documentation de NicheLite.

14
Sur STM32 Le code source de NicheLite est libre et il sut de congure modier quelques
chiers header ou en C pour obtenir les informations utiles et congurer la liaison entre NicheLite
et la couche Ethernet. Pour plus de détails, se réferrer à la note d'application AN 3000.

Figure 3.3  Les diérents dossiers de NicheLite

Source : AN 3000.

15
Chapitre 4

6LowPan

4.1 Introduction à 6LoWPAN

La norme 6lowpan (IPv6 sur réseaux personnels de faible puissance) dénit le format des
"frames" pour la transmission de paquets IPv6, ainsi que les adresses locales IPv6 et les adresses
auto-congurés au dessus des réseaux IEEE 802.15.4. Puisque la taille de MTU de l'IP est
de 1280B et la taille de MTU du protocole 802.15.4 est seulement de 127B, c'est impossible
d'encapsuler un paquet IP sur un paquet 802.15.4 sans un mécanisme d'adaptation. 6LowPan
se concentre sur les mécanismes nécessaires de compression, de fragmentation et d'adaptation.
6LoWPAN permet l'interopérabilité de réseaux internes (PAN) avec les réseaux extérieurs en
respectant la norme IPv6 et en même temps en conservant les fonctionnalités clés des réseaux
sans l comme la abilité, la sécurité, et la consommation d'énergie limitée, au sein de ressources
fortement limitées. La combinaison des normes mentionnées ci-dessus est dénommée "Internet
sans l embarqué" et permet l'insertion de milliards de dispositifs connectés à Internet au service
de nombreuses applications comme l'automatisation du bâtiment, les compteurs intelligents,
l'automatisation industrielle ou personnelle.
Ce document sera organisé en trois parties. Premièrement, nous parlerons de certains points
clés du standard 802.15.4, puisqu'il fournit des services de communication de base avec une
faible puissance et complexité. Dans la deuxième partie, nous examinerons la compression, les
mécanismes d'adaptation/compression et la fragmentation qui permettent d'envoyer des messages
IP sur 802.15.4. Enn une architecture d'implémentation de 6lowpan basée sur les processeurs
STM32 sera décrite.

4.2 Introduction à 802.15.4

La norme 802.15.4 propose un type de réseau de communication sans l simple, à faible coût
qui permet la connectivité aux applications avec une puissance limitée et des conditions restreintes
de débit de communication. Elle fournit une infrastructure pour le transfert de données ables
dans un rayon proche avec un coût extrêmement faible. Certaines des caractéristiques de LR-
WPAN sont :
 Les débits de données de 250, 100, 40, 20 kb / s.
 Conguration réseaux étoile ou peer to peer
 Allocation d'adresses de 16 bits ou 64bits
 Attribution facultative des tranches de temps garanties

16
  Accès multiple au canal avec CSMA /CA.
 Protocole entièrement reconnu pour la abilité de transfert
 Faible consommation
 Indication de qualité du Link
Les types de dispositifs qui constituent le c÷ur du réseau Pan (Personal Area Network) 802.15.4
sans l sont les FFD (Full-function Devices) qui peuvent fonctionner dans deux modes de fonc-
tionnement : Pan coordinateur, coordinateur, dispositif simple. Un autre type de dispositif qui
décrit principalement les "points d'extrémité de ce qu'on appelle l'Internet sans l embarqué
sont les dispositifs qui s'appellent "Reduced Function Devices" (RFD). Ces appareils ne peuvent
communiquer qu'avec leur FFD local et décrivent les n÷uds "spéciques a l'application" dans le
sens qu'ils n'ont pas la fonction de coordinateur.

4.2.1 Topologies de réseaux

Les n÷uds du réseau peuvent être connectés des façons suivante : a) topologie en étoile, b)
topologie peer to peer selon les spécications d'application. En topologies en étoile un dispositif
FFD coordonne le réseau puisque tous les n÷uds communiquent par son intermédiaire. Chaque
n÷ud du réseau dispose d'une adresse 64 bits ou une adresse de 16 bits (court) qui est délivrée
par le coordinateur de PAN. Des exemples d'applications qui pourraient tirer prot de ce type
de topologie sont : L'automatisation personnelle, les appareils de jeux et les dispositifs de soins
de santé.

Figure 4.1  Topologies de réseaux pris en charge par 80.15.4

Source : 802.15.4 standard

Dans un réseau peer to peer, les dispositifs communiquent les uns avec les autres tant qu'ils
peuvent s'atteindre. Ces topologies de réseau nécessitent l'auto-organisation et permettent l'util-
isation des protocoles de routage. Ces protocoles ne sont pas dénis dans la norme 802.14.5, mais
sont plutôt dénis au niveau IP. La norme 6lowpan ne dénit pas le routage, mais les mécan-
ismes de routage sont décrits par le standard d'IETF qui concerne l'optimisation du Neighbor
Discovery pour les réseaux de faible puissance, standard encore en développement.
Dans la topologie en étoile, les FFD (coordinateurs) choisissent un identiant unique PAN
qui n'est pas utilisé par les autres réseaux PAN à proximité. L'identiant PAN permet aux autres
dispositifs d'être connecté dans le même réseau. Dans les réseaux peer to peer des groupes peuvent
êtres formés, chaque groupe a un coordinateur qui fournit des mécanismes de synchronisation.
Ces groupes sont hiérarchisés et leur structure impose qu'il existe seulement un coordinateur
global orant des mécanismes de synchronisation pour le reste des coordinateurs. C'est possible
que le coordinateur donne le contrôle a un autre n÷ud du systeme

17
4.2.2 Principes de la couche physique dénie par 802.15.4
La couche physique de 802.15.4 est parfaitement adaptée aux besoins des topologies réseaux
de faible coût, faible consommation, faible débit. Les services de base qu'elle fournit sont la
transmission et la réception des données, l'indication de qualité de lien (IQT), l'activation et la
désactivation du récepteur de radio, de sélection de fréquence et la détection d'énergie (ED) dans
le canal actuel. Les principales caractéristiques de la couche physique sont la transmission 20kb
/ s, 40kb / s, 100kb / s, 250kb / s et l'opération dans l'une des bandes suivantes, 16 canaux dans
la bande 2450 MHz, 30 canaux dans la bande 915 MHz, et 3 canaux dans la bande 868 MHz.
Les schémas suivants résument les modes de fonctionnement de la couche physique 802.15.4.
 Un 868/915 MHz direct sequence spread spectrum (DSSS) PHY employant la modulation
(BPSK)
 Un 868/915 MHz direct sequence spread spectrum (DSSS) PHY employant la modulation
(O-QPSK)
 Un 2450 MHz direct sequence spread spectrum (DSSS) PHY employant la modulation
(O-QPSK)
Il convient de noter qu'il existe un degré de exibilité dans le choix du régime de modulation
appropriée pour l'application requise. La modulation BPSK implique de faibles débits et de
la complexité émetteur-récepteur à faible tandis que ASK, QPSK impliquent des débits et des
complexités plus élevés.

4.2.3 Principes de la couche MAC du 802.15.4

La couche MAC est responsable de l'accès au canal radio et fournit les tâches suivantes :
 Générer les balises du réseau (dit "beacons) si le dispositif est un coordinateur
 Synchronisation sur les balises du réseau
 Assurer la sécurité des terminaux
 Accès multiple au canal avec CSMA CA.
 Gestion et maintien du mécanisme de GTS (Guaranteed Time Service)
 Fournir un lien able entre deux entités MAC
 Dénition des modes d'adressage
La norme 802.15.4 dénit deux modes d'adressages locaux, soit le 64 bits IEEE EUI mode,
soit le mode 16 bits (court) d'adressage. Ces adresses sont employées directement par la couche
6LoWPAN an de produire directement les adresses IP. En outre le mode 16 bits permet davan-
tage de compression des en-têtes d'IP, même s'il y a certains cas où les adresses ne peuvent pas
être utilisées.
Il existe deux mécanismes principaux d'accès aux canaux soutenus par 802.15.4 : le slotted
CSMA, CA (Carrier Sense Multiple Access, Collision Avoidance) et l'unslotted CSMA. Dans
le premier cas, la synchronisation, l'identication PAN et l'échange de données se produisent
pendant les "superframes" qui sont délimités par des balises (beacons) du réseau émises par le
coordinateur de PAN.
Les "Beacons" identient le PAN, synchronisent les n÷uds connectés et décrivent la struc-
ture du "superframe". L'échange des données entre les appareils se passe pendant la période
de concurrence (conit quand tous les n÷uds partagent le medium), suivant le schéma "slotted"
CSMA CA. Des tranches facultatives de Guaranteed Time Service (GTS) pourraient être allouées
pour les applications nécessitant des limites minimum de bandwidth au cours de la période sans
conit.
Quatre types de cadres sont dénis par 802.15.4 : Les "frames" de données, les "frames"
Balise (Beacons), les "frames" d'acquittement et les "frames" commandes MAC. Il convient de

18
 Figure 4.2  "Network Superframes"
Source : 802.15.4 standard

noter que le "frame" IPv6 est portée par des frames de données. La fonction de chaque cadre a
pu être dérivée en examinant les protocoles d'échange de données dénis par 802.15.4
La norme 802.15.4 dénit le protocole d'échange de données entre un coordinateur et un
dispositif, mais laisse non spécié l'échange de données du protocole Peer to Peer, dans le cas
du Slotted CSMA et note la nécessité de synchronisation peer to peer. Dans le cas de l'échange
de données avec "unslotted" CSMA-CA, l'échange pourrait être eectué par radio-réception
constante.
L'échange de données d'un dispositif vers le coordinateur suit les protocoles décrits ci-dessous.

Figure 4.3  "Communication entre node-coordinateur. Slotted CSMA

Source : 802.15.4 standard

Figure 4.4  "Communication entre node-coordinateur sans "beacons". Unslotted CSMA

Source : 802.15.4 standard

Dans le cas du slotted CSMA, quand un dispositif veut envoyer des données au coordinateur il
attend le "Beacon" réseau. Après la réception du "Beacon" en utilisant les mécanismes CSMA-
CA, il envoie les données au coordinateur. Le coordinateur peut éventuellement envoyer un
"ack" pour indique la réception de données. En cas de réseau PAN sans Beacon , l'émission des

19
données est eectuée directement à l'aide du mécanisme unslotted CSMA. Le coordinateur peut
éventuellement envoyer un "ack" pour indique la réception de données.
Léchange de données coordinateur-dispositif suit les séquences représentées ci-dessous (Image
10 à fente / Image 11 fendue). Dans ce cas, si le coordinateur souhaite envoyer des données à
l'appareil, il notie par l'envoi d'un message porté au network "Beacon". Quand il est prêt,
l'appareil demande alors les données. Une fois que la réception de la demande a été acquittée, le
coordinateur envoie les données vers le dispositif réseau. Quand le dispositif a reçu les données
il peut envoyer un Ack. Une fois les données émises, le coordinateur supprime l'indication des
données de la liste des réseaux Beacon en attente.

Figure 4.5  "Communication entre coordinateur-node avec "beacons". Slotted CSMA

Source : 802.15.4 standard

Figure 4.6  "Communication entre coordinateur-node avec "beacons". Unslotted CSMA

Source : 802.15.4 standard

Dans les réseaux sans "Beacons" le coordinateur stocke les données qu'il veut envoyer au
dispositif. Quand le dispositif peut recevoir des données, il les demande au coordinateur qui les
envoie. Chaque accès au canal est fait par "unslotted-CSMA".
Un aspect très important de la communication coordinateur-dispositif dans les deux cas
(slotted, unslotted) est que l'émission des données est lancée par le dispositif du réseau. En
d'autres termes, le dispositif du réseau indique au coordinateur "Je t'écoute, tu peux m'envoyer
les données". Ce fait permet aux dispositifs du réseau de choisir quand ils vont "écouter" le canal
ou pas. Dans les systèmes avec des conditions de puissance faible, ce mécanisme est essentiel.

4.3 Transmission des données via des reseaux 802.15.4

Le contraste entre la taille d'un paquet 802.15.4 (127 octets) et le fait que le MTU (Maxi-
mum Transmit Unit) de IPv6 est de 1280 octets, conduit à la nécessité de la fragmentation et

20
la compression d'en-tête an de transporter des paquets IP sur les paquets 802.15.4. Le RFC
IETF 4944 explique comment créer un paquet 6LoWPAN en détail an d'eectuer un traitement
uniforme de logiciel sans avoir des contraintes.
Les paquets 6LoWPAN sont transportés par les paquets 802.15.4 comme charge utile. Ils se
composent d'un en-tête de pile qui est semblable à celui de l'IPv6. Dans IPv6 la pile d'en-tête
dénit les attributs suivants : l'adressage, options hop-by-hop, le routage, la fragmentation, les
options de destination, et enn la charge utile. En 6lowpan l'en-tête est composé dans l'ordre
suivant : adressage L2 (soit 64 bit soit 16 bit), options hop-by-hop (y compris la diusion L2
/ multicast), la fragmentation, et enn la charge utile. Pour le traitement uniforme de logiciel
d'une valeur "dispatch" précède toujours ces attributs et dénit leurs propriétés. Un exemple de
dispatch précédant le type en-tête spécique est montre dans l'image 12.

Figure 4.7  "Dispatch and Type specic header (RFC 4944)"

Source : RFC 4944

La tête d'adressage 6LoWPAN utilise un type du niveau L2 (MAC) alors, soit 64 IEEE ou 16
bits d'adresse locale qui est obtenu pour chaque n÷ud après d'une processus de `nommage ' . Le
coordinateur de PAN est responsable de cet événement. Par exemple, tous les n÷uds partageant
les mêmes PAN ont le même préxe 64 bits d'adresse IPv6, il n'y a aucune raison pour insérer
la longueur totale de 128 bits à l'adresse de destination dans un paquet qui est interne au réseau
PAN. Bien sûr, cela implique l'existence d'un "Gateway" qui traduira l'adresse IPv6 de 128 bits
en une adresse de destination 6LoWPAN comprimée (64 ou 16 bits). Quand le "Gateway" reçoit
un message avec une destination externe en mode local bits 64/16, il peut la traduire en IPv6 (128
bits). L'interopérabilité sera mentionnée au paragraphe suivant. Bien sûr, l'en-tête d'adressage
6LowPan est facultatif et est utilisée lorsque le routage est nécessaire à l'intérieur du réseau PAN,
ou quand un n÷ud à l'extérieur du réseau PAN doit être atteint. Il n'y a aucune signication
en ajoutant cette adresse quand les valeurs de destination de couche L2(MAC) et de destination
6LowPan sont identiques.
L'en-tête de fragmentation dénit la taille totale du paquet au niveau IP qu'il faut fragmenter,
le décalage du fragment en cours et la valeur de la variable qui associe tous les fragments au paquet
IP initiale (tag). La taille du paquet à fragmenter a pu être envoyée seulement sur le premier
paquet fragmenté an de permettre l'allocation de tampon. Mais depuis l'arrivée dans l'ordre
n'est pas assurée, il est conseillé de contenir la taille dans chaque paquet de la fragmentation.

4.3.1 Interoperabilite de 6LowPan

Deux types de ux de communication IP existent : 1) Communication lancée à partir d'un
n÷ud appartenant à l'extérieur relativement au réseau PAN, s'adressant à un n÷ud à l'intérieur
du réseau PAN et de la communication initiée à partir d'un n÷ud du réseau PAN s'adressant à

21
un n÷ud de l'extérieur du réseau PAN. Un "Gateway" est nécessaire pour eectuer la traduction
IPv6 à 6LoWPAN an de relier ces deux mondes. Ce genre de traduction ou de compression
/ décompression doit consister en la suppression / ajout des 64 bits de préxe IPv6 quand un
paquet entre ou sort du PAN. Le Gateway peut également comprimer l'adresse de 64 bits à 16
bits en utilisant une table de cartographie...
Dans le cas où un n÷ud du monde extérieur veut communiquer avec un n÷ud à l'intérieur
du réseau, le "Gateway" pourrait probablement exécuter la compression du message IPv6 en un
message 6LowPan. Cela signie de retirer/ ajouter le préxe et la traduction des adresses 64 bits
locales en adresses de 16 bits et vice versa. Dans le cas où n÷ud PAN initie une communication
avec un n÷ud externe, cela signie que l'envoi du premier message de leur communication, le
n÷ud PAN doit ajouter l'adresse complète des 128 bits au destinataire IPv6, puisque le "Gate-
way" n'a évidemment pas associé cette adresse 128 bits à une 16 bits. Ce dernier est cependant
vrai quand un n÷ud PAN répond à un message qu'il a reçu du "monde extérieur".

4.3.2 Routage de 6LowPan

Le routage dans un réseau 6LoWPAN est une procédure assez délicate car la mémoire et les
ressources de traitement sont limitées. En plus, des facteurs comme la distance de transmission
limitée et les n÷uds Pan "en sommeil" compliquent les mécanismes de routage. Par conséquent il
n'y a pas de mécanismes absolument dénis pour le routage proposés pour 6LowPan. Cependant,
il existe les deux grandes catégories de routage 6LoWPAN : 1) Mesh under. 2) Route over.
En routage Mesh under, un message est transmis, donc envoyé à un voisin an d'aller plus
proche  jusqu'au destinataire nal. Une fois que le message arrive à un n÷ud dont l'adresse
couche MAC est égale à l'adresse de destination encapsulé, le paquet 6LoWPAN est reçu avec
succès. En "Route over", les tables de routage et les en-têtes hop by hop sont utilisés an de
déterminer le chemin du paquet. Il a été mentionné que dans le cas des données fragmentées, le
"route over" est plus able que le Mesh under [1].

4.4 Implémentation du 6LowPan sur les processeurs de la

famille STM32 - Nanostack

Nanostack 1.1 est une plate-forme ouverte de 6LoWPAN au dessus de 802.15.4 développée
par Sensinode, une société nlandaise qui eectue de la recherche en propriété intellectuelle sur
les systèmes embarqués sans l. Cette mise en ÷uvre est pleinement conforme à la spécication
RFC 4944 et propose une interface socket facile à utiliser pour le développeur. Le Nanostack est
développé sur le noyau FreeRTOS et possède les "drivers" pour les radios CC2420 CC2430 de
TI . Nanostack fournit également Nanomesh qui utilise les tables des routages et les tables de
voisins du node pour faire le routage. Une mise en ÷uvre de 6LoWPAN Nanostack par rapport
aux processeurs de la famille STM32 pourrait être mise en ÷uvre par l'installation de Nanostack
sur FreeRTOS. Pour obtenir la couche physique et la couche de liaison, il est possible d'utiliser
un composant comme le CC2420 ou le CC243 en le connectant à l'interface SPI du processeur
STM32.

22
4.5 Bibliographie

4.5.1 USB
USB in a Nutshell : http://www.beyondlogic.org/usbnutshell/usb1.shtml
Reference Manual des STM32F103xx
http://www.stackableusb.org/white_paper_interrupts_and_usb.asp

4.5.2 Cartes SD
http://www.sdcard.org/
Le site de la SD card association :
La page wikipedia sur les cartes SD :http://en.wikipedia.org/wiki/Secure_Digital
STMicroelectronics : http://www.st.com/
Des informations sur le mode SD : http://wiki.seabright.co.nz/wiki/SdCardProtocol.
html
Des informations sur le mode SPI :
 http://alumni.cs.ucr.edu/~amitra/sdcard/Additional/sdcard_appnote_foust.pdf
 http://elm-chan.org/docs/mmc/mmc_e.html
ChaN's FAT-Module : http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/
arm_memcards/index.html

4.5.3 IP & Ethernet

Présentation en ligne des STM32F107 http://www.docstoc.com/docs/46523606/STM32F107-Ethernet-TCP-IP-
STM32 Seminar : Connectivity Line (Nov 2010)
ENC28J60 DataSheet
ST AN3102 (lwIP sur STM32F107)
ST AN3000 (NicheLite sur STM32F107)
Design and Implementation of the lwIP TCP/IP Stack (Adam Dunkels, 2001)

4.5.4 6lowPan
1 Route over vs. Mesh-under Routing for 6LowPan
2 A Comparative Study on Available IPv6 Platforms
3 802.15.4
4 RFC 4944 Transmission of IPv6 packets over IEEE 802.15.4 Networks
5 Interoperability of 6LoWPAN

23