Algorithme pour la configuration à partir d’une interface

Configurations disponibles

Il Y existe quelques manières différentes d’ utiliser le RN 171 . Premièrement, on peut l’ utiliser comme point d’ accès. Dans ce mode on peut configurer le nom du réseau et son mot de passe. Le module à aussi la capacité d’ aller cherché une adresse IP du serveur DHCP d’un routeur. Cette capacité est intégré dans le module et se réalise si l’option est sélectionné. On peut aussi utiliser le RN171 en client FTP. Le module va se connecter au serveur et peut créer et aller chercher des fichiers. Ces fichiers vont être transférés à travers le UART. Un autre mode de configuration est le client HTML qui permet au module de se connecter à un serveur Web et d’ inscrire des données sur celui-ci. Finalement, la façon que le RN171 est utilisé dans ce projet est de se connecter à un hôte externe. Le protocole UDP est utilisé pour envoyer des paquets à un ordinateur à travers un réseau préexistant. Le protocole TCP aurait aussi pu être utilisé, mais l’UDP a été choisi pour sa simplicité. Le désavantage d’ utiliser UDP est qu’ il serait possible d’avoir de la corruption ou de la perte de paquet, car il n’y a pas de validation de réception durant la communication.

Ce genre de problèmes n’a pas été observé en expérimentation, mais la méthodologie de communication défInie dans ce chapitre (section 3.3.2) offre la possibilité d’implémenter un CRC afm de vérifIer la validité des messages reçus. Le nombre d’ octets par message est aussi inclue dans ceux-ci donc, il serait possible d’implémenter un délai d’ attente qui déduit que le message n’est pas complet et que certains octets ont été perdus. Pour accéder au réseau, le module à besoin du nom du réseau et de son mot de passe. La communication requiert donc l’IP de l’hôte et le port utilisé pour le transfert. Une fois que le RN171 est mis en mode UDP, on peut utiliser seulement trois commandes pour le changer de réseau si nous ne changeons pas le port. Une commande pour l’ ip de l’ hôte, une pour le nom du réseau et une pour le mot de passe. Une autre commande utile est celle qui récupère les détails de la connexion du RN171 à l’hôte. Avec cette commande, nous pouvons savoir si la connexion a été établie entre le réseau et le module. Les commandes de base utilisées sont écrites dans le fIchier header de RN171cmd.c. Les commandes pour sauvegarder les nouvelles confIgurations sont situées dans leurs fonctions respectives. Pour avoir une référence aux diverses commandes, on peut consulter le manuel de référence des commandes WiFly dont le numéro de document Microchip est 50002230B.

Algorithme pour la configuration à partir d’une interface

Pour mettre le module en mode configuration, on envoie ‘$$$’. Une fois reçu, le module est prêt à recevoir des commandes. Les commandes sont des phrases ASCII envoyées par le UART. Par exemple, « set wlan ssid test \r\n’est une commande qui met à jour le nom du réseau dans le module à test. Il faut toujours enregistrer les modifications effectuées avec la commande « save\r\n » avant de revenir en mode de communication. Pour sortir du mode de commande, il faut envoyer « exit\r\n ». L’algorithme utilise trois structures tampons pour enregistrer les configurations localement sur le microcontrôleur. Deux de ces structures, présentes dans le fichier RN171_ comm.h, contiennent les données qui sont envoyées par le module après les deux commandes pour aller chercher les informations présentes dans le RN171. La première commande nous renvoie l’IP de l’hôte et l’autre le nom et mot de passe du réseau. Par contre, ces commandes envoient aussi d’autres informations sur les configurations du module, donc la troisième structure présente dans DefnType.h est utilisée pour garder seulement les trois configurations énumérées précédemment qui seront modifiées par l’usager.

Lors du démarrage, l’ algorithme attend que le module soit opérationnel et ensuite fait une requête pour l’information enregistrer dans le RN171 afin de remplir les tableaux de caractères situés dans leurs structures respectives. Cette séquence est représentée à la figure 3.3. Une fois les données enregistrées, le reste des étapes s’effectue lors d’une requête de l’ usager. Pour changer une configuration, l’usager doit entrer dans le menu WiFi. Lors de l’affichage de ce menu, un test de connexion est effectué pour pouvoir montrer à l’utilisateur l’état de celle-ci. Ce qui apparaît à l’ utilisateur sont les configurations copiées du tampon du réseau courant. Les nouvelles configurations mises par l’utilisateur ne sont pas mises à jour dans le tampon du réseau courant tant que celui-ci n’a pas appuyé le bouton pour télécharger les configurations vers le RN17l. Lorsque ce bouton est appuyé, l’algorithme envoie les trois commandes pour mettre à jour les configurations au module et il met aussi à jour le tampon des configurations actuelles du côté du microcontrôleur. Ceci est représenté par la figure 3.4.

Menus Le programme est divisé en quatre menus distincts.

Le premier est le menu principal (figure 4.6) où la passerelle opère de façon normale. Le deuxième menu est le menu de configuration Wi-Fi ou on peut trouver et modifier le nom et mot de passe réseau ainsi l’IP de l’hôte. On peut aussi voir l’état de la connexion avec le réseau et l’IP de la passerelle si présent. Les deux autres menus sont des menus claviers. Il y a un clavier pour l’ écriture des noms de réseau et de mot de passe. Puis, il y a un clavier numérique pour l’ écriture de l’IP de l’hôte. Ces claviers fonctionnent tous avec l’écran tactile et sont des images prises des claviers d’ appareils cellulaires. Dans le menu principal, on voit si la passerelle a bien effectué son démarrage. Nous avons un bouton pour accéder aux configurations Wi-Fi ainsi qu’un bouton qui sert à réinitialiser le module Wi-Fi. Le menu a beaucoup de place pour ajouter des fonctionnalités si nécessaire. C’est dans ce menu que le code qui autorise une lecture et un envoi vers le logiciel externe est présent. Si une demande est en attente de traitement et que la passerelle n’est pas en cours de lecture, nous traitons la demande. C’est aussi dans ce menu que l’on trouve l’ algorithme pour le démarrage du module RFID.

L’ algorithme est utilisé la première fois que le menu apparaît après un démarrage sans problème de la passerelle. À la figure 4.7, nous avons une représentation de l’ algorithme du menu principal. Comme on peut le constater, l’algorithme fmi seulement que lorsque nous appuyons sur le menu WiFi. Les algorithmes de menu sont le corps de la boucle du micro contrôleur. Le menu WiFi (figure 4.8) est composé de trois boutons et de trois boîtes de texte. Nous avons un bouton qui permet de fermer le menu, un bouton qui permet d’envoyer les données au module Wi-Fi et un bouton qui pennet de rafraîchir l’IP de la passerelle. Le bouton d’envoi utilise l’algorithme dédié à cette tâche expliqué dans le chapitre trois. Pour le rafraîchissement, le module fait un test de connexion et si elle est fonctionnelle, il affiche l’IP du module. Sur ce menu nous pouvons aussi appuyer sur les trois boîtes de texte pour modifier l’IP d’hôte, le nom du réseau ou son mot de passe. Cette action nous amène au menu clavier approprié. Il est important de noter que si l’utilisateur veut appliquer les modifications apportées aux boîtes de texte, il doit appuyer sur le bouton pour les envoyer au RN171. La figure 4.9 montre la représentation de l’algorithme du menu WiFi. Les menus claviers (figures 4.10 et 4.11) sont assez simples, ils prennent la chaîne de caractères et sa longueur et l’affiche à l’utilisateur. Tous les emplacements de touche sont en note dans le code et ils fonctionnent comme un clavier nonnal. Le clavier standard a deux versions, une nonnale et une autre pour les caractères spéciaux.

Le FAT32 est un système de fichier pour organiser la mémoire morte d’un périphérique qui a pour but de stocker de l’information. Ce système organise la distribution des pages de mémoires d’un fichier. Les pages ou secteurs de mémoire sont un bloc de mémoire continue de longueur fixe. Dans notre cas, la carte a des secteurs fixes de 512 octets. On peut aussi voir le terme cluster quand on fait des recherches sur le FAT32. Un cluster est simplement un regroupement de pages. Le nombre de secteurs par cluster varie selon le formatage et il est important de savoir combien de secteurs par cluster il y a pour faire une lecture précise, mais ce chiffre peut être retrouvé dans le boot sector de la partition utilisée de la carte. Ce secteur peut être trouvé en vérifiant le premier secteur de la carte qui est souvent nommé le master boot sector ou encore le master boot record. La seule information que nous cherchons réellement dans le MBR est le secteur ou la première partition commence. On peut trouver cette information de l’offset 454 à 457.

Avec ces quatre octets, nous pouvons reconstruire le numéro du secteur où se trouve le boot record de la partition. Le projet assume que la carte a seulement une partition pour simplifier le code. Pour un exemple de MBR, allez voir la référence [5] de la bibliographie. Le boot record de partition (exemple à la figure 4.13) varie un peu en fonction du FAT utilisé, mais nous allons détailler ces points importants pour le FAT32 seulement, car c’est le format utilisé dans le projet. Ces points sont le nombre de secteurs par cluster à l’offset 13, le nombre de FAT à l’offset 16, le nombre de secteurs par FAT de l’offset 36 à 39, le nombre de secteurs réservés de l’offset 14 à 15. Avec ces informations, nous pouvons trouver les secteurs où sont situés le début des FATs et le début du dossier root de la partition. Le début du premier FAT est trouvé en additionnant le secteur du boot record au nombre de secteurs réservés. Pour trouver le premier secteur où se situe le dossier root de la partition, nous additionnons le secteur du boot record avec le nombre de secteurs réservés et avec le nombre de FATs multiplié au nombre de secteurs par FAT. À la figure 4.13 nous avons un exemple de secteur de partition avec les éléments mentionnés surligné en couleur. Par exemple, nous avons le nombre de secteurs réservés surligné en bleu.

Table des matières

Résumé
Remerciements
Table des matières
Liste des tableaux
Liste des figures
1 Introduction
1.1 Problématique
1.2 Objectif
1.3 Méthodologie
1.4 Organisation du mémoire
2 Module RFID
2.1 Le module et ses spécifications
2.1.1 Module utilisé
2.1.2 Spécifications du module
2.1.3 Intégration au PCB [mal
2.2 Communication avec le module
2.2.1 Commandes de démarrage
2.2.2 Commandes de lecture
2.3 Algorithme d’envoi de commande
2.3.1 Algorithme de démarrage
2.3.2 Algorithme de lecture
2.4 Conclusion
3 Module Wi-Fi
3.1 Le module et ses spécifications
3.1.1 Choix du module
3.1.2 Spécifications du module
3.1.3 Intégration au PCB [mal.
3.2 Configuration du module
3.2.1 Configurations disponibles
3.2.2 Algorithme pour la configuration à partir d’une interface
3.3 Protocole et méthodologie d’envoi utilisé
3.3.1 Protocole utilisé
3.3.2 Méthodologie de communication
3.3.3 Algorithme d’envoi
3.3.4 Algorithme de réception sur PC
3.4 Conclusion
4 Passerelle RFID à Wi-Fi
4.1 Choix de technologie
4.1.1 Choix de contrôleur
4.1.2 Choix de micro contrôleur
4.2 Conception et fabrication du PCB
4.2.1 Alimentation
4.2.2 Communication externe pour débogage
4.2.3 Interface humain
4.2.4 Fabrication du PCB
4.3 Interface Humaine sur la passerelle
4.3.1 Menus
4.3.2 Algorithme d’initialisation de la carte SD .
4.3.3 Le FAT32
4.3.4 Algorithme de lecture de la carte SD
4.3.5 Algorithme d’affichage d’image bitmap
4.3.6 Algorithme relatif à l’écran tactile.
4.4 Résultats
4.5 Conclusion
5 Conclusion
Bibliographie
Télécharger le rapport complet