accès au cloud depuis une carte photon - welcome to … · 1°) tinker : application mobile pour...
TRANSCRIPT
PR310 2016/2017
ENSEIRB-MATMECA Page 1
Accès au Cloud depuis une carte Photon
Responsable de projet : J.Crenne
Olivero Estelle
Guerineau William
Albi Mathieu
Merchadier Romain E3, S9, Promotion 2017
PR310 2016/2017
ENSEIRB-MATMECA Page 2
SOMMAIRE
Introduction ...................................................................................................................................................................... 3
I - Cheminement du projet ................................................................................................................................................ 6
1°) Tinker : Application mobile pour accéder, configurer et contrôler les périphériques de Particle .......................... 6
2°) Utilisation du Cloud de Particle ............................................................................................................................... 7
3°) Communication par UDP : Wireshark et WinPcap .................................................................................................. 7
II - Emission paquets UDP ............................................................................................................................................... 10
1°) Présentation de la chaîne d’émission .................................................................................................................... 10
2°) Données codées sur 2 bits ..................................................................................................................................... 10
3°) Données codées sur 6 bits ..................................................................................................................................... 12
4°) Etablissement de la fréquence de fonctionnement .............................................................................................. 14
5°) Optimisation de la fréquence ................................................................................................................................ 15
III - Réception paquets UDP ............................................................................................................................................ 17
1°) Réception à l'aide du code C ................................................................................................................................. 17
2°) Réception à l'aide du code lua .............................................................................................................................. 18
3 °) Interface graphique Love2d .................................................................................................................................. 20
Conclusion ....................................................................................................................................................................... 21
PR310 2016/2017
ENSEIRB-MATMECA Page 3
Introduction
De nos jours, les objets connectés ou IoT (Internet of Things) progressent très vite dans notre société. La
plupart des secteurs d'activité mise sur ce domaine prometteur. En effet, l'essor des objets connectés constitue
un enjeu commercial important : le marché est estimé à 7 100 milliards de dollars soit environ 6 650
milliards d'euros en 2020. De même, en 2020, des statistiques prévoient que plus de 50 milliards d'objets
connectés seront vendus aux particuliers, ce qui représente environ 6 objets connectés par personne. Les objets
connectés dans les domaines de l'automobile, de la domotique ou des nouvelles technologies (smartphones,
tablettes tactiles, montres connectées) font désormais parti de notre quotidien depuis plusieurs années.
Néanmoins, ils vont faire leur apparition dans des nouveaux domaines plus insolites les uns que les autres tels
que l'industrie textile qui propose des tee-shirts connectés tel que le Team Pro Shirt de Polar, voir figures 1 et
2. Ce nouveau maillot, composé de deux capteurs, mesure en temps réel le rythme cardiaque. Ces capteurs
envoient donc directement les données sur une tablette tactile, pour le moment utilisé par des sportifs aux
Etats-Unis, ce dispositif permet à leur entraineur d'évaluer leur performance.
Le point commun entre tous ces objets connectés est la mise en œuvre du système de communication. En effet,
un dispositif tel qu'un capteur souhaite échanger des informations mesurées afin de les rendre disponibles via
une application et informer son utilisateur des mesures effectuées par le dispositif. Ainsi, plusieurs moyens de
communication peuvent être mis en place suivant le type d'architecture. Si la communication est qualifiée de
:
Courte-portée (environ 10cm): L'échange peut se faire par "contact physique", on utilise alors un
câble Ethernet ou un câble USB. Sinon, on peut utiliser la technologie NFC transmettant des données
sans fil à l'aide d'ondes.
Figure 1 : Team Polar Shirt
Figure 2 : Tablette connectée au Team Polar Shirt
PR310 2016/2017
ENSEIRB-MATMECA Page 4
Portée modérée (< 10 m) : L'accès à l'Internet peut se faire via un routeur et à l'aide des technologies
Bluetooth, Wi-Fi, ou radio avec les modules Zigbee.
Longue-portée : La transmission des données se fait via les réseaux cellulaires couverts par les
opérateurs de téléphonie par exemple les réseaux 2G, 3G, 4G ou LTE.
Parmi les techniques utilisées pour la communication à portée modérée, le module Photon Particle permet la
transmission de données via la technologie Wi-Fi. L'utilisation de ce module permet, à partir d'un simple
dispositif électronique, dans faire un dispositif connecté capable de communiquer avec son environnement,
voir figure 3 :
Figure 3 : Architecture d'un réseau d'objets connectés
Le kit de développement Photon de Particle permet de réaliser assez facilement des projets "connectés". Le
Photon est composé d'un microcontrôleur ARM Cortex M3 ayant pour fréquence de fonctionnement 120MHz,
d'un module Wi-Fi nommé P-Zero. Ce kit est composé de deux résistances, d'une led rouge et d'une photo
résistance et d'un câble USB pour l'alimenter.
Le Photon propose également les fonctionnalités suivantes, voir figure 4 pour leur placement sur le Photon :
Module Wi-Fi PØ Wi-Fi de Particle
une LED RGB informant l'utilisateur de l'état du Photon
18 entrées GPIO (I/O analogiques/numériques)
Conception Open-Source
Systèmes d'exploitation temps-réel
PR310 2016/2017
ENSEIRB-MATMECA Page 5
Le but de notre projet est d'établir une chaîne de communication entre un FPGA Nexys4 et un ordinateur, le
Photon faisant la liaison entre les deux. Tout d'abord, nous suivrons le cheminement de notre réflexion puis
nous analyserons la chaîne d'émission ainsi que la chaîne de réception de notre système de communication.
Figure 4 : Photon
PR310 2016/2017
ENSEIRB-MATMECA Page 6
I - Cheminement du projet
Ce projet a suivi un cahier des charges évolutif au fur et à mesure de son avancement, c’est pourquoi cette
partie retrace cette évolution, de la réception du photon et de ses logiciels au développement de la solution
d’envoi des données depuis le FPGA et de leur réception et sauvegarde sur un ordinateur.
1°) Tinker : Application mobile pour accéder, configurer et contrôler les
périphériques de Particle
La prise en main du Photon se fait de manière simple grâce à l’application mobile Tinker. Cette dernière
permet de reconnaître les périphériques alentours, configurer leur connexion au réseau Wi-Fi et de contrôler
ou observer l’état de ses pins.
Figure 5 : Application Tinker Particle pour mobile
L’application est donc utilisée au départ afin de prendre en main le Photon et contrôler l’état de deux LED.
L’application permet également d’observer l’état des pins reliées au FPGA qui lui envoie des données.
PR310 2016/2017
ENSEIRB-MATMECA Page 7
2°) Utilisation du Cloud de Particle
La compagnie Particle propose un service de Cloud pour les objets connectés de la marque. Ce service
permet de transmettre des informations depuis le Photon vers le Cloud afin de pouvoir y accéder depuis une
page Web n’importe où dans le monde comme illustré en Illustration du principe du Cloud de ParticleFigure 66.
Figure 6: Illustration du principe du Cloud de Particle
La fonction Particle.publish(const char *eventName, const char *data) permet d’envoyer des données sous
forme de chaine de caractères vers le Cloud. La page Web est codée en HTML et permet d’afficher les
valeurs publiées par le photon en renseignant l’identifiant de l’appareil ainsi qu’une clé d’accès.
3°) Communication par UDP : Wireshark et WinPcap
Le service "Cloud" proposé par Particle permet une mise à disposition simple et efficace des données
récupérées par le Photon à n’importe quel utilisateur disposant des codes d’accès. Cependant elle n’offre
aucun contrôle sur les méthodes de stockage et de sécurisation de ces données. C’est pourquoi il a été décidé
d’utiliser le protocole UDP afin d’envoyer des données directement entre le photon et un ordinateur qui fera
office de serveur, tous deux connectés à un même routeur.
La librairie WinPcap est un standard dans l’industrie pour la collecte de paquets réseau, elle permet
d’observer et d’interpréter les paquets afin d’accéder à des informations telles que l’adresse de source, de
destination, la longueur de la trame de données utiles et d’afficher les données. Cette librairie est d’ailleurs
utilisée par le programme Wireshark qui sert dans ce projet à s’assurer de la bonne réception des paquets
UDP sur l’ordinateur. Ce logiciel est utilisé dans un premier temps afin de mieux comprendre comment sont
structurés les datagrammes UDP et en particulier où se situent les données utiles dans ces datagrammes. Le
logiciel, montré en figure 7, permet également de définir des filtres afin de se limiter à l’observation d’une
communication en particulier.
PR310 2016/2017
ENSEIRB-MATMECA Page 8
Figure 7: Collecte de paquets UDP par le logiciel Wireshark
Pour aller plus loin que la simple observation de paquets, un programme en C est développé afin de
réceptionner et traiter les données grâce aux fonctions de la librairie WinPcap. Le premier objectif est
d’afficher les données reçues dans la console.
L’exemple UDPdump fournit avec la librairie permet de récupérer les paquets UDP passant par une carte
réseau (Wi-Fi ou Ethernet). Il faut tout d’abord définir le filtre selon l’adresse IP du Photon comme suit :
Viens ensuite la sélection de l’interface réseau utilisée pour la collecte des paquets et sa configuration. Enfin
la fonction pcap_loop() est appelée afin de capturer les paquets et les traiter. Cette fonction non modifiable
fait elle-même appel à une autre fonction, packet_handler() qui est modifiable et va permettre d’exploiter les
données de la façon voulue. Elle permet de stocker les différentes informations contenue dans le
datagramme dans des champs spécifiques d’une structure afin de faciliter leur exploitation.
Les données sont toutes contenues dans la chaine de caractères pkt_data. Afin d’afficher les données utiles à
la réception d’un paquet, il suffit d’itérer sur cette chaine à partir du 43ième caractère, les 42 premiers étant
utilisés par le protocole de communication. La fin de l’itération est déterminée par la longueur du paquet.
PR310 2016/2017
ENSEIRB-MATMECA Page 9
L’affichage des données dans la console se fait alors de la manière suivante :
Figure 8 : Affichage du contenu dans lachaîne de caractères pkt_data
L'affichage des données reçues en UDP dans la console est montré en Figure 9.
Figure 9: Affichage en console des données reçues
Pour garder une trace des données reçues, l’enregistrement dans un fichier texte est ajouté. A chaque paquet
reçu, le fichier texte est ouvert, les données y sont écrites et le fichier est refermé. Cela permet de rendre les
données disponibles à d’autres applications, d’y accéder en temps réel afin d’illustrer les données
graphiquement ou de les rendre disponibles sur Internet en passant par une base de données.
Ce code en C présente l’avantage d’utiliser une librairie existante pour la réception des paquets UDP qui
permet entre autre d’appliquer des filtres sur les paquets reçus. Cependant il présente l’inconvénient de ne
pas exploiter les données enregistrées et de ne proposer aucune interface graphique.
PR310 2016/2017
ENSEIRB-MATMECA Page 10
II - Emission paquets UDP
Après avoir acquis de l’expérience sur le fonctionnement du photon, nous avons commencé le
développement d’une chaîne de communication (voir Figure 10) entre un FPGA, une particule Photon et un
ordinateur.
Figure 10 : Chaîne de communication
1°) Présentation de la chaîne d’émission
La chaîne se compose d’un FPGA et d’une particule Photon. Notre FPGA est une Nexys 4 fonctionnant avec
l’environnement de développement ISE de Xilinx. Ce FPGA est cadencé avec une horloge de 100 MHz et sert
de plateforme de traitement de données.
Le photon, quant à lui, fonctionne avec une horloge de 26 MHz et sert à formater et transmettre les données
provenant du FPGA par Wi-fi à un ordinateur.
2°) Données codées sur 2 bits
Pour débuter l’émission de données, nous avons choisi de programmer une mémoire ROM (voir Figure 11)
dans le FPGA. Cette dernière se compose d’éléments codés sur 2 bits.
Figure 11 : Code de la ROM
Pour gérer le défilement de ces données, nous avons utilisé un compteur pour obtenir un changement toutes
les 4.5 secondes pour qu’il soit facilement observable.
Concernant le code arduino du Photon, nous avons défini deux entrées digitales sur lesquelles nous effectuons
une lecture de leur état, les entrées étant reliées par des câbles aux sorties de la Nexys. Nous avons observé
les valeurs reçues par le Photon avec des prints via le port série sur une console.
PR310 2016/2017
ENSEIRB-MATMECA Page 11
Toutefois, nous avons constaté sur cette même console l’affichage répétitif d’une même donnée envoyée par
le FPGA. Nous avons alors ajouté un signal de validation des données, émis depuis le FPGA : Idata. Ce signal
déclenche une interruption (voir Figure 12) sur le Photon qui active une variable autorisant le traitement de la
donnée.
Figure 12 : Interruption du code Photon
Pour vérifier l’exactitude des données, nous avons décidé d’ajouter des LEDs aux cartes, deux sur le FPGA
et deux sur le Photon. Nous avons alors pu constater la correspondance des données de façon visuelle.
Une fois la communication établie entre le Photon et la Nexys, nous avons choisi d’envoyer des données avec
le protocole UDP (voir Figure 13), plus rapide et simple à mettre en œuvre que TCP.
Figure 13 : Trame UDP
Pour cela, nous avons déclaré une instance UDP et choisi une adresse IP et un port pour la communication.
La transmission de données se fait avec la méthode sendPacket().
Les données reçues du FPGA sont converties et stockées dans un buffer pour être envoyées sous la forme
bit1/bit2, voir Figure 14.
Figure 14 : Buffer de données
PR310 2016/2017
ENSEIRB-MATMECA Page 12
3°) Données codées sur 6 bits
La chaîne de communication fonctionnant parfaitement avec des données codées sur 2 bits, nous avons décidé
d’augmenter le débit en générant des données sur 6 bits, voir figure 15.
Figure 15 : Chaîne de communication 6 bits
Pour obtenir de telles données, nous avons programmé un compteur allant de 0 à 63 (6 bits) grâce à
deux processus. L’un gérant les données Data_change (Figure 16) et l’autre la fréquence de comptage
Data_rdy (Figure 17).
Figure 16 : Processus Data_change
PR310 2016/2017
ENSEIRB-MATMECA Page 13
Figure 17 : Processus Data_rdy
Le processus Data_rdy utilise un signal Speed permettant de diviser la fréquence de l’horloge du FPGA pour
l’envoi de données avec le signal data_ready, utilisé dans le code, voir figure 17, et définie ci-dessous :
𝐹𝑟é𝑞𝑢𝑒𝑛𝑐𝑒 𝑑′𝑒𝑛𝑣𝑜𝑖 =𝐹𝑟é𝑞𝑢𝑒𝑛𝑐𝑒 𝐹𝑃𝐺𝐴
𝑆𝑝𝑒𝑒𝑑
La seule modification apportée au code du Photon est l’ajout de 4 entrées supplémentaires. Le format est
devenu bit1/bit2/bit3/bit4/bit5/bit6.
Ce format surcharge le buffer avec 88 bits pour une information d’origine sur 6 bits. Nous avons alors décidé
d’envoyer un caractère représentatif de la valeur. Le buffer est rempli de la façon suivante :
Nous ajoutons un ‘A’ pour pouvoir observer les valeurs sur la console car les premiers caractères ASCII ne
sont aptes à être utilisé pour des vérifications.
PR310 2016/2017
ENSEIRB-MATMECA Page 14
4°) Etablissement de la fréquence de fonctionnement
Par la suite, nous avons voulu établir la fréquence maximale du traitement des données par le Photon. Pour
cela nous avons choisi de programmer 4 interrupteurs sur le FPGA afin de pouvoir faire varier cette fréquence.
Grâce à cela nous avons pu déterminer un ordre de grandeur de la fréquence. Nous avons établi le tableau
suivant (Figure 18) :
Figure 18 : Tableau de la plage de fréquence
Nous nous sommes aperçus, grâce à une recherche empirique autour de 1 kHz, que lorsque nous dépassons
cette fréquence le Photon ne traite pas les données assez vite et cela résulte en une perte de celles-ci.
La fréquence étant faible, nous avons souhaité déterminer quelles parties du code prenaient le plus de temps.
Pour cela, nous avons utilisé la fonction micros() (Figure 19) qui retourne en µsecondes le temps écoulé depuis
l’initialisation du Photon.
Figure 19 : Utilisation de la fonction micros()
Nous avons consigné ces temps dans le tableau ci-dessous (Figure 20) :
Figure 20 : Détermination des temps de fonctionnement
Nous en avons déduit l’envoi des paquets UDP prenait le plus de temps. Il faut préciser que nous n’envoyons
qu’un seul caractère par paquet.
PR310 2016/2017
ENSEIRB-MATMECA Page 15
5°) Optimisation de la fréquence
Suite au problème relevé précédemment, nous avons choisi d’envoyer un buffer de 1024 caractères à la place
d’un seul. Cette méthode est connue sous le nom de “Burst”.
Cela nous a permis de réduire censément le nombre de paquet UDP transmis. Un tel paquet prend forcément
plus de temps à être envoyé, temps que nous avons évalué avec la méthode que précédemment, voir Figure
21.
Figure 21 : Détermination du temps d'envoi de paquets UDP
Nous remarquons que le temps d’envoi est sensiblement doublé alors que les données envoyées sont 1024 fois
plus nombreuses. Cette méthode est donc intéressante à mettre en place.
Une nouvelle batterie de tests a permis d’évaluer la nouvelle fréquence de fonctionnement du FPGA qui est
de 1,5 kHz, soit une amélioration de 50% des performances.
Le problème observé est que la Nexys impose la fréquence de fonctionnement alors que la limite est imposée
par le Photon. Pour y pallier, nous avons mis un fonctionnement de type “Handshake”, voir Figure 22.
Figure 22 : Schéma “Handshake”
Nous avons créé un signal Iphoton indiquant si le Photon est disponible pour le traitement de données. Le
FPGA prend donc ce signal en entrée et le traite dans le processus Data_rdy, voir Figure 23.
PR310 2016/2017
ENSEIRB-MATMECA Page 16
Figure 23 : Processus Data_rdy modifié
Nous avons modifié ce processus pour autoriser un envoi de donnée, grâce à data_ready, uniquement sur front
montant de Iphoton. Le front montant est traité avec l’ajout d’un signal Iphoton_hold.
Toutefois, il existe un cas dans lequel le Photon et le FPGA se trouvent bloqués à cause d’une
désynchronisation. Il s’agit du cas où les deux signaux Iphoton et Iphoton_hold sont égaux à 1 et que le Photon
est prêt à fonctionner. Nous avons résolu ce problème avec l’ajout d’un timeout d’une milliseconde pour ce
cas, voir Figure 24.
Figure 24 : Code du Timeout
Nous avons, à l’aide de WireShark, pu déterminer le débit maximal du Photon, qui est de 8189,27 bits/s.
Ce débit est relativement faible par rapport à nos attentes. Ceci est probablement dû à une importante
surcouche logicielle.
PR310 2016/2017
ENSEIRB-MATMECA Page 17
III - Réception paquets UDP
1°) Réception à l'aide du code C
Précédemment, un code C a été écrit pour la réception des paquets UDP. Deux gros inconvénients viennent
perturber notre démarche scientifique. Tout d'abord, dès lors qu'on reçoit un paquet UDP, on ouvre un fichier
texte dans lequel on sauvegarde chaque donnée reçue. Cette méthode est très chronophage car on reçoit les
informations à une haute fréquence, de plus, à chaque réception de paquet, on doit ouvrir, écrire puis fermer
le fichier de sauvegarde. Il convient donc de trouver une alternative qui résoudra ce problème. Ensuite, le
programme en C n'affichant les données que dans la console, l'application n'offre pas une interface graphique
agréable. Nous souhaitons rendre l'application ludique sans avoir à chercher ni traduire l'information reçue.
Pour cela, il existe un logiciel facile à utiliser nommé Love2d. Ce logiciel permet à des débutants de
programmer facilement des jeux en deux dimensions via la programmation en langage lua. On va donc s'en
servir comme interface graphique afin de rendre l'information visuelle et pédagogique.
Love2d possède sa propre librairie et via quelques exemples trouvés sur le net, nous avons réussi à afficher
l'état des LED du FPGA envoyé. Pour un bit mis à '1', la LED correspondante s'affichera en rouge (LED
allumée, voir figure 25) dans l'interface graphique et un bit à '0' sera représenté par une LED blanche (LED
éteinte, voir figure 26). Pour cela, nous avons décidé d'utiliser la fonction love.draw() qui permet d'afficher
l'état de LED sur notre interface. La fonction love.graphics.draw() permet de sélectionner la LED qu'on veut
afficher et de déterminer sa position dans la fenêtre d'affichage de Love2d, voir figure 27.
Figure 25 : LED allumée, bit à '1'
Figure 26 : LED éteinte, bit à '0'
Figure 27 : Affichage dans Love2d
Dans un premier temps, nous avons remplacé le fichier de sauvegarde généré par le code C par un fichier dans
lequel nous choisissons et actualisons les données nous-mêmes afin de vérifier l'affichage de nos LED. En
PR310 2016/2017
ENSEIRB-MATMECA Page 18
changeant le fichier de sauvegarde et une fois les modifications enregistrées, les changements de couleur sur
l'interface graphique s'opèrent automatiquement.
Une fois cette étape acquise, nous avons décidé d'y intégrer la fonction love.update(dt). Cette fonction va nous
permettre de lire en permanence le fichier de sauvegarde et ainsi actualiser les données reçues par le récepteur
afin d'afficher en temps réel l’état des LED.
Bien que résolvant le problème de l’affichage des données de manière explicite, cette méthode de
communication entre programmes par un fichier utilise beaucoup de ressources CPU ce qui amène souvent à
monopoliser la puissance de calcul de la machine et la bloquer.
2°) Réception à l'aide du code lua
Nous avons donc décidé de ne plus recevoir les paquets UDP à l'aide du code C mais en intégrant la réception
des paquets UDP dans notre code lua. Une fonction nommée upd:receivefrom(), de la librairie luaSocket,
placée dans la fonction love.update(dt) permet de rafraichir les paquets UDP reçus et la fonction file :write()
permet de les enregistrer dans un fichier de sauvegarde.
Toutes les variables dont nous aurons besoin sont définies dans la fonction love.load(), on y définie la socket
UDP, les informations sur les tailles des images (LED rouge ou blanche) et le fichier de sauvegarde, voir
figure 28.
Figure 28 : Définition des variables du programme
PR310 2016/2017
ENSEIRB-MATMECA Page 19
Ensuite nous captons les paquets UDP en temps réel, puis nous comparons les caractères reçus avec le
caractère "A" donc la correspondance en ASCII est l'entier 65. Nous traduisons la chaîne de caractère reçue
en ASCII et on retourne l'entier correspondant au premier caractère de la chaîne. Par soustraction des deux
entiers correspondants aux caractères ("?" - "A"), nous obtenons un entier que nous convertirons en base 2 qui
déterminera le caractère envoyé par la chaîne d'émission. L'algorithme est donné figure 29 :
Figure 29 : Actualisation des paquets UDP reçus
Puis nous comparons bit par bit la chaîne de caractère reçue précédemment avant d’actualiser la valeur de
chaque LED dans la fonction love.update(), voir figure 30 :
Figure 30 : Actualisation de la valeur de la première LED (bit de poids fort)
Nous allons voir maintenant comment se comporte notre système dans l'environnement graphique Love2d.
PR310 2016/2017
ENSEIRB-MATMECA Page 20
3 °) Interface graphique Love2d
Nous utiliserons désormais une application Androïd appelée "UDP Sender" pour effectuer les tests sur
l’application. Nous choisissons alors l'adresse IP à laquelle on enverra les paquets UDP, on peut ainsi contrôler
les messages que nous envoyons à l'ordinateur. Nous décidons d'envoyer un caractère, le résultat est donné ci-
dessous :
Figure 31 : Screenshot "UDP Sender"
Figure 32 : Interface graphique Love2d
On décide d'envoyer le caractère "R" à l'aide de l'application. Le caractère "R" dans la table ASCII correspond
à l'entier 82. En comparant ce caractère au caractère "A", ceci revient à faire l'opération suivante : 82 - 65 =
17.
La valeur correspondante en binaire est 010001 ce qui correspond au résultat affiché par l'interface graphique.
Peu importe le caractère compris entre "A" et "[DEL]", l'interface graphique Love2d permet de rendre ludique
et pédagogique le réel comportement des sorties numériques du FPGA Nexys4.
PR310 2016/2017
ENSEIRB-MATMECA Page 21
Conclusion
C’est un fait que les objets connectés sont omniprésents dans notre société. Grâce au Photon, il est possible
de connecter un objet qui ne l’est pas. Ce projet repose sur cet objectif, où l’objet à connecter est une carte
FPGA.
Pour l’accomplir, nous avons, tout d’abord, pris en main le kit de développement Wi-Fi Particule Photon grâce
à l’application Androïd Tinker et aux exemples fournis en ligne par Particle.
Suite à cela, nous avons établi notre chaine de communication entre le FPGA et un ordinateur, le Photon
assurant la liaison sans fil. La première étape consistait à transmettre des données générées depuis la Nexys
au Photon par liaison filaire. Une fois l’exactitude des données établie, ces dernières sont transmises via le
protocole UDP à l’ordinateur qui en effectue le traitement.
La seconde étape consistait à récupérer les données. L’outil Wireshark nous a permis de vérifier l’existence
des paquets UDP. Pour automatiser le traitement, nous avons développé une application en lua qui permet
d’extraire l’information utile. Cette information est ensuite stockée dans un fichier texte et représentée sur une
interface graphique.
Une application possible de notre projet serait une station météorologique sans fil. Soit différents capteurs
reliés à la carte FPGA comme des capteurs de température, d’humidité, de pression. Les données étant reçues
et traitées par le FPGA puis transmis par le Photon à un ordinateur.
D’autres solutions pouvaient être envisagées pour ce projet, comme une Raspberry Pi ou bien une carte
Arduino munie d’un module Wi-Fi. L’avantage du Photon réside dans sa simplicité, il propose uniquement
une interface Wi-Fi à un faible coût contrairement à ses concurrents qui proposent des cartes généralistes.
Figure 33 : Nexys 4 + Photon