Rapport d’UV Libre - Bienvenue dans le département...

Institut National des Sciences Appliquées

Département Architecture des Systèmes d’Information

Le protocole X10

Rapport d’UV Libre

PIERRE YVES A IMON , DAMIEN BARON, GUILLAUME TANGUY

Encadrés par M. FRÉDÉRICBAUCHER

Janvier 2004

TABLE DES MATIÈRES

Table des matières

I X10 version 1 7

1 Introduction 8

2 Etude du protocole 92.1 Trame du message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Message simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Message contenant de l’information . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Etude de la dynamique du protocole 113.1 Transmission d’ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Transmission standard (entre PC et CM11) . . . . . . . . . . . . . . . . . . . . 113.1.2 PC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.3 Le Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.4 Le checksum et l’acquittement . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.5 Interface prête à recevoir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.6 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.7 Application aux messages Extended . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Réception d’ordre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.1 Le signal de réveil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 La réponse du PC au signal de réveil . . . . . . . . . . . . . . . . . . . . . . . . 133.2.3 Le buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.4 Application aux messages Extended . . . . . . . . . . . . . . . . . . . . . . . . 133.2.5 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Quelque points pratiques 154.1 Longueur maximale entre deux éléments . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Débits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Envoi de messages X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3.1 Misterhouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.2 Packages Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 En cas de besoin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Description des expériences réalisées 175.1 Expérience n◦1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.1 Dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.2 Protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.3 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Expérience n◦2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.1 Dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.2 Protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.3 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.3 Expérience n◦3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3.1 Dispositif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Uv Libre X10 2

TABLE DES MATIÈRES

5.3.2 Protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3.3 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.4 Experiment n◦1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4.1 Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19



II X10 version2 21

6 Étude du module x10net 226.1 Structures de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.1.1 Les listes chaînées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.1.2 Déclaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.1.3 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.1.4 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.1.5 Les buffers de socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2 Périphériques caractère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2.2 Déclaration d’un fichier de périphérique . . . . . . . . . . . . . . . . . . . . . . 246.2.3 Opérations sur les fichiers de périphérique . . . . . . . . . . . . . . . . . . . . . 256.2.4 Blocage des Entrées/Sorties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.3 Périphériques réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4 Conception du module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.4.2 Fonctionnement général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.4.3 Description détaillée du programme . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Mise en œuvre 297.1 Le principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2.1 Le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2.2 Le routeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 L’étude de Heyu 328.1 Le matériel X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.2 Le programme Heyu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.3 L’architecture de Heyu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.4 Heyu 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

9 Les projets X10 349.1 MisterHouse (v2.86) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349.2 Java Home Automation (v1.1.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349.3 Linux X10 universal device driver (v1.6.9) . . . . . . . . . . . . . . . . . . . . . . . . . 349.4 Ppower (v0.1.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349.5 X10Controller(v1.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Uv Libre X10 3

TABLE DES MATIÈRES

9.6 Stantor (v05) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359.7 SweetHome (v1.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

III Annexes X10 v1 36

A Valeur des différents codes 37A.1 Code Maison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.2 Code Unité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37A.3 Code Fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B Etude du fonctionnement d’une télécommande X10 39B.1 Télécommande IR ou RF avec convertisseur X10 . . . . . . . . . . . . . . . . . . . . . 39B.2 Télécommande PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B.3 Module AM12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

IV Annexes X10 v2 40

C Annexe de test 41

D Code source 42D.1 Listingskeleton.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42D.2 Listingx10net.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42D.3 Listing lire_x10net.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

E Makefile 50

F Scripts pour le module 51F.1 Script de chargementload_x10net.sh . . . . . . . . . . . . . . . . . . . . . . . . . 51F.2 Scriptboucle.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

G Configuration 52

Bibliographie 53

Uv Libre X10 4

TABLE DES FIGURES

Table des figures

5.1 Dispositif expérimental n◦1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Dispositif expérimental n◦2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 Dispositif expérimental n◦3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1 Fonctionnement général du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.1 Architecture du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Uv Libre X10 5

PAGES DE SERVICE

Pages de service

Auteur(s)

X10 version 1

SÉBASTIEN BONVOISIN : [email protected]

X10 version 2PIERRE-YVES A IMON : @insa-rouen.frDAMIEN BARON : [email protected] TANGUY : [email protected]

Historique des versions

X10 version 1

X10 version 2

Uv Libre X10 6

Première partie

X10 version 1

Uv Libre X10 7

CHAPITRE 1. INTRODUCTION

Chapitre 1

Introduction

Le protocole X10 permet d’envoyer des ordres ou informations par courants porteurs ; concrètementon utilise les fils électriques de 230 volts existants dans l’habitation pour relier un module émetteur àun module récepteur. Le gros avantage du X10 est qu’avec ce type de matériel il ne faut pas de câblagesupplémentaire.

Le protocole X10 permet de gérer 256 modules, chaque module possède un code maison réglable deA à P, et un code unité réglable de 1 à 16 (Ce qui fait : 16 x 16 = 256 possibilités).

Un module est relié à un matériel électrique et va modifier le comportement de ce dernier en fonctiondes ordres qu’on lui donne. Il existe de nombreux modules à la norme X10 que l’on peut classer selonleur fonction :

★ Interface PC (CM11) module émetteur / récepteur permettant de contrôler tous les modules récep-teur de l’habitation à partir d’un PC

★ La télécommande radio : cette télécommande envoi des ordres radio à un module qui convertitles ordres reçus en courant porteur, permettant de contrôler des modules récepteur à partir d’unetélécommande.

★ Le module Appareil : il permet une fonction MARCHE / ARRÊT.★ Le module Lampe : permet les fonctions MARCHE / ARRÊT et VARIATION de l’intensité lu-

mineuse.★ Modules permettant la détection : contact de porte, bris de glace, mouvements, lumière.★ Modules de conversion des ordres X10 : radio vers courant porteur, infrarouge vers courant porteur.

Le but de ce rapport est de présenter la norme X10 par une étude de ce protocole puis par la dynamiqued’une communication entre un PC, une interface CM11 et le reste de la ligne.

Une deuxième partie présentera les différentes expériences réalisées ainsi que les résultats obtenus.

Uv Libre X10 8

CHAPITRE 2. ETUDE DU PROTOCOLE

Chapitre 2

Etude du protocole

Nous l’avons dit en introduction, le protocole X10 permet d’envoyer des ordres mais aussi des infor-mations. Seuls certains modules sont pas capables de gérer tous les ordres ou informations, cela dépendde sa fonction. Selon les modules utilisés, des ordres peuvent être envoyés, voici les plus courants :

★ Marche (on)★ Arrêt (off)★ Baisser (dim)★ Augmenter (brighten)★ Faire varier : +5, +10,. . .,+100, -5, -10,. . .,-100★ Tous modules ON★ Tous modules OFF

2.1 Trame du message

Un message (ordre ou information) est envoyé à tout le monde par le module émetteur. La trame de cemessage dépend de son contenu :

2.1.1 Message simple

Un message simple comprend onze cycles. Par simple, on entend ordre de base (Marche, Arrêt,. . .). Al’exception du code de début, chaque bit est écrit deux fois (la première étant sa vrai valeur, la deuxièmeson complément).

1× 2 3× 4× 5× 6 7× 8× 9× 10 11 Cycles10× 11 H8H8 H4H4 H2H2 H1H1 D8D8 D4D4 D2D2 D1D1 F1F1 Bits

en-voyés

DÉBUT

DU

CODE

CODE MAISON CODE FONCTION / UNITÉ FONCTION CORRESPONDANCE

Le bit FONCTION F1 indique si les bits D8D4D2D1 représentent un code unité (F1=0) ou un codefonction (F1=1). Un module émetteur commence par adresser un module récepteur (donc à envoyerd’abord un message avec un code unité). Une fois adressé, un module répond à n’importe quel ordreenvoyé jusqu’à ce que l’on adresse un autre module ou que l’on envoie l’ordre ’Tous Module OFF’.

Uv Libre X10 9

2.1. TRAME DU MESSAGE

2.1.2 Message contenant de l’information

Ce genre de message n’est pas très utilisé mais il s’agit de ceux qui nous intéressent dans notre étude.Ici, plusieurs cas se présentent :

Messages à longueur fixe, ce qui correspond à l’ordre ’Extended Code 1’ et qui est de 31 cycles.Cet ordre permet d’envoyer des paramètres (par exemple : ouverture d’un vélux de 35◦), et d’ajouter desnouvelles fonctions.

1× 2 3× 4× 5× 6 7× 8× 9× 1010× 11 H8H8 H4H4 H2H2 H1H1 D8D8 D4D4 D2D2 D1D1

DÉBUT DU CODE CODE MAISON EXTENDED CODE1(0111)

11 12× 13× 14× 15 16 à 31F1F1 U8U8 U4U4 U2U2 U1U1 16 bits

FONCTION CODE UNITÉ COMMANDE ET DONNÉES

Les bits de commande et de données sont définis dans l’annexe 1, mais nous n’allons pas nous enservir car cela ne fait pas partie de nos objectifs que d’utiliser de telles fonctions. Ainsi nous allons laisserde côté l’ordre ’Extended Code 1’.

Message à longueur variable, ou ordre ’Extended Data’ ou encore ’Extended Code 2’ (cette dernièredénomination est la plus récente). Cet ordre va nous être utile puisque il va nous permettre d’envoyerdes données quelconque, donc du texte formaté selon le code HTML. Le code ’Extended Data’ est suivid’octets qui représentent des données analogiques. Il ne devrait pas y avoir de trous entre le code ’Extenddata’ et les différents octets qui suivent. Le premier octet peut être utilisé pour indiquer le nombre d’octetsqui vont suivre. Si des trous apparaissent dans l’envoi, les codes pourraient être reçus par des modulesX10, causant ainsi des opérations erronées. (par trou, on entend cycle sans information. En effet, l’absenced’information est considérée comme la fin du message).

1× 2 3× 4× 5× 6 7× 8× 9× 1010× 11 H8H8 H4H4 H2H2 H1H1 D8D8 D4D4 D2D2 D1D1

DÉBUT DU CODE CODE MAISON EXTENDED CODE2(1100)

11 12× 13× 14× 15 16 à 16 + 8kF1F1 U8U8 U4U4 U2U2 U1U1 multiples de 8 bits

FONCTION CODE UNITÉ NB BITS DE DONNÉES+ DONNÉES

Pour envoyer une page HTML, il suffit de créer une trame ’EXTENDED CODE 2’ contenant commedonnées le code source binaire de la page Web. Mais ceci pose des problèmes car on va augmenter lenombre de cycle de manière considérable et donc le temps d’émission.

Uv Libre X10 10

CHAPITRE 3. ETUDE DE LA DYNAMIQUE DU PROTOCOLE

Chapitre 3

Etude de la dynamique du protocole

3.1 Transmission d’ordre

Une émission d’ordre X10 consiste en un échange d’informations entre le PC et le module CM11.Ensuite, le module CM11 envoie l’ordre sur le réseau électrique et tous les modules récepteurs analysentl’ordre reçu. Si cet ordre leur est destiné, ils l’appliquent sinon ils ne s’en occupent pas.

3.1.1 Transmission standard (entre PC et CM11)

Cela consiste pour le PC à envoyer soit le code maison et unité soit la fonction à réaliser (l’ordre). Ces

transmissions suivent le schéma suivant :

PC Interface : 2 octetsChecksum : 1 octet

Acquittement : 1 octetInterface prête à recevoir

3.1.2 PC Interface

Cette partie comprend 2 octets, le premier est le Header et le deuxième est soit le code maison suivitd’un code unité ou soit le code maison suivit de l’ordre à appliquer.

3.1.3 Le Header

La partie nommée Header est configurée comme suit :

Bit : 7 6 5 4 3 2 1 0

Bit 7 à 3 : il s’agit d’une chiffre entre 0 et 22 équivalent à la valeur à envoyer (22 correspond à 100%).

Bit 2 : Sa valeur est toujours ’1’ afin d’être sûr qu’il y a synchronisation entre le PC et l’interface.

Bit 1 : définit si l’octet suivant est un ordre (1) ou une adresse (0).

Bit 0 : définit si l’octet suivant est un ordre Extended (1) ou standard (0).

3.1.4 Le checksum et l’acquittement

Lorsque l’interface CM11 reçoit une transmission du PC, elle somme tous les octets reçu et retournela somme. Si elle est correcte, le PC retourne la valeur 0x00 pour indiquer à l’interface qu’elle peutenvoyer le message sur la ligne électrique. Sinon le PC réenvoie le Header :Code et attend de l’interfaceun nouveau checksum.

Uv Libre X10 11

3.1. TRANSMISSION D’ORDRE

3.1.5 Interface prête à recevoir

Une fois que le PC a envoyé la valeur 0x00 pour signifier que le checksum est correct, l’interfacecommence à envoyer l’ordre sur la ligne électrique. Lorsqu’elle a terminée, l’interface envoie au PCla valeur : 0x55. Le PC comprend grâce à ce signal que l’interface est prête à réaliser une nouvellecommunication.

3.1.6 Exemple

PC 0x04 (le bit suivant est une adresse, le seul bit à 1 permet la synchroni-sation)

PC 0x66 (adresse A1)CM11 0x6a (checksum : (0x04 + 0x66)&0xff)PC 0x00 (checksum correct)CM11 0x55 (interface prête à recevoir)PC 0x04 (le bit suivant est une adresse, le seul bit à 1 permet la synchroni-

sation)PC 0x6e (adresse A2)CM11 0x72 (checksum : (0x04 + 0x6e)&0xff)PC 0x00 (checksum correct)CM11 0x55 (interface prête à recevoir)PC 0x86 (indique que le bit suivant est un ordre standard et les 5 premiers

bits donnent la valeur 16)PC 0x64 (code maison : A ; code fonction : Dim.)CM11 0xe0 (checksum)

Le PC voit que le checksum est incorrect et va donc réenvoyer le mes-sage.

PC 0x86 (indique que le bit suivant est un ordre standard et les 5 premiersbits donnent la valeur 16(72%))

PC 0x64 (code maison : A ; code fonction : Dim.)CM11 0xe0 (checksum : (0x86 + 0x64)&0xff)PC 0x00 (checksum correct)CM11 0x55 (l’interface a finit d envoyer l ordre et est prête à recevoir)

Ceci représente

tout d’abord l’adressage du module A1 puis de A2 et ensuite de l’émission de l’ordre Dim avec commevaleur 72%.

3.1.7 Application aux messages Extended

La communication est basée sur le même principe sauf que l’on ajoute deux octets supplémentaires :

PC Interface : 4 octetsChecksum : 1 octetAcquittement : 1 octet

Interface prête à recevoir

Le Header est toujours le même dans ce cas : 0 0 0 0 0 1 1 1Le deuxième octet est : Code maison / 0 1 1 1Le troisième et le quatrième représentent les données et la commande dans le cas Extended 1 ou lesdonnées dans le cas Extended 2.Le checksum retourné par l’interface est défini comme suit :

Checksum = (Header + code + data + command)& 0xff

Uv Libre X10 12

3.2. RÉCEPTION D’ORDRE

3.2 Réception d’ordre

Dès que le module CM11 " voit " des données sur la ligne électrique, il envoi au PC un signal nommé" serial ring ". Ce signal déclenche la procédure de réveil du PC. Le module CM11 commence à uploaderle contenu de son buffer (10 octets max.) une fois que le PC a répondu au signal de réveil. Si le PC nerépond pas, le buffer du CM11 se remplit et une fois remplit il ne conserve aucune autre donnée.

3.2.1 Le signal de réveil

Il s’agit d’un signal répété toute les secondes jusqu’à ce que le PC réponde. Le signal envoyé est lesuivant : 0 1 0 1 1 0 1 0 (0x5a).

3.2.2 La réponse du PC au signal de réveil

Afin de signifier au module CM11 qu’il faut arrêter d’envoyer le signal de réveil, Le PC doit luienvoyer un signal d’acquittement : 1 1 0 0 0 0 1 1 (0xc3).

Remarque : le bit n◦2 de l’acquittement est égal à " 0 ", ce qui enlève toutes ambiguïtés concernant unéventuel envoi d’ordre X10 au lieu du message d’acquittement.

3.2.3 Le buffer

Les dix octets du buffer sont définis comme suit :

n◦ 0 : Nombre d’octets à uploadern◦ 1 : Fonction / Adresse / Masquen◦ 2 : Octets de données n◦ 0n◦ 3 : Octets de données n◦ 1n◦ 4 : Octets de données n◦ 2n◦ 5 : Octets de données n◦ 3n◦ 6 : Octets de données n◦ 4n◦ 7 : Octets de données n◦ 5n◦ 8 : Octets de données n◦ 6n◦ 9 : Octets de données n◦ 7

Le module CM11 va envoyer au PC seulement le nombre d’octet spécifié sur le n◦ 0 (on commence àcompter à partir de l’octet n◦1). La position du bit a 1 de l’octet n◦1 définit le numéro de l’octet oucommencent les données. Si sa valeur est 1, l’octet est définit comme une fonction. Si sa valeur est 0, ils’agit seulement d’octets indiquant une (des) adresse(s). Les octets de données sont du même format queles octets envoyés par un CM11 lors d’une transmission (sans le Header).

Une fois que la totalité du buffer a été uploader, il n’y a pas d’acquittement du PC vers le CM11 pourvérifier que le contenu du buffer n’a pas été modifié lors du transfert. Ce point risque de poser un légerproblème : il n’y a pas de vérification car la seule application d’une réception de message X10 est laréception de statut extérieur (par exemple, un détecteur de mouvement qui envoie un message pour direqu’il a détecter quelquechose). Bien que la réception de message X10 autre reste possible, le fait qu’iln’y a pas de vérification induit que le PC risque de mal interpréter certain message au cas ou il y auraitaltération du contenu du buffer.

3.2.4 Application aux messages Extended

Après un ordre Extended, le PC va attendre deux octets (dans le cas Extended 1) ou le nombre d’octetsindiqué sur l’octet suivant (dans le cas Extended 2).

Uv Libre X10 13

3.2. RÉCEPTION D’ORDRE

3.2.5 Exemple

CM11 0x5a (message de réveil du PC)PC 0xc3 (le PC est prêt à recevoir)CM11 0x05 (la valeur 5 indique que la transmission à une longueur de 5 octets)

0x04 (Octets de données n◦0 : les données commencent à l’octet n◦ 4)0xe9 (Octets de données n◦1 : Adresse J7)0xe5 (Octets de données n◦2 : Adresse J6)0xe5 (Octets de données n◦3 : Code maison J, ordre Bright)0x04 (Octets de données n◦4 : Il s’agit de la valeur 4/210*100 =1.9%)

Cette trans-

mission commence par réveiller le PC, puis signifie qu’un ordre de longueur 5 octets va être envoyé. Lemessage envoyé est l’éclairage de 1.9% des modules J et J7 (un module X10 a 210 niveau d’éclairage).

Uv Libre X10 14

CHAPITRE 4. QUELQUE POINTS PRATIQUES

Chapitre 4

Quelque points pratiques

4.1 Longueur maximale entre deux éléments

La distance maximale pouvant séparer deux éléments semble se situer aux alentours de 50 mètres.Cette distance est bien sur variable en fonction des conditions de la ligne électrique (bruit). Par contre,dans certains cas, on peut installer des répéteurs de signaux, ce qui permet d’augmenter cette distance.Mais ceci n’est possible que si on connaît la longueur des trames à répéter ; ainsi cette méthode n’est pasvalable pour les trames de type ’EXTENDED CODE 2’.

4.2 Débits

Le débit effectif semble se situer entre 30 et 300bps. Prenons l’exemple du fichier Html "hello world"qui fait 416 bits. Une fois la trame incorporée on en sera à 454 ce qui va prendre 1.5 seconde si l’onconsidère un débit à 300bps.

De plus, le nombre d’octets de données est défini sur 8 bits, il faudra donc nous limiter à des fichiersHtml de 28=256 octets maximum. En se limitant à cette taille et si l’on considère toujours un débit de300bps, cela donnerait un temps d’attente d’une dizaine de seconde secondes.

4.3 Envoi de messages X10

Il existe plusieurs moyens d’envoyer un message X10. Le premier que l’on n’étudiera pas est latransmission par télécommande infrarouge. Le deuxième est beaucoup plus pratique et plus performantpuisqu’ils sont transmis via un PC. Le PC est relié au réseau électrique via un module (CM11) qui contientun port série que l’on relie à l’ordinateur.

Il existe plusieurs logiciels conçus pour construire de tels messages. En général, on peut l’acquérirlors de l’achat d’un module CM11, ou plus simplement sur Internet. Voici quelques logiciels gratuits quel’on peut se procurer.

4.3.1 Misterhouse

Il s’agit d’un programme d’automisation de maison Open Source complètement gratuit et écrit en Perl.On peut le télécharger sur leur site à : http ://www.misterhouse.net . De nombreux exemples pour réalisernos propres programmes sont disponibles sur leur site ainsi qu’une FAQ sur l’installation et l’utilisationde leur logiciel.

4.3.2 Packages Debian

Voici la liste des packages disponibles sur Debian qui permettent de piloter des modules X10. Lelogiciel le plus apprécié s’appelle HEYU.

Uv Libre X10 15

4.4. EN CAS DE BESOIN. . .

heyu : 2 way x10 communications for the CM11Awmx10 : Control X10 home automation modules via a firecracker CM-17A X10 serial doglex10 : Operate X-10 electrical power control modulesx10-automate : GUI interface for x10 power line control utilityxtend : X10 status monitoring daemon

4.4 Liste des personnes à contacter en cas de besoin

Service technique : [email protected]éveloppeur X10 : [email protected]

Uv Libre X10 16

CHAPITRE 5. DESCRIPTION DES EXPÉRIENCES RÉALISÉES

Chapitre 5

Description des expériences réalisées

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Française . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Expérience n◦1 : Utilisation du matériel

5.1.1 Dispositif

Un PC est relié à un module CM11 qui est connecté au secteur. De plus, un module LM12 est relié àce même secteur.

FIG. 5.1 –Dispositif expérimental n◦1

5.1.2 Protocole

Le PC envoie alternativement l’ordre de mettre le module sur la position OFF ou ON.

5.1.3 Résultat

La lampe s’est éteinte et allumée, puis plus rien : impossible de la commander de nouveau. Il s’estavéré que cela était dû au module LM12 qui était défectueux.

Uv Libre X10 17

5.2. EXPÉRIENCE N◦2

5.2 Expérience n◦2 : Faire réagir un ordinateur qui reçoit un ordreX10

5.2.1 Dispositif

Un PC et son module CM11 sont reliés et branchés sur le courant. Un module lampe LM12 est relié àla ligne électrique ainsi qu’à une lampe de chevet.


5.2.2 Protocole

Le PC envoie l’ordre au CM11 d’envoyer sur la ligne électrique l’ordre de mettre à la position OFFle module A1 (module où l’on a installé la lampe). Le programme ’xtend’ (sous Linux) permet de faireréagir le PC à un ordre X10 qu’il reçoit (ici, on lui demande simplement d’afficher un prompt à l’écrandans le cas de la mise à ON ou a OFF du module A1).

5.2.3 Résultat

Le module LM12 étant défectueux (mais on l’a appris que plus tard), la lampe n’a pas changé d’état. LePC n’a d’ailleurs rien affiché à l’écran. Plusieurs raisons peuvent expliquer cela : soit le démon de ’xtend’qui scanne le port série ne s’occupe pas des ordres qui vont dans le sens PC-CM11, soit cela provient dumodule LM12 défectueux (mais cette hypothèse est peu probable car il n’y a pas d’acquittement de lapart du LM12). Une autre raison pourrait être que le logiciel heyu bloque l’accès au port série, xtend nepourrait donc pas y accéder. La dernière solution envisageable est une mauvaise configuration de ’xtend’.

5.3 Expérience n◦3 : Communication entre deux PC

5.3.1 Dispositif

Deux modules CM11, reliés chacun à un PC différent sont installés dans une pièce et branchés sur laligne électrique + module LM12.

Uv Libre X10 18

5.4. EXPERIMENT N◦1


5.3.2 Protocole

On lance en tâche de fond sur l’ordinateur récepteur le logiciel ’xtend’ configuré pour afficher unprompt à l’écran lors de la mise à ON ou OFF du module A1. A Partir de l’ordinateur émetteur, oncommande le CM11 en envoyant l’ordre de mettre à ON puis OFF le module A1.

5.3.3 Résultat

Le module LM12 défectueux ayant été changé entre temps, la lampe s’est bien allumée puis éteinte àla suite des émissions d’ordre. L’ordinateur récepteur a lui bien capté les ordres qui se présentent sur laligne électrique puisqu’il affiche a l’écran les prompts désirés au bon moment. On en déduit par rapportà l’expérience précédente que heyu bloque l’accès au port série. Il est à noter que le bruit présent sur laligne électrique peut perturber de façon non négligeable la bonne réception d’ordre X10.

5.4 Experiment n◦1 : The use of the material

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Anglaise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4.1 Device

A computer is connected to a CM11 interface which is linked to the power line. Moreover, a LM12module is also linked to this power line.

5.4.2 Protocol

The computer sends to the LM12 the following order : change state to OFF

5.4.3 Results

The lamp connected to the LM12 lights off and on but then, nothing else happened. It was due to thefact that the LM12 was defective.

Uv Libre X10 19

5.5. EXPERIMENT N◦2

5.5 Experiment n◦2 : Waking up a computer in response to an X10order

5.5.1 Device

A PC and its CM11 interface are linked to the power line. A LM12 lamp module is connected to thepower line and to a bedside lamp.

5.5.2 Protocol

The PC asks the CM11 to send the X10 order of changing state to OFF for the LM12 module (ad-dressed as A1). The ’xtend’ program makes it possible to execute a shell command as soon as its daemonsees a X10 order on the specified port (this is the serial port). Here, we simply ask xtend to prompt amessage on the screen if it detects a change of the LM12 module state).

5.5.3 Results

Since the LM12 module is defective (but we learned it only a few days ago), the lamp did not changeits state. The PC prompts nothing. This may be due to the fact that xtend daemon doesn’t care of themessages that are sent from PC to the CM11 interface. Another raison could be that heyu block the accessof the serial port. The last solution maybe an improper configuration of ’xtend’.

5.6 Experiment n◦3 : Communication between 2 PCs

5.6.1 Device

2 CM11 interfaces, each one is linked to its own PC, are placed in a room and connected to the powerline. The LM12 module is also connected to the line.

5.6.2 Protocol

We launch in background the xtend program on a computer. Xtend is configured in order to display aprompt on screen when the A1 interface changes its state. Another computer sends the order of changingthe state of the A1 interface.

5.6.3 Results

Since the defective LM12 interface has been replaced, the lamp lights on and off . The computer onwhich xtend was running successfully receives the X10 order. As a consequence, it displays on its screenthe state of the LM12 interface. We can deduct from this that heyu block the access of the serial port. Weshould also notice that the noise on the power line can alter the signal sent by heyu.

Uv Libre X10 20

Deuxième partie

X10 version2

Uv Libre X10 21

CHAPITRE 6. ÉTUDE DU MODULE X10NET

Chapitre 6

Étude du module x10net

6.1 Structures de données

6.1.1 Les listes chaînées

Le noyau Linux dispose d’outils pour manipuler des types de données complexes telles que les listeschaînées. Il s’agit d’une structure pour stocker des données d’une manière dynamique. Chaque élémentde la liste chaînée contient des données et un pointeur vers l’élément suivant.

Dans le cas de Linux, les programmeurs du noyau ont prévu une structure générale pour implémenterdes listes chaînées, utilisable dans le kernel. En effet, les fonctions de la librairie standard C ne sont pasdisponibles dans l’espace noyau. Ceci a pour but d’éviter aux autres développeurs de développer leur pro-pres structures.

La liste chaînée du noyau Linux est une structure qui se nomme list_head. Cette liste est doublementchaînée. Pour chaque élément, il est donc possible de récupérer le suivant et le précédent. Les élémentsde la structure sont deux pointeurs vers des variables list_head.

6.1.2 Déclaration

Pour utiliser une liste chaînée, il faut tout d’abord inclure le fichier <linux/list.h>. Ce fichier définitainsi la structure list_head :

struct list_head {struct list_head *next, *prev;

}

Pour l’initialiser, il suffit de déclarer une liste au début du programme :

#include <linux/list.h>struct list_head ma_liste;

Puis on initialise la liste avec la fonction INIT_LIST_HEAD :

INIT\_LIST\_HEAD(\&ma\_liste);

6.1.3 Utilisation

Pour utiliser les structures list_head, il faut l’inclure dans sa propre structure contenant les élémentsque l’on veut mettre dans la liste chaînée. Par exemple, si on veut faire une liste chaînée des adresse X10reçues (des entiers), il suffiet de la déclarer ainsi :

Uv Libre X10 22

6.1. STRUCTURES DE DONNÉES

struct adresse_struct {struct list_head liste;int adresse_X10;

};

Puis on déclare une variable list_head qui pointe sur le début de la liste. Quand on veut parcourir laliste, on ne manipule en fait que les variables list_head. Pour récupérer la structure complète (adresse_structdans l’exemple), des fonctions sont décrites plus loin.

6.1.4 Fonctions

On trouve dans <linux/list.h> des fonctions pour manipuler des listes.

Pour ajouter un élément, on peut l’ajouter au début de la liste. En fait l’élement immédiatement aprèsl’entête de la liste :

list_add(struct list_head *new, struct list_head *head)

Pour ajouter l’élément en fin :

list_add_tail(struct list_head *new, struct list_head *head)

Tester si la liste est vide :

list_empty(struct list_head *liste)

Cette fonction retourne une valeur différente de 0 si la liste est vide.

Pour supprimer un élément de la liste, on utilise la fonction list_del :

list_del(struct list_head *entry)

Enfin, la plus complexe : obtenir la structure dont fait partie l’élément de la liste chaînée en cours. Ondispose d’un pointeur sur une liste “ptr”.

void * list_entry(struct list_head *ptr, type_de_structure, champs)

6.1.5 Les buffers de socket

Partie vide pour le moment

Uv Libre X10 23

6.2. PÉRIPHÉRIQUES CARACTÈRE

6.2 Périphériques caractère

6.2.1 Introduction

Sous UNIX, les périphériques prennent la forme de simples fichiers qui se trouvent dans le répertoire/dev/. En réalité, ces fichiers ne pointent pas vers des données réelles sur le disque dur de l’ordinateur.Il s’agit d’abstractions crées par le driver d’un pérphérique pour faciliter l’échange de données entre lepilote dans le noyau et le programme dans l’espace utilisateur. En effet, le programme n’a qu’à ouvrir, lireet écrire dans le fichier de périphérique comme il le ferait dans un simple fichier.

Linux ne déroge pas à la règle et propose lui aussi des fichiers pour communiquer avec les pé-riphériques. Ces fichiers sont de deux sortes :

– les périphériques en mode bloc– les périphériques en mode caractère

Dans les périphériques en mode bloc, l’accès au fichier se fait de manière aléatoire, comme dans unvrai fichier. L’utilisateur peut lire et écrire à n’importe quel androit du fichier en précisant l’adresse.

Dans les périphériques en mode caractère, le programme utilisateur lit le bout du fichier comme dansun FIFO. Il ne peut pas parcourir le fichier. C’est ce type de périphérique qui est utilisé dans le programmex10net.

Pour que l’utilisateur puisse se servir du fichier, le module doit d’abord déclarer au noyau son fichier.Puis il donne les opérations qu’il est possible de faire dessus.

6.2.2 Déclaration d’un fichier de périphérique

Le gestion des fichiers est déclarée dans le fichier <linux/fs.h>. Il faut donc commencer par l’incluredans le programme. Le fonction pour enregistrer dans le noyau le périphérique caractère se nomme regis-ter_chrdev(). Sa signature est la suivante :

int register_chrdev(unsigned int major,const char *name,struct file_operations *fops);

La fonction renvoie 0 ou plus si l’opération réussit. major est le numéro qui apparaît quand on tape lacommance “ls -l” dans le réperoire /dev/. Il s’agit d’un nombre entier de 0 à 255. Si on choisit 0, alors lenoyau attribut un nombre dynamiquement et le renvoie. name est le nom du périphérique tel qu’il apparaitdans /proc/devices. Enfin, fops est un pointeur vers un tableau de pointeurs des fonctions qu’il est possiblede faire sur le périphérique (voir plus loin).

Exemple d’invocation :

result = register_chrdev(0, "scull", &scull_fops);if (result < 0) {

printk(KERN_WARNING "scull : ne peut pas obtenir de périphérique\n");} else// récupérer le numéro majeur avec result (si besoin est)

Pour supprimer le fichier caractère, il suffit d’invoquer la fonction unregister_chrdev() de cette manière :

extern int unregister_chrdev(unsigned int major, const char *name);

major est le nombre majeur demandé, et name, le nom du périphérique tel qu’il apparait dans /proc/de-vices.

En mode utilisateur, on crée un fichier de périphérique avec la commande mknod :

mknod /dev/scull c 254 0

Uv Libre X10 24

6.3. PÉRIPHÉRIQUES RÉSEAU

6.2.3 Opérations sur les fichiers de périphérique

Nous avons vu plus haut que les opérations sur les périphériques sont les mêmes que celle des fichiers :lecture, écriture, ouverture, fermeture, etc. Ils correspondent en fait aux appels systèmes d’UNIX : read,write, open, close, etc.

Pour chaque appel système que l’utilisateur est susceptible d’invoquer sur le périphérique, le moduledoit avoir une fonction qui y corresponde. Cette fonction peut avoir un nom similaire. Ex : x10net_readpour read. Par contre, elle doit avoir les mêmes arguments que l’appel système. On peut n’implémenterque les fonctions dont on a besoin.

Les pointeurs de ces fonctions sont réunis dans une structure “file_operations” définie dans <lin-ux/fs.h>, et souvent désigné par fops. C’est cette structure qui est passée en argument à register_chrdev().Il faut déclarer cette structure en variable globale de cette manière :

struct file_operations truc_fops = {read : truc_read,write : truc_write, };

Parmi ces fonctions, on trouve :

ssize_t (*read) (struct file *, char *, size_t, loff_t *);int (*open) (struct inode *, struct file *);

Pour le module, nous choisissons de ne déclarer que l’appel système read.

Pour transférer des données de l’espace utilisateur vers l’espace noyau, et inversement, on utilise desfonctions déclarées dans <asm/uaccess.h>.copy_to_user permet de copier des données vers l’espace d’adressage du processus appelant :

unsigned long copy\_to\_user(void *to, const void *from,unsigned long count)

copy_from_user fait exactement l’inverse :

unsigned long copy\_from\_user(void *to, const void *from,unsigned long count)

6.2.4 Blocage des Entrées/Sorties

On veut éviter que le processus ne fasse une attente active des données quand celle-ci ne sont pasdisponibles. On voudrait qu’il se bloque quand il n’y a pas de données sur le périphérique. Il existe desfonctions pour bloquer un processus et pour le débloquer.

Il faut commencer par déclarer une file d’attente :

wait_queue_head_t file_blocage; /* file d’attente des processus bloqués */

Bloquer le processus courant, mais le laissant semsible aux signaux :

interruptible_sleep_on(&file_blocage);

Débloquer les processus de la file :

wake_up_interruptible(&file_blocage);

6.3 Périphériques réseau

6.3.1 Introduction

Partie vide pour le moment

Uv Libre X10 25

6.4. CONCEPTION DU MODULE

6.4 Conception du module

6.4.1 Introduction

L’objectif de ce module x10net est de créer une interface entre le protocole IP des réseaux Internet etle protocole X10 des modules CM11 reliés à un matériel électrique. Il s’agit de commander l’activationde ces modules par le biais d’un simple ping. Il serait ainsi possible de “pinguer” un périphérique X10,un appareil électrique de la maison relié au réseau électrique de façon transparente, comme si celui-ciavait une adresse IP valide. La réception de ce ping entraînerait alors l’activation du module CM11 pourallumer ou éteindre l’appareil.

Le fonctionnement du module x10net est donc le suivant. Le module ouvre une interface réseau,déclare un fichier de périphérique, et initialise une structure de données telle qu’une liste chaînée. Dèsqu’un paquet IP se conformant à certains critères est reçu par l’interface réseau, un message est stocképar le module dans une liste chaînée. Dès qu’une lecture est faite sur le fichier de périphérique, le moduleretire le message est le transmet à un programme en mode utilisateur. Il est donc nécessaire maîtriser lestechniques mises en oeuvre dans le noyau Linux dans ces trois domaines :

– les interfaces Réseau– les structures de données, et notamment les listes chaînées– les fichiers de périphérique

6.4.2 Fonctionnement général

Pour décrire le fonctionnement général du projet, on peut le décomposer en deux programmes. Unprogramme, le module, se trouve en mode noyau, le seul moyen d’accéder directement aux paquets IP quitransitent par le réseau. Le second est un démon qui tourne en fond de tâche.

Le module, x10net, se voie associer une adresse IP par la méthode traditionnel sous linux, c’est-à-direavec la commande ifconfig :

# ifconfig x10net0 inet 192.168.1.1 netmask 255.255.255.0 up

Ce programme reçoit les paquets ping à destination des adresses IP virtuelles reservées au périphériquesX10. Le programme en mode utilisateur, x10netd, exécute une commande heyu dès qu’il en reçoit l’ordrepar le module x10net.

Pour leur permettre de communiquer, la méthode utilsée est un fichier de périphérique en mode carac-tère. Ce fichier se nomme “/dev/x10net”. Le module x10net peut ainsi communiquer au processus x10netdles adresses x10 des appareils électriques qui ont été pingués par un utilisateur.

Le schéma suivant décrit le fonctionnement du programme.

FIG. 6.1 –Fonctionnement général du projet

Pour résumer, le module s’exécute quand une des deux actions suivantes se produit : réception d’unping par l’interface réseau et lecture du fichier de périphérique par le démon x10netd.

Quand un ping arrive sur la périphérique réseau net_device déclaré par le module, le programme extraitle type du paquet et l’adresse de destination. S’il s’agit d’un ping, il extrait de l’adresse IP de destinationl’adresse X10 et le stocke dans la liste chaînée.

Uv Libre X10 26


Quand le processus x10netd lit un octet dans le fichier de périphérique “/dev/x10net”, le modulex10net extrait de la liste la première adresse X10 entrée, et lui communique. x10netd exécute alors le pro-cessus heyu avec les bons arguments pour invoquer la commande demandée. Heyu envoie une instructionx10 sur le réseau électrique et la lampe s’allume.

6.4.3 Description détaillée du programme

Initialisation du module

Au démarrage du module, il faut déclarer l’interface réseau et lui donner un nom :

dev_alloc_name(&dev_x10net,"x10net%d");register_netdev(&dev_x10net);

Il faut aussi déclarer le fichier de périphérique :

register_chrdev(0, "x10net", &x10net_fops);

Enfin, on initialise la file d’attente des processus bloqués ...

init_waitqueue_head(&file_blocage);

...et la liste chaînée des adresses X10 reçues par ping :

INIT_LIST_HEAD(&adresse_liste);

Réception d’un ping

Quand un ping est reçu par l’interface réseau, c’est la fonction x10net_xmit() qui est appelée. Lafonctin éclate la structure sk_buff donnée en argument pour trouver des informations nécessaires : l’adresseIP de destination et le type de paquet (ping).

/* On récupère l’adresse de destination */send_addr = skb->nh.iph->saddr;

/* Le type de protocole */skb->nh.iph->protocol;

On peut alors récupérer l’adresse X10 et l’état demandé : 0 pour éteindre, et 1 pour allumer. L’adresseX10 est dans le 3e nombre de l’adresse IP de destination (192.168.X.1) et l’état dans le 4e (192.168.179.X).On utilise un masque sur les bits demandés.

/* Et l’adresse x10 */recv_x10_addr = (recv_addr&0x00FF0000)>>16;recv_x10_state = (recv_addr&0xFF000000)>>24;

Après avoir alloué la mémoire, ces deux données sont stockées à la fin de la liste chaînée :

/* Stocker l’adresse dans la liste chaînée */adresse_ptr = (struct adresse_struct *)kmalloc(sizeof(struct adresse_struct), GFP_KERNEL);(*adresse_ptr).adresse_X10 = recv_x10_addr;list_add_tail(&((*adresse_ptr).liste), &adresse_liste);

Lecture du fichier de périphérique

La fonction x10net_read() est appelé quand un processus tente de lire le fichier de périphérique “/de-v/x10net”. Cette fonction commence par bloquer le processus pour le placer dans une attente passive si laliste est vide.

Uv Libre X10 27


/* Si la liste est vide, bloquer le processus */if (list_empty(&adresse_liste) != 0) {

interruptible_sleep_on(&file_blocage);}

Dans le cas contraire, elle retire une adresse de la liste chaînée et la copie dans l’espace d’adressage duprocessus grâce à la fonction copy_to_user().

/* Récupérer une adresse de la liste */adresse_liste_ptr = adresse_liste.next;adresse_struct_ptr = list_entry(adresse_liste_ptr,

struct adresse_struct, liste);

/* Supprimer l’adresse de la liste */list_del(adresse_liste_ptr);

/* Renvoyer l’élément au programme appelant */copy_to_user(buf, &(*adresse_struct_ptr).adresse_X10, 1);

Le démon x10netd

Le programme x10netd est composé d’une boucle infinie qui lit ouvre le fichier de périphérique “/de-v/x10net” et lit des adresses X10 transmises par le module.

Le démon commence son exécution par ouvrir le fichier de périphérique :

/* Ouvrir le fichier */result = open("/dev/x10net", O_RDONLY);if (result == -1) {

return result;} else {

fd = result;}

Puis il lit une adresse et un état dans le fichier :

result = read(fd, buf_addr, 1);result = read(fd, buf_state, 1);

Si il a bien reçu les deux entiers, il fork et exécute le programme heyu avec comme arguments l’adresseX10 et l’état. Dans une première version, le processus fils résultant du fork exécutait trop lentement heyu.Des données étaient perdues quand on envoyait des pings dans l’intervalle. Nous avons donc ajouté uneinstruction wait() dans le corps du père pour qu’il attende que le fils ait terminé avant d’exécuter heyu ànouveau.

/* Exécuter heyu avec la bonne adresse et le bon état ! */pid = fork();if (pid == 0) {

/* On est dans le fils : exécuter heyu */printf("Adresse : %s - state : %s\n", chaine_addr, chaine_state);execlp("heyu", "heyu", "turn", chaine_addr, chaine_state, NULL);

} else {/* On est dans le père : attendre que le fils ait terminé */waitpid(pid, NULL, 0);

}

Le x10netd attend correctement que son processus fils ait terminé d’exécuter heyu. Heyu se charge d’en-voyer sur le port série les instructions X10 pour arriver au résultat escompté : la lampe s’allume.

Uv Libre X10 28

CHAPITRE 7. MISE EN ŒUVRE

Chapitre 7

Mise en œuvre

7.1 Le principe

Le principe du Projet était de pouvoir piloter un appareil X10 sur un réseau électrique par de simplespings. Il fallait pour cela intégrer un module de conversion et de dérivation des pings vers le réseau X10pour les traiter (traduire l’adresse IP en adresse X10, récupérer l’état demandé : on ou off, avant d’envoyerle bon message sur le réseau X10 à destination du bon appareil X10).Pour cela nous avons implémenté un module réseau (x10net) qui déroute les paquets de ping à destinationdu réseau X10 et les traite de la façon suivante :

• Les deux premiers nombres de l’IP définissent le réseau X10, réseau assigné à l’interface x10net0(interface virtuelle)

• Le troisième représente l’adresse X10 de l’appareil de destination, sous forme décimale. Il faut doncla convertir en hexadécimal pour heyu ( 161[d]=a1[h] )

• Enfin le dernier représente l’état demandé (0=off, 1=on). (Si le nombre est différent de 0, il seraconsidéré comme égale à 1)

Par exemple pour allumer la lampe ayant pour adresse X10 A1 (161 en décimal), sur le réseau192.168.0.0, il suffit de pinger avec 192.168.161.1. Lorsque le module a identifié un ordre destiné auréseau X10, il écrit dans le fichier périphérique/dev/x10net(voir partie sur fichier périphérique) l’adressex10 du module cible ainsi que l’état demandé. L’écriture dans le fichier périphérique déclenche le réveildu daemon X10netd qui va lire ces paramètres dans le fichier, avant de lancer une commande heyu avecles bons paramètres sur le réseau X10, via le CM11.

7.2 Expérience

Pour l’expérience nous allons utiliser deux ordinateurs :

X Le premier servira de client pour effectuer les pings de control.X Le deuxième servira à la fois de passerelle entre le réseau ethernet (dont fait partie le client) et le

réseau X10 (dont fait partie la lampe), et de traducteur de ping en commande X10.

7.2.1 Le client

Il lui suffit de le configurer sur le même réseau Ethernet que le routeur, par exemple voici la configu-ration du réseau dans le /etc/network/interfaces, pour l’interface eth0 :

auto eth0iface eth0 inet static

address 192.100.1.2

Uv Libre X10 29

7.2. EXPÉRIENCE

netmask 255.255.0.0broadcast 192.100.255.255network 192.100.0.0

Ensuite il faut rajouter la passerelle dans les tables de routage :

route add default gw 192.100.1.1

où 192.100.1.1 est l’adresse du routeur

7.2.2 Le routeur

configuration du réseau

Pour le réseau ethernet, on procède de la même façon que pour le client :

auto eth0iface eth0 inet static

address 192.100.1.1netmask 255.255.0.0broadcast 192.100.255.255network 192.100.0.0

Pour le réseau X10 : on insère le module implémenté (voir annexes)

insmod ./x10net.o

et on configure l’interface virtuelle x10net0 :

ifconfig x10net0 inet 192.168.1.1 netmask 255.255.255.0 up

Puis pour activer la fonction de passerelle entre les deux réseaux il faut entrer la commande suivante :

echo 1 > /proc/sys/net/ipv4/ip_forward

La conversion IP / X10

On commence par créer le fichier périphérique :

mknod /dev/x10net c 254 0

Ensuite il ne reste plus qu’à lancer le daemon :

./X10netd

L’installation est terminée et on peut effectuer les tests, la configuration est la suivante :

Uv Libre X10 30

7.2. EXPÉRIENCE

FIG. 7.1 – Architecture du réseau

Uv Libre X10 31

CHAPITRE 8. L’ÉTUDE DE HEYU

Chapitre 8

L’étude de Heyu

8.1 Le matériel X10

Comme avec le projet X10 v1.0, nous avions à disposition deux modules CM11 (interface série avecl’ordinateur) et un module LM12 (module lampe). Le CM11 sert d’interface du réseau X10 avec un or-dinateur relié par port série. Le premier problème que nous avons rencontré a été le fonctionnement desappareils X10 lors des premiers tests. En effet, nous ne savions pas si l’échec du fonctionnement venaitdu matériel ou bien du programme Heyu mal configuré. . .Finalement nous nous sommes rendus compteque les piles du module CM11 étaient usées avant de les remplacer. Il peut paraître tout à fait paradoxal dedevoir mettre des piles dans un module destiné à être branché sur le secteur mais sans celles-ci le matérielne répond pas du tout. Cérifiez donc bien l’état des piles dans chaque module avant de vous en servir, cesderniers semblant consommer une quantité non-négliegable d’électricité même sans qu’on les emploie.

Nous avions également pensé que le problème venait peut-être aussi des branchements des modulessur des prises différentes, avec ou sans rallonges, à plus ou moins longue distance. Finalement nousnous sommes rendus compte que, s’il est vrai que deux prises cotes à cotes peuvent être sur des réseauxdifférents (trop lointains pour faire passer des ordres X10), le plus simple reste encore de faire les testsavec tous les modules emboîtés les uns dans les autres sur une même prise : cela marche très bien.

8.2 Le programme Heyu

Heyu est un programme asiatique destiné à piloter les modules X10, en particulier le CM11. Il estdisponible sous plusieurs packages de distributions, dont Debian, ce qui facilite grandement son installa-tion qui se réduit alors à réaliser la commande :

apt-get install heyu

Ensuite vient la configuration de l’application : Il faut tout d’abord intégrer une variable d’environ-nement à chaque session d’utilisateur, concernant le fichier de configuration à utiliser par heyu. pour cela,ajouter dans le.bashrcde l’utilisateur la variable suivante.

export X10CONFIG=/etc/x10.config

Puis, il ne reste plus qu’à éditer le fichier/etc/x10.config. Par défaut, la configuration du port à utiliserpour piloter le module CM11 est/dev/x10, qui n’existe pas. Nous allons utiliser le port série puisque notreCM11 fonctionne ainsi. A partir de là deux solutions sont possibles :

• Créer un device symbolique redirigé vers le bon port serie (ttyS0)

ln -s /dev/ttyS0 /dev/x10

ou bien alors (et c’est le plus simple).

Uv Libre X10 32

8.3. L’ARCHITECTURE DE HEYU

• Changer le device directement dans le fichier de configuration en remplaçant

# Set the port the program will use.TTY /dev/x10

par

# Set the port the program will use.TTY /dev/ttyS0

ttyS0 représentant le premier port série, bien brancher le CM11 sur ce port (COM1). . .Il ne reste plus qu’à utiliser Heyu avec des commandes simples :

heyu turn a1 on

allume la lampe d’adresse a1.

heyu -vvv turn a1 off

éteint cette lampe en mode verbose (sortie standard des étapes de l’envoi du message). On peut égalementmonitorer le trafic X10 sur une ligne électrique en sniffant à l’aide de la commande :

heyu monitor

Cependant, attention, le résultat n’est pas le même selon qu’on le lance sur la machine qui lance les ordresX10 ou qui écoute simplement.

On peut aussi demander l’état d’un module LM12 en utilisant :

heyu info

8.3 L’architecture de Heyu

Le but original était d’intégrer au noyau un module pour créer le dialogue avec le CM11. Or, leprogramme Heyu n’étant pas modulaire, il fallait se pencher sur la source du programme pour essayerd’intégrer la communication X10 dans le module. Le problème a été de s’immerger dans un code deHeyu relativment imbittable, sans aucun commentaire et donc particulièrement difficile à comprendre.Cependant,La sortie du programme Heyu2, apparemment (re)codé avec plus de soin nous a permis decibler nos recherches sur les quelques fichiers dialoguant avec le CM11 à travers le port série. Nous avonstrouvé où le programme écrit sur le bon port mais le traitement des chaînes écrites sur le port série est restéobscur et malgré des tests et modifications dans le code source, nous n’avons pu recréer le bon message àenvoyer au CM11.

8.4 Heyu 2

Pendant notre développement de projet, nous avons vu l’apparition du programme Heyu2, apparem-ment successeur de Heyu mais développée par une équipe différente. Le programme n’existe pas encoreen version stable et est donc disponible uniquement en sources. Cependant son installation reste classique :

./configuremake

make install

De plus, les mêmes configurations que pour Heyu sont réutilisées (voir paragraphe précédent). Cecidit les sources sont plus commentées et se plonger dans le code source est moins un problèmea : on peutmodifier facilement les codes voulus, puis recompiler le tout avec unmake(ou à la main, les fichierschoisis avec gcc). Le make produit un exécutableHeyu2que lemake install se chargera de placerdans le repertoire/usr/bin. On peut donc directement le tester dans le répertoire sans une installationcomplète.

Uv Libre X10 33

CHAPITRE 9. LES PROJETS X10

Chapitre 9

Les projets X10

Il existe un certain nombre de projets sur le X10 , nous recenserons ici les plus importants issus duprojet Sourceforge1

9.1 MisterHouse (v2.86)

MisterHouse est un programme de domotique Windows/Unix écrit en Perl. Il peut répondre à desordres vocaux, par navigateurs web, selon un agenda, par ordres X10 et autres. . .

9.2 Java Home Automation (v1.1.0)

C’est un logiciel de domotique qui permet de contrôler divers modules X10 grâce au CM11 ou CM17apar le port série. C’est une application 100% Java avec beaucoup d’options, comme le monitoring desévènements, la voix ou encore une interface web.

9.3 Linux X10 universal device driver (v1.6.9)

les pilotes de modules X10 pour Linux créent un device/devpour chaque unité X10 de la maison.Ils permettent un contrôle par ligne de commande, scripts et accès par programme au réseau X10. Ilfonctionne avec PowerLinc Serial, PowerLinc USB, CM11A, et Firecracker/CM17A.

9.4 Ppower (v0.1.5)

Ppower, sigle de ’Penguin Power’, est un logiciel de contrôle de domotique pour réseaux X10 con-nectés à un ordinateur par un module CM11a. Il peut être utilisé pour allumer ou éteindre des lampes. Enplus de contrôler des appareils X10, il peut aussi recevoir les commandes envoyées par d’autres sourcescomme une télécommande X10 et exécuter des commandes sur le système en réponse.

9.5 X10Controller(v1.3)

X10Controller est la réunion de deux petits programmes :

• X10Server : Il permet de contrôler des appareils X10 par un réseau grâce aux module CM11a etCM17a. C’est une application Java spécialement conçue pour les ordinateurs Dallas Semiconduc-tor, Corp. TINI mais devrait marcher sur toutes les plates-formes supportant le javaCommAPI (pour

1http ://www.sourceforge.net

Uv Libre X10 34

9.6. STANTOR (V05)

l’accès aux ports série). Il a été testé sur TINI, Linux et Windows.

• X10Client : C’est une petite application Java utilisant une interface utilisateur AWT qui commu-nique avec le X10Server sur un réseau pour contrôler des appareils X10. Conçus pour tourner surle PDA Sharp Zaurus, il fonctionne aussi sur toutes les plates-formes supportant le Java.

9.6 Stantor (v05)

STANTOR v05 est un ensemble de progiciels et de logiciels permettant de :

X Consulter des informations numériques, digitales et videos,X Envoyer des commandes numériques et digitales.

Stantor :

X Scrute de façon cyclique des capteurs (sonde de température, contact Tout ou Rien...).X Transmet des ordres à des actionneurs (relais,. . .).X Reçoit périodiquement des images émanant de WebCam.

Dans le cadre de cette version STANTOR pilote :

X Une carte électronique K8000 via un Bus série I2C au travers du port parallèle (port Imprimante).X Un module X10 (courant porteur sur le 220V) de type CM11A via une liaison série au travers d’un

port série du micro-ordinateur.X Une webcam type Logitech via le bus USB.

STANTOR est utilisable avec un navigateur (Netscape, IE, ...), avec un téléphone I-mode ou un mininavigateur répondant à la norme WAP 1.x.

9.7 SweetHome (v1.0)

Solution domotique développée en Java, qui permet d’obtenir et d’agir sur les informations de lamaison. L’utilisation d’un serveur de Servlets permet l’utilisation d’un client léger (Navigateur HTML,WAP, PDA, etc. . .). Le matériel est configuré au préalable depuis un PC (ou MAC). Le matériel contienttoutes les informations dont il a besoin pour dérouler l’enchaînement logique définit par l’utilisateur.Ainsi, si l’on appuie sur un bouton, une ou plusieurs commandes sont émises sur le réseau de domotique.

Uv Libre X10 35

Troisième partie

Annexes X10 v1

Uv Libre X10 36

ANNEXE A. VALEUR DES DIFFÉRENTS CODES

Annexe A

Valeur des différents codes

A.1 Code Maison

H8 H4 H2 H1A 0 1 1 0B 1 1 1 0C 0 0 1 0D 1 0 1 0E 0 0 0 1F 1 0 0 1G 0 1 0 1H 1 1 0 1I 0 1 1 1J 1 1 1 1K 0 0 1 1L 1 0 1 1M 0 0 0 0N 1 0 0 0O 0 1 0 0P 1 1 0 0

A.2 Code Unité

D8 D4 D2 D1 F101 0 1 1 0 002 1 1 1 0 003 0 0 1 0 004 1 0 1 0 005 0 0 0 1 006 1 0 0 1 007 0 1 0 1 008 1 1 0 1 009 0 1 1 1 010 1 1 1 1 011 0 0 1 1 012 1 0 1 1 013 0 0 0 0 0

. . .

Uv Libre X10 37

A.3. CODE FONCTION

D8 D4 D2 D1 F114 1 0 0 0 015 0 1 0 0 016 1 1 0 0 0

A.3 Code Fonction

D8 D4 D2 D1 F1Tous modules Off 0 0 0 0 1Tous modules On 0 0 0 1 1On 0 0 1 0 1Off 0 0 1 1 1Dim 0 1 0 0 1Brighten 0 1 0 1 1All Lights Off 0 1 1 0 1Extended Code 0 1 1 1 1Hail Request 1 0 0 0 1Hail Acknowledge 1 0 0 1 1Pre-Set Dim 1 0 1 X 1Extended Data 1 1 0 0 1Status is On 1 1 0 1 1Status is Off 1 1 1 0 1Status request 1 1 1 1 1

Uv Libre X10 38

ANNEXE B. ETUDE DU FONCTIONNEMENT D’UNE TÉLÉCOMMANDE X10

Annexe B

Etude du fonctionnement d’unetélécommande X10

Il existe deux sortes de télécommande permettant d’avoir des ordres X10 sur la ligne électrique. Lesparties suivantes vont présenter ces différentes sortes.

B.1 Télécommande IR ou RF avec convertisseur X10

C’est une télécommande qui permet d’envoyer des ondes RF ou IR. Ces ondes sont captées par unconvertisseur X10 qui envoie l’ordre correspondant au signal reçu sur la ligne électrique.

Dans ce cas, le module CM11 n’intervient pas.

B.2 Télécommande PC

Il s’agit d’une télécommande avec son récepteur relié au PC. Lorsque la télécommande envoie unmessage, le récepteur le reçoit et un programme lancé en tache de fond le reconnaît et envoie au moduleCM11 l’ordre correspondant au message reçu. Un script configurable permet d’associer un signal avecune action a réaliser avec le CM11.

B.3 Module AM12

Un module AM12 est un module appareil. Il peut être branché sur un ordinateur mais cela n’est pasnécessaire sur notre application car le module CM11 " voit " tout ce qui se passe sur la ligne électrique.Nous n’avons donc pas besoin de fixer d’adresse au CM11 dans le cas d’une communication entre deuxordinateurs. Par contre, si on dispose de plusieurs couples : modules CM11 + PC, et que l’on envoi unordre X10,tous les CM11 branchés sur la ligne électrique vont capter ce message, même si il ne leur estpas destiné.

Uv Libre X10 39

Quatrième partie

Annexes X10 v2

Uv Libre X10 40

ANNEXE C. ANNEXE DE TEST

Annexe C

Annexe de test

Uv Libre X10 41

ANNEXE D. CODE SOURCE

Annexe D

Code source

D.1 Listing skeleton.c

Ajouter le listing complet du code

D.2 Listing x10net.c

1 / *2 * Programme : x10ne t3 *4 * But : un module réseau sous l i n u x a l l umer des p é r i p h é r i q u e s x105 * en l e s p i n g a n t− avec g e s t i o n d ’ un p é r i p h é r i q u e c a r a c t è r e6 * des l i s t e s c h a î n é e s7 *8 * Langage : Langage C9 * F i c h i e r : x10ne t . c

10 *11 * Au teu rs : Gui l laume TANGUY ( ASI4 )12 * Damien BARON ( ASI5 )13 * P ie r re−Yves AIMON ( ASI4 )14 * Date : Thu Jan 1 1 9 : 5 5 : 0 2 2 0 0 415 * /1617 # inc lude < l i n u x / c o n f i g . h>18 # inc lude < l i n u x / module . h>19 # inc lude < l i n u x / k e r n e l . h>20 # inc lude < l i n u x / n e t d e v i c e . h>21 # inc lude < l i n u x / i n i t . h>2223 / * Pour g é r e r l e s f i c h i e r s de p é r i p h é r i q u e en mode car* /24 # inc lude < l i n u x / f s . h>25 # inc lude < asm / u a c c e s s . h>2627 / * Pour pouvo i r é c l a t e r l a s t r u c t u r e i p h d r :* /28 # inc lude < l i n u x / i p . h>2930 / * Types de données* /31 s t r u c t a d r e s s e _ s t r u c t {32 s t r u c t l i s t _ h e a d l i s t e ;

Uv Libre X10 42

D.2. LISTING X10NET.C

33 i n t adresse_X10 ;34 } ;3536 / * V a r i a b l e s * /37 i n t x10ne t_ma jo r ;38 wa i t_queue_head_ t f i l e _ b l o c a g e ;/ * f i l e d ’ a t t e n t e des p r o c e s s u s

b loqués * /39 s t r u c t l i s t _ h e a d a d r e s s e _ l i s t e ; / * l i s t e cha înée des a d r e s s e s X10

r e ç u e s * /4041 / * D é c l a r a t i o n s de f o n c t i o n s* /42 s t a t i c i n t x10ne t_xmi t (s t r u c t s k _ b u f f * skb , s t r u c t n e t _ d e v i c e * dev ) ;43 s t a t i c s t r u c t n e t _ d e v i c e _ s t a t s* x 1 0 n e t _ g e t _ s t a t s (s t r u c t n e t _ d e v i c e *

dev ) ;444546 / * f a k e m u l t i c a s t a b i l i t y * /47 s t a t i c vo id s e t _ m u l t i c a s t _ l i s t (s t r u c t n e t _ d e v i c e * dev )48 {49 }5051 # i f d e f CONFIG_NET_FASTROUTE52 s t a t i c i n t x 1 0 n e t _ a c c e p t _ f a s t p a t h (s t r u c t n e t _ d e v i c e * dev , s t r u c t

d s t _ e n t r y * d s t )53 {54 re turn −1;55 }56 # e n d i f5758 s t a t i c i n t _ _ i n i t x 1 0 n e t _ i n i t (s t r u c t n e t _ d e v i c e * dev )59 {60 / * I n i t i a l i z e t h e d e v i c e s t r u c t u r e .* /6162 dev−>p r i v = kmal loc (s i z e o f( s t r u c t n e t _ d e v i c e _ s t a t s ) ,

GFP_KERNEL) ;63 i f ( dev−>p r i v = = NULL)64 re turn −ENOMEM;65 memset ( dev−>pr i v , 0 , s i z e o f( s t r u c t n e t _ d e v i c e _ s t a t s ) ) ;6667 dev−> g e t _ s t a t s = x 1 0 n e t _ g e t _ s t a t s ;68 dev−>h a r d _ s t a r t _ x m i t = x10ne t_xmi t ;69 dev−> s e t _ m u l t i c a s t _ l i s t = s e t _ m u l t i c a s t _ l i s t ;70 # i f d e f CONFIG_NET_FASTROUTE71 dev−>a c c e p t _ f a s t p a t h = x 1 0 n e t _ a c c e p t _ f a s t p a t h ;72 # e n d i f7374 / * F i l l i n d e v i c e s t r u c t u r e w i th e t h e r n e t−g e n e r i c v a l u e s . * /75 e t h e r _ s e t u p ( dev ) ;76 dev−>t x _ q u e u e _ l e n = 0 ;77 dev−> f l a g s | = IFF_NOARP ;78 dev−> f l a g s &= ~IFF_MULTICAST ;7980 p r i n t k ( " <1> I n i t i a l i s a t i o n de l ’ i n t e r f a c e du module x10ne t \ n " )

;

Uv Libre X10 43


8182 re turn 0 ;83 }8485 s t a t i c i n t x10ne t_xmi t (s t r u c t s k _ b u f f * skb , s t r u c t n e t _ d e v i c e * dev )86 {87 s t r u c t n e t _ d e v i c e _ s t a t s* s t a t s = dev−>p r i v ;88 __u32 send_addr ; / * Ad resse e m e t t e u r* /89 __u32 r e c v _ a d d r ; / * Ad resse d e s t i n a t a i r e* /90 __u8 recv_x10_addr ;/ * Adresse x10 du d e s t i n a t a i r e* /91 __u8 r e c v _ x 1 0 _ s t a t e ;/ * E t a t ( x10 ) du d e s t i n a t a i r e * /92 s t r u c t a d r e s s e _ s t r u c t* a d r e s s e _ p t r ;9394 s t a t s−>t x _ p a c k e t s ++;95 s t a t s−>t x _ b y t e s +=skb−>l e n ;9697 / * On ré cup è r e l ’ a d r e s s e de d e s t i n a t i o n* /98 send_addr = skb−>nh . iph−>s ad d r ;99 r e c v _ a d d r = skb−>nh . iph−>daddr ;

100101 / * Et l ’ a d r e s s e x10 * /102 recv_x10_addr = ( r e c v _ a d d r&0x00FF0000 ) > >16;103 r e c v _ x 1 0 _ s t a t e = ( r e c v _ a d d r&0xFF000000 ) > >24;104105 / * S t o c k e r l ’ a d r e s s e dans l a l i s t e cha înée* /106 a d r e s s e _ p t r = (s t r u c t a d r e s s e _ s t r u c t* ) kmal loc (s i z e o f( s t r u c t

a d r e s s e _ s t r u c t ) , GFP_KERNEL) ;107 (* a d r e s s e _ p t r ) . adresse_X10 = recv_x10_addr ;108 l i s t _ a d d _ t a i l (&( (* a d r e s s e _ p t r ) . l i s t e ) , & a d r e s s e _ l i s t e ) ;109110 / * S t o c k e r On ou Of f dans l a l i s t e cha înée* /111 a d r e s s e _ p t r = (s t r u c t a d r e s s e _ s t r u c t* ) kmal loc (s i z e o f( s t r u c t

a d r e s s e _ s t r u c t ) , GFP_KERNEL) ;112 (* a d r e s s e _ p t r ) . adresse_X10 = r e c v _ x 1 0 _ s t a t e ;113 l i s t _ a d d _ t a i l (&( (* a d r e s s e _ p t r ) . l i s t e ) , & a d r e s s e _ l i s t e ) ;114115 / * Débloquer l e s p r o c e s s u s au cas ou i l s s o n t b loqués* /116 w a k e _ u p _ i n t e r r u p t i b l e (& f i l e _ b l o c a g e ) ;117118 / * Message du noyau* /119 p r i n t k ( " <1> T r a n s m i s s i o nd ’ un paque t pa r l ’ i n t e r f a c e du module

x10ne t : \ n \120 Type : %x \ n \121 Adresse d ’ envo i : %d.%d.%d.%d \ n \122 Adresse de d e s t i n a t a i r e : %d.%d.%d.%d \ n " ,123 skb−>nh . iph−>p r o t o c o l ,124 ( send_addr&0x000000FF ) ,125 ( send_addr&0x0000FF00 ) >>8 ,126 ( send_addr&0x00FF0000 ) >>16 ,127 ( send_addr&0xFF000000 ) >>24 ,128 ( r e c v _ a d d r&0x000000FF ) ,129 ( r e c v _ a d d r&0x0000FF00 ) >>8 ,130 ( r e c v _ a d d r&0x00FF0000 ) >>16 ,131 ( r e c v _ a d d r&0xFF000000 ) >>24) ;

Uv Libre X10 44


132133 dev_k f ree_skb ( skb ) ;134 re turn 0 ;135 }136137 s t a t i c s t r u c t n e t _ d e v i c e _ s t a t s* x 1 0 n e t _ g e t _ s t a t s (s t r u c t n e t _ d e v i c e *

dev )138 {139 re turn dev−>p r i v ;140 }141142 s t a t i c s t r u c t n e t _ d e v i c e dev_x10net ;143144145 / * Ges t i on des f i c h i e r s de p é r i p h é r i q u e c a r a c t è r e s* /146147 / * F o n c t i o n s des p é r i p h é r i q u e s* /148 s s i z e _ t x10ne t_ rea d (s t r u c t f i l e * f i l p , char * buf , s i z e _ t count ,

l o f f _ t * f_pos )149 {150 s t r u c t l i s t _ h e a d * a d r e s s e _ l i s t e _ p t r ;151 s t r u c t a d r e s s e _ s t r u c t* a d r e s s e _ s t r u c t _ p t r ;152153 / * DEBUG : a f f i c h e r une message quand l ’ appe l sys tème read

e s t f a i t * /154 p r i n t k ( " <1>Appel sys tème read a p p e l é \ n " ) ;155156 / * S i l a l i s t e e s t v ide , b l oque r l e p r o c e s s u s* /157 i f ( l i s t _ e m p t y (& a d r e s s e _ l i s t e ) ! = 0 ) {158 i n t e r r u p t i b l e _ s l e e p _ o n (& f i l e _ b l o c a g e ) ;159 }160161 / * Sinon , l e déb loque r ( au cas ou ) , e t l u i r e nvo ye r l e s

a d r e s s e s une162 * par une e t l e s suppr imer de l a l i s t e* /163 / * A t t e n t i o n : i l s ’ a g i t d ’ une f o n c t i o n r é e n t r a n t e* /164 i f ( l i s t _ e m p t y (& a d r e s s e _ l i s t e ) = = 0 ) {165 / * Débloquer l e s p r o c e s s u s au cas ou* /166 w a k e _ u p _ i n t e r r u p t i b l e (& f i l e _ b l o c a g e ) ;167168 / * Récupérer une a d r e s s e de l a l i s t e* /169 a d r e s s e _ l i s t e _ p t r = a d r e s s e _ l i s t e . nex t ;170 a d r e s s e _ s t r u c t _ p t r = l i s t _ e n t r y ( a d r e s s e _ l i s t e _ p t r ,171 s t r u c t a d r e s s e _ s t r u c t

, l i s t e ) ;172173 / * DEBUG : a f f i c h e r l ’ a d r e s s e l u e * /174 p r i n t k ( " <1> AdresseX10 l u e : %d \ n " , (*

a d r e s s e _ s t r u c t _ p t r ) . adresse_X10 ) ;175176 / * Suppr imer l ’ a d r e s s e de l a l i s t e* /177 l i s t _ d e l ( a d r e s s e _ l i s t e _ p t r ) ;178179 / * Renvoyer l ’ é l émen t au programme a p p e l a n t* /

Uv Libre X10 45


180 c o p y _ t o _ u s e r ( buf , & (* a d r e s s e _ s t r u c t _ p t r ) . adresse_X10, 1 ) ;

181182 / * Déa l l oue r l a mémoire de l a s t r u c t u r e de données* /183 k f r e e ( a d r e s s e _ s t r u c t _ p t r ) ;184185 re turn 1 ;186 } e l s e {187 re turn 0 ;188 }189190191 / * uns igned long r e s u l t ;* /192193194195 / * r e s u l t = c o p y _ t o _ u s e r ( buf , cha ine , 6 ) ;196 p r i n t k ("<1> L e c t u r e su r l e p é r i p h é r i q u e x10ne t− coun t : % d −

r e s u l t : % l d \ n " , count , r e s u l t ) ;197198 b loque r l e p r o c e s s u s199 i n t e r r u p t i b l e _ s l e e p _ o n (& f i l e _ b l o c a g e ) ;200201 r e t u r n 0 ; * /202 }203204205 / * V a r i a b l e s g l o b a l e s * /206 s t r u c t f i l e _ o p e r a t i o n s x10ne t_ fops = {207 read : x10ne t_ read , } ;208209210211 s t a t i c i n t _ _ i n i t x 1 0 n e t _ i n i t _ m o d u l e (vo id )212 {213 i n t e r r ;214 i n t r e s u l t ;215216 dev_x10net . i n i t = x 1 0 n e t _ i n i t ;217 SET_MODULE_OWNER(& dev_x10net ) ;218219 / * Find a name f o r t h i s u n i t * /220 e r r = dev_a l loc_name (& dev_x10net , " x10ne t%d " ) ;221 i f ( e r r <0)222 re turn e r r ;223 e r r = r e g i s t e r _ n e t d e v (& dev_x10net ) ;224 i f ( e r r <0)225 re turn e r r ;226227 / * Déc la re r l e f i c h i e r de p é r i p h é r i q u e* /228 r e s u l t = r e g i s t e r _ c h r d e v ( 0 , " x10ne t " , & x10ne t_ fops ) ;229 i f ( r e s u l t < 0 ) {230 p r i n t k (KERN_WARNING " x10ne t : ne peu t pas o b t e n i r de

p é r i p h é r i q u e \ n " ) ;

Uv Libre X10 46

D.3. LISTING LIRE_X10NET.C

231 re turn r e s u l t ;232 } e l s e {233 x10ne t_ma jo r = r e s u l t ;234 }235236 / * I n i t i a l i s e r l a f i l e d ’ a t t e n t e des p r o c e s s u s b loqués* /237 i n i t _ w a i t q u e u e _ h e a d (& f i l e _ b l o c a g e ) ;238239 / * I n i t i a l i s e r l a l i s t e des a d r e s s e s X10 r e ç u e s par p ing* /240 INIT_LIST_HEAD(& a d r e s s e _ l i s t e ) ;241242 / * Un message du noyau* /243 p r i n t k ( " <1> I n i t i a l i s a t i o n du module x10ne t − numéro majeur

: %d \ n " , x10ne t_ma jo r ) ;244 re turn 0 ;245 }246247 s t a t i c vo id _ _ e x i t x10ne t_c leanup_modu le (vo id )248 {249 i n t r e s u l t ;250251 u n r e g i s t e r _ n e t d e v (& dev_x10net ) ;252 k f r e e ( dev_x10net . p r i v ) ;253254 memset(& dev_x10net , 0 ,s i z e o f( dev_x10net ) ) ;255 dev_x10net . i n i t = x 1 0 n e t _ i n i t ;256257 / * Suppr imer l e f i c h i e r de p é r i p h é r i q u e* /258 r e s u l t = u n r e g i s t e r _ c h r d e v ( x10net_major , " x10ne t " ) ;259 i f ( r e s u l t < 0 ) {260 p r i n t k (KERN_WARNING " x10ne t : ne peu t pas d é c h a r g e r

l e p é r i p h é r i q u e \ n " ) ;261 }262263 / * L i b é r e r l e s p r o c e s s u s b loqués* /264 / * Pas une bonne i d é e : ca f a i t f a i t p l a n t e r l e s p r o c e s s u s

b loqués265 w a k e _ u p _ i n t e r r u p t i b l e (& f i l e _ b l o c a g e ) ;* /266267 p r i n t k ( " <1>Déchargementdu module x10ne t \ n " ) ;268 }269270 m o d u l e _ i n i t ( x 1 0 n e t _ i n i t _ m o d u l e ) ;271 modu le_ex i t ( x10ne t_c leanup_modu le ) ;272 MODULE_LICENSE( "GPL" ) ;

D.3 Listing lire_x10net.c

1 / *2 * Programme : l i r e _ x 1 0 n e t3 *4 * But : l i r e su r l e p é r i p h é r i q u e X10net

Uv Libre X10 47


5 *6 * Langage : Langage C7 * F i c h i e r : l i r e _ x 1 0 n e t . c8 *9 * Au teu rs : Gui l laume TANGUY ( ASI4 )

10 * Damien BARON ( ASI5 )11 * P ie r re−Yves AIMON ( ASI4 )12 * Date : Thu Jan 1 1 9 : 4 6 : 2 6 2 0 0 413 * /1415 # inc lude < s t d i o . h>16 # inc lude < u n i s t d . h>17 # inc lude < s t d l i b . h>18 # inc lude < sys / t y p e s . h>19 # inc lude < sys / s t a t . h>20 # inc lude < f c n t l . h>2122 i n t main (vo id )23 {24 i n t r e s u l t ;25 i n t fd ;26 char * bu f_add r ;27 char * b u f _ s t a t e ;28 i n t p id ;29 i n t a d r e s s e ;30 char * c h a i n e _ a d d r ;31 char * c h a i n e _ s t a t e ;3233 / * a l l o c a t i o n memoire* /34 bu f_addr =(char * ) ma l loc (1* s i z e o f( char ) ) ;35 b u f _ s t a t e =(char * ) ma l loc (1* s i z e o f( char ) ) ;36 c h a i n e _ a d d r =(char * ) ma l loc (3* s i z e o f( char ) ) ;37 c h a i n e _ s t a t e =(char * ) ma l loc (3* s i z e o f( char ) ) ;3839 / * Ouvr i r l e f i c h i e r * /40 r e s u l t = open ( " / dev / x10ne t " , O_RDONLY) ;41 i f ( r e s u l t == −1) {42 re turn r e s u l t ;43 } e l s e {44 fd = r e s u l t ;45 }4647 / * L i r e ce f i c h i e r de p é r i p h é r i q u e en bouc le i n f i n i e* /48 whi le ( 1 ) {49 r e s u l t = read ( fd , bu f_addr , 1 ) ;50 i f ( r e s u l t = = −1) {51 p r i n t f ( " L e c t u r e i m p o s s i b l e \ n " ) ;52 } e l s e {53 p r i n t f ( " \ n \ nRecep t i on Paquet : \ nAdresse X10

l u e : %d \ n " , ( ( i n t ) ( * bu f_add r ) )&0x00FF ) ;5455 r e s u l t = read ( fd , b u f _ s t a t e , 1 ) ;56 i f ( r e s u l t == −1) {57 p r i n t f ( " L e c t u r e i m p o s s i b l e \ n " ) ;

Uv Libre X10 48


58 } e l s e {59 p r i n t f ( " E t a t l u : %d \ n " , * b u f _ s t a t e ) ;60 }6162 / * Ex éc u t e r heyu avec l a bonne a d r e s s e e t l e63 bon é t a t ! * /64 p id = f o r k ( ) ;6566 i f ( p id = = 0 ) {67 / * On e s t dans l e f i l s : e x é c u t e r

heyu * /68 / * a d r e s s e = ( i n t ) (* bu f_addr ) ;* /69 s p r i n t f ( cha ine_addr , "%x " , (* bu f_add r

)&0x00FF ) ;7071 i f ( ( i n t ) * b u f _ s t a t e = = 0 ) {72 c h a i n e _ s t a t e = " o f f " ;73 } e l s e {74 c h a i n e _ s t a t e = " on " ;75 }7677 p r i n t f ( " Adresse : %s − s t a t e : %s \ n "

, cha ine_addr , c h a i n e _ s t a t e ) ;78 e x e c l p ( " heyu " , " heyu " , " t u r n " ,

cha ine_addr , c h a i n e _ s t a t e , NULL) ;79 / * r e s u l t = e x e c l p ( " l s " , " l s " , NULL) ;

* /8081 } e l s e {82 / * A t t e n d r e que l e f i l s a i t t e r m i n é* /83 w a i t p i d ( pid , NULL, 0 ) ;8485 }86 }87 }8889 f r e e ( bu f_add r ) ;90 f r e e ( b u f _ s t a t e ) ;91 f r e e ( c h a i n e _ a d d r ) ;92 f r e e ( c h a i n e _ s t a t e ) ;9394 re turn EXIT_SUCCESS ;95 }

Uv Libre X10 49

ANNEXE E. MAKEFILE

Annexe E

Makefile

Uv Libre X10 50

ANNEXE F. SCRIPTS POUR LE MODULE

Annexe F

Scripts pour le module

F.1 Script de chargementload_x10net.sh

1 # ! / b in / sh2 i f c o n f i g x10net0 down3 rmmod x10net4 insmod− f . / x10ne t . o5 i f c o n f i g x10net0 i n e t 1 9 2 . 1 6 8 . 0 . 1 netmask 2 5 5 . 2 5 5 . 0 . 0 up

F.2 Script boucle.sh

1 # ! / b in / sh23 f o r i i n 1 2 3 4 54 do5 . / p ingx10 1 9 2 . 1 6 8 . 1 7 9 . 16 . / p ingx10 1 9 2 . 1 6 8 . 1 7 9 . 07 done

Uv Libre X10 51

ANNEXE G. CONFIGURATION

Annexe G

Configuration

Uv Libre X10 52

BIBLIOGRAPHIE

Bibliographie

[RC02] Alessandro Rubini and Jonathan Corbet.Pilotes de périphériques sous Linux. EditionsO’Reilly, Paris, France, deuxième edition, 2002.

[Ste94] W. Ricahrd Stevens.TCP / IP Illustarted : The protocols, volume one. Addison-WesleyPublishing Company, Inc., Reading, Massachussets, USA, 1994.

[Ste98] W. Ricahrd Stevens.TCP / IP illustré : Les protocoles, volume un. Editions Vuibert Infom-ratique, Paris, France, 1998.

[WPR+02] K. Wherle, F. Pählke, H. Ritter, D. Müller, and M. Bechler.LinuxNetzwerkarchitektur. Ad-disson Wesley Verlag, München, Deutchland, 2002.

[WPR+03] K. Wherle, F. Pählke, H. Ritter, D. Müller, and M. Bechler.Architecture réseau Linux :Conception et implémentation des protocoles réseau du noyau Linux. Editions Vuibert Infor-matique, Paris, France, 2003.

Uv Libre X10 53

Rapport d’UV Libre - Bienvenue dans le département...

Documents

Transcript of Rapport d’UV Libre - Bienvenue dans le département...