Projet Systèmes Embarqués :

Objets Connectés
Marc AUZARY – Clément PASCAL – Clément TARDELLA – Justin TESSIER

Encadrant : M.CRENNE

ème
3 Année Filière Electronique – Option Systèmes Embarqués

ENSEIRB-MATMECA
 Objets Connectés

TABLE DES MATIÈRES

Table des Figures .............................................................................................................................................. 3
Contexte ........................................................................................................................................................... 4
Introduction ..................................................................................................................................................... 5
1. Les Objets Connectés ............................................................................................................................... 6
1.1. Le choix de la carte ........................................................................................................................... 6
1.1.1. La carte Uno .............................................................................................................................. 6
1.1.2. Le microcontrôleur ATmega328 ............................................................................................... 7
1.2. Communication sans fil .................................................................................................................... 8
1.3. Choix du Shield ................................................................................................................................. 8
1.3.1. Wifi : Moyen de communication surdimensionné .................................................................... 9
1.3.2. Infrarouge : les ondes ne traversent pas les murs .................................................................... 9
1.3.3. Radio ......................................................................................................................................... 9
1.3.4. Blutooth et Xbee : les solutions envisageables ......................................................................... 9
1.4. Programmation de la carte par Bluetooth ...................................................................................... 10
1.4.1. Solutions éventuelles .............................................................................................................. 10
1.4.2. Solution finale ......................................................................................................................... 11
1.4.3. Envoi de données de la carte vers l’utilisateur ....................................................................... 13
2. L’Interface .............................................................................................................................................. 14
2.1. Principe ........................................................................................................................................... 14
2.2. L’interface de programmation ........................................................................................................ 14
2.2.1. Création de blocs .................................................................................................................... 15
2.2.2. La chaîne de compilation ........................................................................................................ 17
2.2.3. Exemple d’application ............................................................................................................ 18
Conclusion ...................................................................................................................................................... 19
Annexes .......................................................................................................................................................... 21
Script Windows .......................................................................................................................................... 21
compilation.lua........................................................................................................................................... 21
led_time_blink.cpp ..................................................................................................................................... 21
led_time_blink.lua ...................................................................................................................................... 22
light_sensor.lua .......................................................................................................................................... 22
light_sensor.cpp ......................................................................................................................................... 23
Références...................................................................................................................................................... 24

ENSEIRB-MATMECA – 2014/2015 Page 2

 Objets Connectés

TABLE DES FIGURES

Figure 1 - Prévision Objets Connectés .............................................................................................................. 4
Figure 2 - Arduino ............................................................................................................................................. 6
Figure 3 - Carte Arduino Uno ............................................................................................................................ 6
Figure 4 - Broches du microcontrôleur ATmega328 ......................................................................................... 7
Figure 5 - Principe de communication .............................................................................................................. 8
Figure 6 - Wifi ................................................................................................................................................... 9
Figure 7 - Zigbee ............................................................................................................................................... 9
Figure 8 - Bluetooth .......................................................................................................................................... 9
Figure 9 - Le shield Bluetooth ......................................................................................................................... 10
Figure 10 - Bouton Téléverser ........................................................................................................................ 10
Figure 11 - Mécanisme de compilation .......................................................................................................... 12
Figure 12 - Terminal de l'IDE........................................................................................................................... 13
Figure 13 - IDE Arduino................................................................................................................................... 14
Figure 14 - LUA ............................................................................................................................................... 14
Figure 15 - API fournie par M. CRENNE .......................................................................................................... 14
Figure 16 - Chaîne de clignotement ................................................................................................................ 15
Figure 17 - Bloc serial ..................................................................................................................................... 16
Figure 18 - Chaîne Serial-Graph ...................................................................................................................... 16
Figure 19 - Chaîne de compilation .................................................................................................................. 17
Figure 20 - Application Programming Interface.............................................................................................. 18

ENSEIRB-MATMECA – 2014/2015 Page 3

 Objets Connectés

CONTEXTE

Figure 1 - Prévision Objets Connectés

De nos jours, les objets connectés sont partout. D’après les prévisions Cisco, le nombre d’objets
connectés est estimé à 50 milliards en 2020, soit plus de 6 fois le nombre d’êtres humains sur terre. Cet
important développement est dû à la demande toujours de plus en plus grande ainsi qu’au grand nombre
de domaines dans lesquels les objets connectés s’insèrent. Cette importante évolution peut être également
mise en relation avec la recrudescence du nombre de smartphones. Leurs usages sont divers et variés, mais
avec souvent pour but de rendre notre quotidien plus facile.

Ils sont présents dans l’industrie médicale par exemple avec des capteurs connectés permettant
aux malades de suivre leur santé en direct sur leur smartphone. Aussi présents dans notre maison, les
objets connectés peuvent la rendre plus intelligente à l’aide de capteurs permettant de réduire notre
consommation énergétique et nos dépenses, ou de renforcer sa sécurité à l’aide d’alarmes pouvant
prévenir d’un éventuel incendie ou cambriolage. Une des grandes tendances est le sport connecté qui
mesure l’activité physique et permet de suivre des indicateurs tels que le nombre de pas réalisés dans la
journée, la distance parcourue ou les calories brulées. Ceci est rendu possible par une montre connectée à
un smartphone mais également grâce à l’introduction de nouveaux objets plus surprenants les uns que les
autres tels que le soutien-gorge connecté qui mesure le rythme cardiaque ou la pédale connectée muni
d’une puce GPS et d’une carte SIM qui permet à un utilisateur de localiser son vélo et donc de minimiser les
risques de vols.

Ces exemples illustrent que de plus en plus de Start-Ups et d’entreprises profitent de ce marché
fleurissant et décident de créer de nouveaux objets connectés. Travailler sur un projet de cette thématique
est donc une opportunité à saisir et sera certainement profitable dans notre vie professionnelle.

ENSEIRB-MATMECA – 2014/2015 Page 4

 Objets Connectés

INTRODUCTION

L’idée directrice de ce projet est de développer une interface permettant à des utilisateurs non
qualifiés de programmer des systèmes embarqués, donc des objets connectés. La réalisation de cette
interface comprend plusieurs choix, aussi bien matériels que logiciels.

Tout d’abord, nous avons choisi de travailler avec des composants électroniques faciles à
programmer : les cartes électroniques Arduino. Ce sont des composants développés en Italie par une
équipe d’étudiants et de professeurs. Leur principal objectif est de rendre l’électronique plus accessible au
niveau du coût et ainsi faire profiter aussi des débutants.

Par la suite, pour répondre à la thématique « Objets connectés » nous avons souhaité travailler
avec la technologie Bluetooth.

Enfin, disposant de peu de temps pour réaliser ce projet, nous avons souhaité nous appuyer sur
une interface graphique développée par notre encadrant. Nous avons donc dû apprendre un nouveau
langage, le LUA, langage de script.

Dans ce rapport, nous commencerons par une présentation de la technologie Arduino et du

matériel utilisé, puis nous développerons une partie sur l’API (Application Programming Interface). Enfin,
nous terminerons ce rapport en dressant un bilan de notre travail et des améliorations possibles et
concluront par un bilan plus personnel en relatant les compétences que nous avons acquises durant ce
projet.

ENSEIRB-MATMECA – 2014/2015 Page 5

 Objets Connectés

1. LES OBJETS CONNECTES

1.1. Le choix de la carte

La première étape de ce projet fut le choix de la plateforme pour réaliser nos objets connectés. Il
nous fallait trouver une plateforme de prototypage rapide, offrant de nombreux choix d’utilisation.

1.1.1. La carte Uno

Pour modéliser nos objets connectés, une carte électronique où des capteurs de
toutes sortes peuvent être branchés est nécessaire. Les cartes électroniques à bas prix
présentes sur le marché sont les cartes Arduino, la Beaglebone et la Raspberry Pi. Le
Figure 2 - Arduino
choix du groupe s’est porté sur la carte Arduino Uno pour différentes raisons :

 Plateforme de prototypage rapide Open Source, à bas coût et suffisant pour notre projet

 Communauté importante sur Internet, offrant ainsi de nombreuses fonctions à travers des
bibliothèques Open Source

 Le langage de programmation est simple et de haut niveau.

 La carte possède de nombreux pins d’entrées/sorties où différents capteurs peuvent être branchés

 La possibilité d’ajouter des Shields spécifiques (cartes filles) pour ajouter de nouvelles
fonctionnalités. Comme les communications doivent s’effectuer sans fil, le Shield adéquat sera
choisi. De plus si le projet évolue et que de nouvelles fonctionnalités doivent être ajoutées (liaison
Ethernet par exemple), il suffit de brancher un Shield supplémentaire correspondant à la fonction
désirée.

Figure 3 - Carte Arduino Uno

ENSEIRB-MATMECA – 2014/2015 Page 6

 Objets Connectés

La puissance de calcul nécessaire pour nos communications sans fil étant faible, le microcontrôleur
de la carte est suffisant. De plus nous bénéficions de toutes les souplesses qu’offre la carte.

1.1.2. Le microcontrôleur ATmega328

Le microcontrôleur utilisé sur la carte est le ATmega328. C’est un microcontrôleur Atmel de type
AVR. L’AVR est une architecture Harvard modifiée (séparation physique de la mémoire de données et la
mémoire programme) 8 bits RISC qui a été développée en 1996. Ce composant possède trois mémoires
distinctes :

• Une mémoire flash de 32 ko pour écrire le programme exécutable

• Une mémoire SRAM de 2 ko pour les données volatiles
• Une mémoire EEPROM de 1 ko pour les données non volatiles.

C’est donc dans la mémoire flash de ce composant que le programme exécutable doit être écrit.

Ce microcontrôleur possède également deux timer 8 bits et un timer 16 bits.

La présence d’un port série USART permet l’envoi et la réception de données ce qui est un point crucial
pour des problématiques d’objets connectés où la communication joue un rôle majeur.

La carte Arduino Uno est cadencée à 16 MHz. Notre projet ayant plus une vision applicative que
performante, cette horloge est suffisante. De plus le langage Arduino est de trop haut niveau pour que des
problématiques de MIPS ou de fréquence d’horloge se posent réellement.

En tout il y a 24 sources différentes d’interruptions. Le microcontrôleur ATmega328 est donc un

microcontrôleur de petite taille (32 ko de mémoire) mais possède toutes les sources d’interruptions
nécessaires pour notre projet. Le programme final ne faisant que 3.04 ko la mémoire du microcontrôleur
est donc suffisante pour nos applications.

Figure 4 - Broches du microcontrôleur ATmega328

ENSEIRB-MATMECA – 2014/2015 Page 7

 Objets Connectés

1.2. Communication sans fil

Dans un premier temps, une communication point à point entre un utilisateur et un objet connecté
est établie. Ensuite une des améliorations possibles peut être la construction d’un réseau d’objets
connectés. L’utilisateur est le maître de ces objets et donne des ordres via un ordinateur (ou application
smartphone dans un second temps). Un programme est alors généré et va être envoyé via une
communication sans fil dans la mémoire flash de notre Arduino. Si l’objet connecté comprend des capteurs,
alors l’envoi des données vers le PC sera également réalisé via une communication sans fil. La figure
suivante expose le principe de communication.

Utilisateur
(Ordinateur)

Retour de données
Programmation sans sans fil
fil

Objet connecté
(Arduino)

Figure 5 - Principe de communication

1.3. Choix du Shield

Il existe de nombreuses méthodes pour communiquer sans fil entre différents objets. Comme
expliqué dans la partie 1.1.1., un Shield doit être ajouté à la carte de base pour accéder aux nouvelles
fonctionnalités. Le but de cette partie est de choisir le Shield de communication le plus adapté à notre
projet. Les critères de choix étaient les suivants :

• Le shield doit autoriser la programmation de la carte mère sans fil

• Faible consommation d’énergie
• Faible coût

Les protocoles de communications étudiés étaient le Bluetooth, le Wifi, Xbee, radio et infrarouge.

ENSEIRB-MATMECA – 2014/2015 Page 8

 Objets Connectés

1.3.1. Wifi : Moyen de communication surdimensionné

Le principal défaut du protocole Wifi est son importante

consommation d’énergie. Il permet d’avoir une grande portée et
également un débit bien plus élevé que les autres protocoles.
Cependant, les fichiers de programmation (inférieurs à 32 ko) et les
données envoyées par la carte Arduino ont une très petite taille. Le débit
élevé du Wifi n’est donc pas utile dans notre cas. De plus, le groupe a
pris la décision que la portée des communications n’était pas un critère
de choix pour le moment. Des applications domestiques ont été ciblées.
Figure 6 - Wifi
Ainsi, une portée d’une dizaine de mètres est suffisante.

1.3.2. Infrarouge : les ondes ne traversent pas les murs

Pour établir une communication infrarouge entre deux modules, il ne faut pas d’obstacle sur le
chemin du signal. Or Cette contrainte réduit l’usage des objets connectés. Cette technologie a donc été
abandonnée.

1.3.3. Radio

La radio était une solution viable pour notre projet car elle répondait au critère « objets connectés »
tout en consommant très peu d’énergie. Cependant étant adeptes des nouvelles technologies nous nous
sommes tournés vers une autre solution. De plus, avec la radio, un premier problème d’incompatibilité
pouvait survenir en cas de création d’une application smartphone ou tablette.

1.3.4. Blutooth et Xbee : les solutions envisageables

Après avoir éliminé les autres moyens de communication, le choix s’est donc porté entre le
Bluetooth et le Xbee (le Xbee utilise le protocole Zigbee). Les caractéristiques sont assez similaires c’est-à-
dire un prix faible pour une portée et un débit faible. Cependant, la possibilité de programmer le
microcontrôleur de la carte mère à distance est l’un des critères les plus importants, et seule la
communication Bluetooth pouvait le permettre. Après différentes recherches, notre choix s’est porté sur le
Shield Bluetooth Bluefruit EZ-Link Shield de chez Adafruit. En effet ce Shield comprend un bootloader
offrant la possibilité d’envoyer à distance le fichier de programmation permettant de booter la carte avec
un nouveau programme, sans passer par un câble USB. De plus, grâce à un switch la carte permet de choisir
entre une communication USB ou sans fil.

Figure 8 - Bluetooth Figure 7 - Zigbee

ENSEIRB-MATMECA – 2014/2015 Page 9

 Objets Connectés

Ci- dessous le Shield utilisé :

Figure 9 - Le shield Bluetooth

Ce Shield développé par un constructeur de confiance possède également l’avantage de pouvoir

ajuster automatiquement son Baudrate à la vitesse de communication si celle-ci venait à varier.

1.4. Programmation de la carte par Bluetooth

Dans l’optique de construire une interface graphique pour

programmer notre carte, nous avons dû contourner
l’environnement de développement (Integrated Development
Environment) Arduino et reproduire toutes les étapes nécessaires,
de la génération du fichier binaire final au téléversement dans la
carte. Les développeurs d’Arduino, qui visent des programmeurs
débutants, ont rendu cela très simple grâce au bouton « téléverser
» présent dans l’IDE Arduino. Nous allons donc voir dans cette partie Figure 10 - Bouton Téléverser
comment nous avons pu nous dispenser de cet environnement.

1.4.1. Solutions éventuelles

Afin de compiler toutes les sources nécessaires à la création d’un fichier binaire exploitable par le
microcontrôleur, nous nous sommes tout d’abord penchés sur la solution d’un Makefile. Cependant,
l’interface graphique présentée par notre enseignant n’étant pas compatible avec le système d’exploitation
Linux, l’idée du Makefile s’est révélée compliquée car Windows ne dispose pas du logiciel Make présent
sous Linux. Pour résoudre ce problème, après quelques recherches, nous avons essayé de générer un
premier Makefile à l’aide d’un outil de construction sous Windows (c’est-à-dire un outil permettant
d’automatiser les étapes de préprocessing, compilation, éditions de liens, etc) appelé Cmake.
Malheureusement, cette démarche ne nous a pas permis d’aboutir au fonctionnement désiré.

Par la suite, nous avons eu connaissance suite à une de nos formations scolaire, de l’existence d’un
logiciel similaire à Make sous Windows accessible depuis le terminal MSDOS. Nous avons installé le package
MinGW et placé nos variables d’environnement afin que Windows reconnaisse l’existence de nos

ENSEIRB-MATMECA – 2014/2015 Page 10

 Objets Connectés

commandes. Une fois cela réalisé, la commande make Linux est devenue accessible à l’aide de la
commande mingw32-make sous Windows. Nous avons ensuite écrit un premier Makefile qui a fonctionné
pour de petits projets avec quelques fichiers sources, mais nous n’avons pas réussi à compiler toutes les
sources Arduino. Nous nous sommes donc tournés vers une autre solution que nous développerons dans la
partie suivante.

1.4.2. Solution finale

La solution finale était la création d’un script Windows. L’intérêt d’écrire un script est de pouvoir
encapsuler des fonctionnalités. De cette façon, si nous désirons faire appel à cette fonctionnalité depuis un
programme, il suffit d’écrire la ligne de code qui permet d’exécuter ce script. Il n’y a pas de modification à
apporter à l’intérieur. C’est ce qui sera effectué dans la partie II depuis l’API graphique.

Ce script a été écrit avec des chemins absolus. Pour pouvoir l’exécuter, il faut placer à la racine du
disque dur interne C :, le répertoire d’installation Arduino. Ce répertoire contient tous les outils
(compilateurs, bibliothèques…) nécessaires pour programmer la carte. Les différentes étapes sont
expliquées ci-dessous.

1.4.2.1. Suppression des fichiers précédents

Les fichiers générés pour la programmation précédente de la carte sont effacés avec la commande
del. De cette façon, il n’y a pas de risque d’écrire à la suite des fichiers précédents et le processus repart du
même point de départ.

1.4.2.2. Création du fichier objet

Le fichier source (template contenant le programme écrit en langage Arduino à être exécuté sur la
carte) est enregistré au format .cpp. Le langage Arduino étant une extension du langage C++, cette
opération permet d’utiliser un compilateur C++. Le résultat de la compilation est un fichier objet .o.

Le compilateur utilisé est avr-g++ avec de nombreuses options dont par exemple
-mmcu=atmega328p pour cibler l’architecture cible de notre microcontrôleur ATmega328. Le compilateur
avr est un compilateur spécialisé pour les microprocesseurs de type AVR.

1.4.2.3. Création du fichier exécutable

Afin de générer un fichier .elf, le fichier objet créé a besoin de bibliothèques de fonctions Arduino.
En effet, les fonctions (Serial.begin() de la bibliothèque Serial par exemple) ne sont pas écrites dans notre
code source mais dans des bibliothèques Open Source. Etant donné que tous les programmes Arduino
utilisent les mêmes bibliothèques de bases, une librairie core.a contenant toutes les bibliothèques

ENSEIRB-MATMECA – 2014/2015 Page 11

 Objets Connectés

compilées a été créée et compilée. Le fichier objet et la librairie core.a sont donc compilés ensemble pour
créer le fichier exécutable et liable .elf.

Les compilateurs utilisés sont avr- gcc pour les bibliothèques écrites en langage C, et avr-g++ pour celles en
langage C++.

1.4.2.4. Ecriture du programme dans la carte

Une fois le fichier exécutable ainsi généré, il faut l’exécuter sur notre cible. Grâce à la
documentation, une méthode pour écrire un fichier binaire .hex dans la mémoire flash du microcontrôleur
de l’Arduino a été trouvée. Il faut convertir le fichier exécutable et liable .elf en un fichier .hex. Pour cette
étape, l’outil avr-objcopy est nécessaire.

Il ne reste plus qu’à envoyer et écrire ce fichier dans le microcontrôleur. L’outil avrdude permet de
programmer les microcontrôleurs de la famille AVR dont fait partit le ATmega328 de la carte Arduino Uno.
L’utilisation de cette commande nécessite entre autre l’option flash:w:X.hex pour écrire dans la mémoire
flash ce fichier .hex. Il faut également préciser un port COM de communication ainsi qu’un débit d’écriture.

Dans notre script, nous exécutons 2 fois cette commande, l’une utilisant la liaison série par USB et
l’autre via la communication Bluetooth.

De cette façon, un programme Arduino écrit avec un éditeur de texte enregistré au format .cpp
peut être directement flashé sur l’Arduino avec l’exécution de ce script. La figure suivante illustre la chaîne
de compilation effectuée par le script :

Fichier Fichier Fichier

Source .cpp
objet .o exécutable .elf binaire .hex
g++ gcc objcopy

Bibliothèques
core.a

avrdude
Fichier binaire
.hex

Figure 11 - Mécanisme de compilation

Le script complet est fourni en annexe.

ENSEIRB-MATMECA – 2014/2015 Page 12

 Objets Connectés

1.4.3. Envoi de données de la carte vers l’utilisateur

Le Shield choisi pour ce projet permet l’envoie de données par Bluetooth. Il faut pour cela
positionner le switch du Shield en position « micro » pour permettre une communication Bluetooth. En se
positionnant sur cette position « micro », les pins TX et RX du microcontrôleur sont reliés à ceux du
composant Bluetooth. L’échange des données est donc assuré. Il est aussi possible de recevoir les données
via un câble USB pour cela il est nécessaire de repositionner le switch en mode USB.

La clé Blutooth connectée à l’ordinateur, permettant de communiquer avec la carte, virtualise un

port série. Ainsi, du pont de vue programmation, la communication s’effectue par liaison série. Il suffit donc
d’initialiser la liaison série dans la fonction setup() puis d’écrire les valeurs lues par le capteur sur cette
liaison série à l’intérieur de la fonction loop(). En ouvrant un moniteur série directement depuis l’IDE
Arduino, nous pouvons lire les valeurs envoyées par la carte via la communication Bluetooth.

Figure 12 - Terminal de l'IDE

ENSEIRB-MATMECA – 2014/2015 Page 13

 Objets Connectés

2. L’INTERFACE

2.1. Principe

Nous allons commencer par définir simplement ce qu’est une

API (Application Programming Interface) : c’est une interface logiciel
délimitée qui offre des services à d’autres logiciels. Elle a pour objectif
de simplifier la mise en œuvre d’un système en faisant abstraction des
détails de son fonctionnement.

Dans notre projet, nous souhaitons pouvoir programmer notre

système en nous abstrayant de l’IDE Arduino car elle n’est pas très
intuitive ni pratique d’utilisation (cf. figure 13). De plus, la connaissance
du langage de programmation propre à Arduino est nécessaire.

Enfin, un des points clé de notre travail consiste à offrir la

possibilité de concevoir et programmer des systèmes embarqués plus ou
moins complexes à une personne non initiée à la programmation. C’est-
à-dire sans avoir besoin d’écrire la moindre ligne de code.

Figure 13 - IDE Arduino

2.2. L’interface de programmation

Pour ce faire, notre tuteur sur ce projet nous a fourni les bases d’une API qu’il a
personnellement développée et que nous devions donc reprendre, améliorer et adapter à
notre projet. Cette interface est codée en langage C, en particulier à l’aide des outils SDL et
Open GL propres à la création d’interfaces graphiques. De plus cette interface est composée
de blocs à relier entre eux. Ces blocs sont implémentés grâce au langage de script LUA. Le
LUA est un langage de script léger qui est surtout utilisé dans le domaine des jeux vidéo. En
effet, le principe de cette API est d’utiliser des blocs réalisant chacun une fonction disponible Figure 14 - LUA

dans un catalogue et de les disposer sur le plan de travail pour concevoir un système.

Figure 15 - API fournie par M. CRENNE

Une fois la prise en main de cette API réalisée, nous avons deux objectifs. Le premier consiste à
créer de nouveaux blocs et le second permet de réaliser le lien entre le matériel (la carte Arduino) et le
logiciel (l’API).

ENSEIRB-MATMECA – 2014/2015 Page 14

 Objets Connectés

2.2.1. Création de blocs

La création de nouveaux blocs permet d’implémenter de nouvelles fonctionnalités pour l’objet

connecté. Ces blocs sont donc développés grâce au langage LUA.

 Base de données :

Une base de données de templates Arduino a été créée. Chaque template correspond à une fonction en
particulier. Il y a donc par exemple un template pour le clignotement de la LED, un autre pour l’utilisation
du capteur de lumière… Dans chaque template se trouve des balises #INX#. Ces balises correspondent à des
données avec lesquelles l’utilisateur peut interagir, comme par exemple, le temps entre deux états d’une
LED.

 Le fichier LUA :

Les blocs étant codés en LUA, nous avons dû apprendre la syntaxe du langage pour permettre de réaliser
nos fonctions. Le but de ces fichiers est de généré un fichier C++, à partir du template utilisé, en modifiant
les balises par les valeurs choisies.

Par exemple la figure ci-dessous permet de gérer le clignotement d’une LED :

Figure 16 - Chaîne de clignotement

Explications :

 Du point de vue schématique

Le bloc led_time_blink offre la possibilité à l’utilisateur de faire clignoter une LED. Ce bloc comprend 2
entrées, l’une permet de commander l’état de la LED au démarrage (reliée à constant_1) et l’autre indique
le délai en milliseconde entre les changements d’état de la LED (reliée à constant_100).

 Du point de vue algorithmique (bloc led_time_blink)

Le fichier LUA correspondant au bloc led_time_blink récupère les données en entrée du bloc, et va générer
un fichier C++, à partir de la template Arduino correspondant à la fonction led_time_blink, en modifiant les
balises par les valeurs présentes sur les entrées du bloc. Les entrées sont tout d’abord récupérées à chaque
rafraîchissement par la fonction Update :

function Update( r, h )

Avec r[1] qui correspond à l’état de la LED au démarrage et h[1] le délai en milliseconde entre deux états de
la LED.

ENSEIRB-MATMECA – 2014/2015 Page 15

 Objets Connectés

Ensuite la génération du fichier C++ avec la modification des balises est réalisée grâce à l’utilisation des
fonctions LUA suivantes :

o Ouverture de fichier

file_read = io.open(filename,'r')

Permet d’ouvrir le fichier "filename". Nous utilisons les modes lecture (‘r’) ou écriture ("w+").

o Lecture et récupération du contenu d’un fichier

text = file_read:read("*all")

Permet de récupérer l’ensemble du contenu du fichier ("*all") et de le stocker dans la variable text.

o Modification du contenu

text = string.gsub(text, "#IN2#", tostring(delay))

Cette fonction permet de modifier le contenu de la variable text, en remplaçant toutes les chaînes de
caractères "#IN2#" par la chaîne de caractère contenu dans la variable delay.

o Ecriture dans un fichier

file_write:write(text) – écrit text dans le fichier

Permet d’écrire le contenu de la variable text dans un fichier préalablement ouvert en écriture ("w+").

Maintenant vient le problème de la communication entre blocs de types différents. Pour cela, des
blocs de transtypage ont dû être créés. Dans le cas de l’exemple précédent, un transtypage d’un entier
vers un booléen était nécessaire. C’est donc pour ça que nous avons utilisé le bloc inttobool.

Désormais, il faut un bloc capable de récupérer les informations que la

carte peut envoyer à l’ordinateur via la liaison série. Ce bloc est nommé serial (cf.
figure 17). A noté que la communication Bluetooth fonctionne exactement de la
même manière que la communication série simplement le port est différent. Le Figure 17 - Bloc serial
Bluetooth virtualise une liaison série ce qui est très appréciable.

Enfin, un bloc _graph, réalisé en langage C, permet de tracer des données. Ainsi la chaîne Serial-
Graph permet de récupérer les données provenant de l’objet connecté, et de les tracer sur un graphique.
Comme par exemple avec des données de luminosité provenant d’un capteur de lumière :

Figure 18 - Chaîne Serial-

Graph

Une fois le système dessiné, il faut être capable de le compiler et l’implanter sur la carte.

ENSEIRB-MATMECA – 2014/2015 Page 16

 Objets Connectés

2.2.2. La chaîne de compilation

Cette chaîne définit l’ensemble des étapes de compilations d’un programme pour un processeur
donné. L’objectif de cette chaîne est de transformer un code source écrit dans un langage de
programmation (langage source) en un autre langage (langage cible). En effet, pour que la machine puisse
exploiter le code écrit dans un langage de haut niveau aisément compréhensible par l’homme, il faut plus
traduire en un langage machine de bas niveau.

Dans notre cas, la machine hôte (ordinateur) est différent de la machine cible (carte Arduino), il
faut donc être capable de compiler le code source pour qu’il puisse fonctionner sur une architecture de
processeur différente de celle de la machine qui effectue la compilation. On parle de compilation croisée.

Nous avons pour cela créé un bloc de compilation que nous pouvons activer à l’aide d’un switch
lorsque nous souhaitons implanter notre programme :

Figure 19 - Chaîne de compilation

Le bloc LUA implémenter réalise simplement un appel système pour exécuter le script Windows
expliqué dans la partie 1.4. :

os.execute("script.bat")

Ce bloc de compilation est un point central ayant une place primordiale dans notre projet. Après
plusieurs étapes (décrites précédemment) incompréhensibles pour un non initié, ce bloc permet de faire le
lien entre la partie logicielle et la partie matérielle de notre système. A l’aide d’appels systèmes réalisés
grâce au LUA, différentes étapes d’ajout de bibliothèque et de compilation, il permet, pour parler
simplement, de traduire le système décrit en blocs sur le plan de travail en un fichier qu’il exécute sur la
carte cible.

ENSEIRB-MATMECA – 2014/2015 Page 17

 Objets Connectés

2.2.3. Exemple d’application

L’exemple suivant permet de programmer un objet comprenant un capteur de luminosité. L’objet

va donc nous renvoyer la valeur de la luminosité, que l’on va récupérer grâce au bloc serial et nous allons
tracer ensuite les données sur un graphique par le biais du bloc _graph.

Figure 20 - Application Programming Interface

ENSEIRB-MATMECA – 2014/2015 Page 18

 Objets Connectés

CONCLUSION

Bilan sur le système délivré :

Tout d’abord, le premier point que nous relevons au terme de ce projet est que nous avons un
système fonctionnel ce qui est en soit très satisfaisant. De plus le choix de matériel Arduino permet d’avoir
des systèmes à prototypage rapide à bas coût. Bien sûr le produit n’en n’est qu’au stade de prototype et
nous avons relevés plusieurs pistes d’amélioration :

 La plus importante à nos yeux se porte sur la communication sans fil. En effet, nous avons choisi
d’utiliser le Bluetooth car cette technologie consomme peu d’énergie mais surtout car elle nous a
permis de pouvoir programmer la carte Arduino à distance, ce qui est un point fort de notre
système. Cependant, les Shields Bluetooth, de par leur caractère exclusivement esclave, nous
permettent uniquement de communiquer en point à point. Il n’est donc pas possible de
communiquer entre l’ordinateur et plusieurs cartes en même temps. De plus, il est impossible de
faire échanger les cartes entre elles, ce qui borne les possibilités d’élaboration de système. Peut-
être faudrait-il changer de technologie pour palier à ce problème et les remplacer par des Shields
capables de se configurer en master/slave sans perdre de vue la possibilité de programmation à
distance.

 Une autre amélioration se porterait sur l’API. Son utilisation déjà très simple pourrait se trouver
l’être encore plus, en ajoutant un bouton de téléversement remplaçant notre duo « bloc
compilation et switch d’activation ». En effet, il est peu intuitif pour un non initié d’avoir un bloc
« téléversement » a activé avec un bouton switch pour programmer son système. De plus les blocs
créés sont très basiques, il serait intéressant de fournir le catalogue et développer des blocs plus
complexes. Il serait aussi utile de réussir à s’abstraire des blocs de conversion de type de donnée,
pas forcément simple à comprendre et à utiliser pour un débutant en informatique. Le design
pourrait aussi se voir étoffer pour rendre l’API plus accueillante et intuitive avec entre autre la
possibilité de sauvegarder un projet.

 Par la suite, il pourrait aussi être très intéressant de « traduire » cette API sous forme d’application
smartphone ou tablette pour que l’utilisateur puisse programmer et utiliser son système de cette
manière.

 Enfin, l’API pourrait offrir la possibilité à un initié de venir créer ses propres blocs, grâce par
exemple à un tutoriel.

Conclusion d’équipe :

Ce projet nous a permis à chacun de développer nos aptitudes à travailler en équipe. Nous avons
dû nous confronter à des tâches d’organisation, de répartitions des tâches et de mise en commun des
différents travaux ce qui est très intéressant pour notre future vie professionnelle en entreprise.

Techniquement nous avons appris beaucoup de choses. Tout d’abord sur les outils Arduino, nous
avons amélioré nos capacités en termes de développement de code mais nous avons pu aussi nous rendre

ENSEIRB-MATMECA – 2014/2015 Page 19

 Objets Connectés

compte que ces produits sont simple d’utilisation mais aussi particulièrement adaptables. En effet, le
principe d’ajouts de Shields offre des possibilités presque illimitées quant au développement d’un système.

Nous avons aussi pu apprendre ce que signifiait vraiment « Compiler ». En effet, au cours de notre
cursus nous avions l’habitude soit de cliquer sur un bouton ou d’utiliser l’outil « Makefile » fourni par notre
enseignant pour réaliser cette étape. Ce projet nous a permis de mieux comprendre chaque étape de la
chaîne de compilation.

Enfin, nous avons appris les bases du langage de script LUA intégrable facilement dans la plupart
des projets et particulièrement apprécié par les développeurs de jeux vidéo.

Tous ces points font que nous sommes très satisfaits sur l’apport de ce projet dans notre cursus et
nous espérons avoir apporté au projet pour qu’il puisse être repris les années suivantes à l’ENSEIRB-
MATMECA pour en faire un produit abouti.

ENSEIRB-MATMECA – 2014/2015 Page 20

 Objets Connectés

ANNEXES

Script Windows
echo suppression X.o X.elf X.hex
del X.o blX.elf X.hex

echo creation X.o a partir de X.cpp

C:\Arduino\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-
sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=22 -I
C:\Arduino\hardware\arduino\cores\arduino\ -o X.o X.cpp

echo creation X.elf a partir de core.a et X.o

C:\Arduino\hardware\tools\avr\bin\avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -
o X.elf X.o core.a -L core -lm

echo creation X.hex a partir de X.elf

C:\Arduino\hardware\tools\avr\bin\avr-objcopy -O ihex -R .eeprom X.elf X.hex

echo upload du .hex

C:\Arduino\hardware\tools\avr\bin\avrdude -C
C:\Arduino\hardware\tools\avr\etc\avrdude.conf -p atmega328p -c arduino -P \\.\COM6 -
b115200 -D -U flash:w:X.hex
C:\Arduino\hardware\tools\avr\bin\avrdude -p atmega328p -c arduino -P COM5 -
b115200 -U flash:w:X.hex

echo Fait

compilation.lua

local test=0

function Update( r )
if r[1]==true then
if test==0 then
os.execute("script.bat")
test=1
end
else
test=0
end
end

led_time_blink.cpp

#include "Arduino.h"/**/

int LED=13;
boolean etat=#IN1#;

void setup()
{
pinMode(LED,OUTPUT);
}

void loop()
{
digitalWrite(LED,etat);
delay(#IN2#);
digitalWrite(LED,!etat);

ENSEIRB-MATMECA – 2014/2015 Page 21

 Objets Connectés

delay(#IN2#);
}

led_time_blink.lua

function Update( r, h )
if test==0 then
replaceB("./template/led_time_blink.cpp", r[1], h[1])
test=1
end
end

function replaceB(filename, level, delay)

file_read = io.open(filename,'r')
if file_read == nil then
print("File read can not be opened")
else
print("File read opened")
text = file_read:read("*all")
file_read:close()
--do the job
if level == true then
text = string.gsub(text, "#IN1#", "1")
text = string.gsub(text, "#IN2#", tostring(delay))
else
text = string.gsub(text, "#IN1#", "0")
text = string.gsub(text, "#IN2#", tostring(delay))
end
print(text)
file_write = io.open("X.cpp","w+")
if file_write == nil then
print("File write can not be opened")
else
print("File write opened")
file_write:write(text)
end
file_write:close()
print("Job done")
end
end

light_sensor.lua

function Update( r )
if test==0 then
replaceB("./template/light_sensor.cpp", r[1])
test=1
end
end

function replaceB(filename, level)

file_read = io.open(filename,'r')
if file_read == nil then
print("File read can not be opened")
else
print("File read opened")
text = file_read:read("*all")
file_read:close()
--do the job
if level == true then

ENSEIRB-MATMECA – 2014/2015 Page 22

 Objets Connectés

text = string.gsub(text, "#IN1#", "1")

else
text = string.gsub(text, "#IN1#", "0")
end
file_write = io.open("X.cpp","w+")
if file_write == nil then
print("File write can not be opened")
else
print("File write opened")
file_write:write(text)
end
file_write:close()
print("Job done")
end
end

light_sensor.cpp

#include "Arduino.h"

int photocellPin = 0;
int photocellReading;
boolean onOff = #IN1#;
String chaine;

void setup(void)
{
Serial.begin(115200);
}

void loop(void)
{
char buf[5] = {0,0,0,0,0};
photocellReading = analogRead(photocellPin);
chaine = String(photocellReading,DEC);
chaine.toCharArray(buf, 5);

if ( onOff )
{
Serial.write(buf[0]);
Serial.write(buf[1]);
Serial.write(buf[2]);
Serial.write(buf[3]);
Serial.write(buf[4]);
}
}

ENSEIRB-MATMECA – 2014/2015 Page 23

 Objets Connectés

REFERENCES

[1] www.arduino.ccc

[2] www.adafruit.com/product/1628

[3] www.francoistessier.info/blog/2011/07/06/programmation-arduino-en-ligne-de-commande/

[4] www.instructables.com/id/Wireless-upload-program-to-Arduino-without-USB-cab/

[5] www.lua.org

ENSEIRB-MATMECA – 2014/2015 Page 24