Actions
P13B04 Conception d'un serveur Wifi sur plateforme Rx63N¶
Projet GE2-GE3 2013 :
Entreprise / Client : Renesas électronic / Tolentino Martins
Auteurs : Jonathan Chassaing, Florent Montes
Responsable Projet : Michel James
Tuteur industriel : Gérard Chazelle
Sommaire¶
1. Résumé
2. Abstract
3. Introduction
4. Présentation du Sujet
1. Synoptique général
2. Présentation des éléments du système
1. Carte Gr-Sakura
2. Microcontrôleur RX63N
3. Module Wifi
1. Adaptation du module wifi sur la carte Gr-Sakura
2. Communication entre le Module WiFi et le RX63N
3. Pile TCP/IP
4. Fonctionnement de l’application
5. Récupération du Serveur-web Ethernet
6. Serveur-web Minimaliste
7. Création et insertion des pages web dans le Serveur
8. Organisation du Serveur
9. Performances
1. Etat d'avancement
2. Analyse Critique
3. Perspectives d'amélioration
1) Résumé¶
Le projet « serveur Wifi sur plateforme RX63N » concerne la réalisation d’un serveur web sur un microcontrôleur RENESAS. Cette entreprise souhaite la réalisation d’un tel projet afin de démontrer les performances de leur puce sur une application de type « serveur web wifi ».
Pour la réalisation de ce projet nous disposons d’une carte Gr-Sakura possédant un microcontrôleur RX63N qui sera la base de notre projet. Dans un premier temps, nous avons choisi puis adapté un module Wifi sur la carte GR-Sakura, de manière matérielle (carte d’adaptation) et logicielle (drivers). Dans un deuxième temps, nous avons créé un serveur web minimaliste que l’on a implanté dans notre programme final pour le faire communiquer avec le module wifi. Enfin, nous avons créé des pages personnalisées pour avoir un serveur web wifi fonctionnel.¶
Mots clés :
Serveur Web embarqué
Wifi
Gr-Sakura
RX63N
KPIT GNURX¶
Sommaire¶
2) Abstract¶
Le projet « serveur Wifi sur plateforme RX63N » concerne la réalisation d’un serveur web sur un microcontrôleur RENESAS. Cette entreprise souhaite la réalisation d’un tel projet afin de démontrer les performances de leur puce sur une application de type « serveur web wifi ».
Pour la réalisation de ce projet nous disposons d’une carte Gr-Sakura possédant un microcontrôleur RX63N qui sera la base de notre projet. Dans un premier temps, nous avons choisi puis adapté un module Wifi sur la carte GR-Sakura, de manière matérielle (carte d’adaptation) et logicielle (drivers). Dans un deuxième temps, nous avons créé un serveur web minimaliste que l’on a implanté dans notre programme final pour le faire communiquer avec le module wifi. Enfin, nous avons créé des pages personnalisées pour avoir un serveur web wifi fonctionnel.¶
Mots clés :
Serveur Web embarqué
Wifi
Gr-Sakura
RX63N
KPIT GNURX¶
Sommaire¶
3) Introduction¶
Dans le cadre du projet industriel de Génie Électrique qui s’étend sur 250 heures, Renesas Electronics acteur majeur dans le domaine des microcontrôleurs (27 % des parts de marché) propose un sujet portant sur l'un des derniers microcontrôleurs de la gamme RX.
Cette entreprise désire mettre en avant les performances de son microcontrôleur RX63N à travers une application de type serveur web WiFi embarquée en utilisant des outils de développement gratuits.¶
Sommaire¶
4) Présentation du Sujet¶
4.1) Synoptique général¶
Le cœur de l’application est le microcontrôleur RX63N présent sur la carte GR-SAKURA, celui-ci devra être connecté à un module WiFi afin de rendre possible la communication sans fil. Grâce à ce module, le RX63N sera capable de communiquer avec un système possédant une interface web et une connexion WiFi. La carte d’adaptation permettra la connexion physique entre le module et la carte Gr-Sakura.¶
Sommaire¶
4.2) Présentation des éléments du système¶
4.2.1) Carte Gr-Sakura¶
La carte utilisée pour la réalisation du projet sera la GR-SAKURA (voir photo ci-dessous). Elle est fabriquée par Wakamatsu Tsusho en partenariat avec Renesas. Elle est disponible chez quelques grands distributeurs de composant électronique. Une programmation directement par USB et l’utilisation d’un compilateur web Renesas en fait une carte abordable au grand publique (voir start guide).¶
détail des caractéristiques de la carte
Sommaire¶
4.2.2) Microcontrôleur RX63N¶
Le microcontrôleur utilisé sur ce projet est le RX63N, distribué par Renesas. Il fait partie de la famille des RX, dont les grandes lignes sont résumées sur le schéma ci-dessous.
RX Family¶
Ce microcontrôleur possède des caractéristiques suivantes :¶
- Calculs sur 32bits
- Fréquence max 100MHz
- 1 MBytes main flash memory
- 128kBytes SRAM
- 128 ports E/S
- Bus RSPI
- Ethernet Mac¶
Le grand intérêt de ce microcontrôleur dans notre projet est son "ethernet controler" qui permet de gérer via l'ethernet les problématiques liées aux protocoles spécifiques à l'internet (ex : pîle TCP/IP...).
Il possède également un BUS SPI, qui va servir pour communiquer avec le module wifi.¶
Sommaire¶
4.2.3) Module Wifi Redpine RS9110¶
Le module wifi choisi pour ce projet est le Redpine RS9110-N-11-22.¶
Ce module possède les caractéristiques suivantes :¶
- Norme wifi 802.11b/g compatible 802.11n
- Fonction série vers sans fil inclus
- Modes de sécurité WPA/WPA2-PSK, WEP et TKIP
- Interface hôte : UART et SPI
- Pile TCP-IP incluse, possibilité de la bypasser en mode SPI
- Antenne intégrée et horloge basse fréquence
- Consommation ultra réduite en mode veille.¶
Afin de simplifier la mise en œuvre du module WiFi, nous avons choisi le modèle compatible avec la carte de développement RDK de Renesas. Dans un premier temps, ceci va nous permettre d’utiliser les applications note fournies avec le module Redpine.¶
Sommaire¶
4.3) Problématiques¶
Le projet s’organise essentiellement autour de trois grandes problématiques :¶
- Connexion du module WiFi à RX63N¶
- Communication entre le programme Webserveur présent sur la carte GR-SAKURA et la plateforme de contrôle WiFi¶
- Communication entre la carte capteurs actionneurs et le programme Webserveur¶
Sommaire¶
5) Cahier des Charges¶
- Microprocesseur RX63N sur plateforme GR-SAKURA
- Webserveur Ethernet existant
- Portage du webserveur en WiFi
- Utilisation de ressources gratuites (outils de développement et de conception)
- Création d’une documentation technique en anglais¶
Sommaire¶
6) Développement¶
6.1) Adaptation du module wifi sur la carte Gr-Sakura¶
Pour cette première partie, nous avons eu recours à la sous-traitance aux élèves de deuxième année génie électrique. Nous avons choisi de sous-traiter, la réalisation d’une carte d’adaptation afin de pouvoir connecter le module WiFi directement sur la carte Gr-sakura. Cette carte se présente sous la forme ci-dessous.¶
La forme de cette carte nous permet de venir la plugger directement sur les borniers de la carte Gr-Sakura, ce qui nous permet une connexion rapide et fiable du module WiFi (voir animation ci-dessous).¶
Pour finir grâce à cette carte d’adaptation le module WiFi est connecté de la même manière que sur la carte de développement RDK. Ce qui nous permet une portabilité de code entre la carte de développement RDK et la carte Gr-Sakura.¶
Sommaire¶
6.2) Communication entre le Module WiFi et le RX63N¶
Dans un premier temps, nous avons décidé d’utiliser la liaison SPI pour réaliser le dialogue entre le module WiFi et le RX63N. Nous avons préféré l’utilisation cette connexion, car elle présentée des vitesses de transfert supérieur à la liaison UART disponible, ce qui permettaient de nous rapprocher le plus du cahier de charges initial.¶
Pour la mise au point de la première version de notre système nous avons réutilisé une partie des librairies SPI fournies dans l’application note de Redpine. Les principales fonctions utilisées sont les suivantes :¶
- Initialisation du module WiFi
- Ouverture socket
- Fermeture socket
- Lecture des données
- Envoi des données¶
Sommaire¶
6.3) Pile TCP/IP¶
Pour qu’un paquet de données (une page web par exemple) soit communiqué d’un ordinateur à un autre par internet, il faut respecter un protocole particulier : le protocole Ethernet. Chaque donnée envoyée sur le réseau l’est donc sous la forme d’une trame Ethernet, que l’on peut voir sur la figure ci-dessous.¶
Dans cette trame, il y a un paquet qui nous intéresse particulièrement, car il contient la donnée, le paquet IP. Ce paquet est composé d’une entête, de l’adresse IP de la machine source et de la destination, et enfin de la donnée en elle-même. C’est uniquement la donnée (appelée donnée IP sur le schéma) qui doit être transmise au serveur web afin qu’il puisse la traiter, et c’est uniquement cette donnée qu’il envoie également. Donc, pour que cette donnée soit transmissible par le protocole Ethernet, il faut l’empaqueter dans un paquet IP.
Ce paquet, c’est au rôle de la pile TCP/IP de le créer. Il y a différents moyens de le créer. Il peut être directement écrit dans le code du serveur web pour qu’il envoie un paquet IP tout entier, ou peut être créé grâce à une fonction externe, afin que notre serveur s’occupe uniquement de la donnée.
Il se trouve que créer cet empaquetage est extrêmement compliqué, et qu’un projet complet pourrait être dédié à ce sujet. Heureusement pour nous, le module wifi que nous avons utilisé contient directement une pile TCP/IP intégrée dans son microcontrôleur. Pour que notre programme marche, il nous a suffi d’envoyer à ce module seulement la donnée IP que le serveur est capable de générer, et le module se charge de créer un paquet IP. Ce module nous renvoie également la donnée qui nous intéresse seule, débarrassée de tout l’empaquetage d’un paquet IP.¶
Sommaire¶
6.4) Fonctionnement de l’application¶
Le programme de notre système pouvait être réalisé de deux manières différentes. Néanmoins, le cahier des charges nous a laissé le choix entre l’utilisation d’un noyau temps réel FreeRTOS ou une programmation séquentielle.¶
Dans un premier temps, notre choix s’était porté sur l’utilisation du noyau temps réel. Selon nous, il offrait des facilités de conception pour notre application. Cependant, l’utilisation de ce noyau temps réel demandait une étude préliminaire. Malheureusement, nous n’avons pas plus réalisé cette solution par manque de temps. C’est pour cela que nous avons développé une première version de l’application de manière séquentielle en utilisant les interruptions.¶
La figure ci-dessus représente le fonctionnement de notre application. Dans un premier temps, nous avons la phase d’initialisation du module WiFi. Durant cette phase, le module WiFi est configuré et la connexion à un réseau sans fil est établie. La seconde étape et réalisé dans une boucle infinie. Tout d’abord, l’ouverture d’une socket est réalisée afin de pouvoir recevoir les données, lorsque le module WiFi reçoit une information il déclenche une interruption. On effectue alors la lecture de la donnée reçue, celle-ci et traité par le Web-Serveur et enfin on ferme la socket pour indiquer au navigateur que la requête à bien été traité.¶
1. Initialisation:¶
La première partie de cette phase d’initialisation permet de configurer les entrées sorties du microcontrôleur. Dans un second temps, il faut configurer le module WiFi via la liaison SPI :
initialisation du module
scan des réseaux disponibles
connexion à un réseau sans fil (non sécurisé)
chargement des paramètres de connexion¶
2. Ouverture socket:¶
L’ouverture d’une socket permet de recevoir et d’envoyer des données via un protocole réseau (TCP). Dans notre application, nous ouvrons une socket sur le port 80, qui nous permet de recevoir des données provenant d’un autre système utilisant un navigateur web. L’ouverture de la socket et réalisée par le module WiFi. Lorsque celui-ci va reçoit une donnée sur la socket il déclenche une interruption.¶
3. Lecture des données reçues:¶
lorsque le module WiFi envoie une interruption, nous allons lire via la liaison SPI les données reçues sur la socket. Les données sont ensuite transférées dans des buffers pour être traitées par le serveur-web.¶
4. Web-serveur :¶
Le serveur-web traite les données reçues (requêtes) et renvoie les pages ou les fichiers demandés. Son fonctionnement sera détaillé dans les parties suivantes.¶
5. Fermeture socket :¶
Pour Termier la connexion nous fermons la socket, ceci est réalisé à l’aide d’une commande SPI envoyer au module WiFi. Ensuite nous ouvrons une nouvelle socket pour pouvoir recevoir les données suivantes.¶
Sommaire¶
6.5) Récupération du Serveur-web Ethernet¶
L’une des notes d’application de Renesas contenait un exemple de serveur web avec une connexion Ethernet. Ce programme est découpé en deux parties : La partie serveur web d’un point de vue applicatif, qui reçoit des requêtes et envoie des pages, et la partie pile TCP/IP qui se charge de transformer une requête Ethernet en donnée lisible par le serveur et vice-versa, comme nous pouvons le voir sur la figure suivante.¶
Pour que notre serveur fonctionne avec le module wifi, il faut garder de notre programme uniquement la partie application, car la pile TCP/IP est fournie avec le module Redpine. Ce qui est transmis depuis la carte wifi vers le microcontrôleur et donc notre programme est uniquement la requête décodée.
L’opération consistant à extraire uniquement la partie du programme qui nous intéressait s’est avérée extrêmement délicate. En effet, le code fait énormément de liens entre l’application et la pile logicielle. Les fonctions ne sont pas séparées et le serveur web passe son temps à appeler des fonctions de la pile.
C’est pour cela que nous avons décidé de ne pas retenir cette solution, et de créer nous même un serveur web minimaliste.¶
Sommaire¶
6.6) Serveur-web Minimaliste¶
Le synoptique ci-dessous décrit le fonctionnement du serveur web minimaliste que nous avons créé pour notre application. Celui-ci permet d’afficher les différentes pages présentes dans le microcontrôleur et de contrôler les sorties lorsqu’une action est demandée par une page HTML. Le serveur ne gère pas les fichiers CSS séparés.¶
Sommaire¶
6.7) Création et insertion des pages web dans le Serveur¶
Il est possible d’ajouter soit même des pages personnalisées sur le serveur web ! Pour cela, il faut procéder en 3 étapes.
Pour commencer, il convient de créer sa propre page web à insérer dans le serveur. Comme vous pouvez le voir sur la figure suivante.¶
Une page est écrite en html5 et css3, sans limite de taille sauf celle de la mémoire du microcontrôleur. Attention cependant aux images qui prennent rapidement beaucoup d’espace.
Pour que la mise en forme de la page soit fonctionnelle, le CSS doit être écrit directement dans la page html, à l’intérieur de la balise <head>. La gestion du CSS en fichier séparé n’est pas prévue par le serveur web.¶
Une fois la page correctement écrite et validée, il va falloir convertir cette page pour que le serveur puisse l’interpréter. Pour cela, la page doit être placée dans le dossier « page_web » situé à la source du programme, puis lancer le programme « http_convert.exe » disponible dans le dossier « soft ». Ces opérations sont détaillées de manière plus précise dans le User guide joint avec le projet.
Ce logiciel va convertir la page web en une suite d’octet et placer ces données dans une structure que le code va intégrer comme étant une page. Cette manipulation est nécessaire, car le serveur web ne dispose pas de gestionnaire de fichiers pour utiliser directement les pages.
Ne pas oublier, à chaque modification d’une page, de refaire cette manipulation.¶
Enfin, pour que le programme prenne en compte les modifications de la page, il faut recompiler le programme. Maintenant les pages sont ajoutées à votre serveur web.
Sommaire¶
6.8) Organisation du Serveur¶
Le serveur présent sur notre système comprend actuellement un total de 5 pages, pour une taille de 154ko. Les pages du serveur-web sont organisées comme sur la figure ci-dessous. À partir de la page index, nous pourrons naviguer sur les différentes pages présentes sur notre serveur.¶
Communication pages web / sorties microcontrôleur:¶
La page control LEDs va nous permettre d’interagir avec les sorties du microcontrôleur. En plus de l’envoi de la requête de la page, quand une commande d’allumage de led est demandée par l’utilisateur sur la page, le navigateur envoie une commande html spéciale, la méthode GET.
Cette méthode permet d’ajouter des paramètres à l’adresse de la page, qui sont noté à la fin de l’adresse avec une syntaxe similaire à celle-ci : « ?led1=Off&led2=On&led3=On »
Le programme analyse ces paramètres et allume les sorties du RX63N en conséquence. Ici, il va allumer la led 2 et la led 3 et éteindre la led 1.
On peut imaginer d’autres applications à ces paramètres, qui seraient en rapport avec l’utilisation de ce serveur (exemple : allumer un contacteur qui permet la fermeture des volets électriques d’une maison).¶
les pages :¶
Ci-dessous vous trouverez les pages du serveur-web au format html :¶
- page index
- page information
- page control LEDs
- page resume
- page température¶
Sommaire¶
6.9) Performances¶
Le programme prend une place totale de 309ko sur la mémoire du microcontrôleur. Ce qui laisse un espace d'environ 600ko pour les pages web. Nous pouvons voir sur la figure suivante que le programme avec les pages que l'on a implanté occupe actuellement 463ko d'espace mémoire.¶
Du côté de la RAM, elle est largement suffisante pour notre projet, il n'y aura donc pas de problèmes de surcharge et de performance de ce côté-là.
Sommaire¶
7) Gestion de Projet¶
Gantt¶
Dans l’objectif de mener à bien le projet, nous avons divisé le travail en plusieurs taches nous permettant ainsi d’avancer en parallèle sur la réalisation de notre système. Le découpage est présenté dans le diagramme de Gantt ci-dessous.¶
Sur la figure ci-dessus, nous pouvons voir que certaines tâches ont pris du retard. Malgré tout, nous avons quand même réussi à finir le projet dans les temps, notamment grâce à l’utilisation du serveur web-minimaliste qui nous a permis de récupérer le temps perdu sur l’étude du programme et la mise en œuvre de la carte WiFi.
Sommaire¶
8) Bilan¶
8.1) Etat d'avancement¶
Actuellement, notre application procède les caractéristiques suivantes :
- Attribution automatique de l’adresse IP via serveur DHCP
- Connexion réseau non sécurisée
- Version des pages HTML 5 et CSS3
- Support CSS intégré uniquement
- Pages interactives avec les sorties du RX63N¶
Par rapport au cahier des charges initial, nous n’avons pas rempli tous les critères demandés. Notamment au niveau de la réutilisation du serveur web de Renesas qui n’a pas été réalisé par manque de temps. Nous avons utilisé un serveur minimaliste pour pallier à ce problème et fournir une application fonctionnelle au terme de ce projet.¶
Sommaire¶
8.2) Analyse Critique¶
Le projet s'étalant sur un an, il est relativement difficile de prévoir au début toutes les étapes et les difficultés rencontrées. C'est pour cela que la tentative d'isolation du serveur web proposé par Renesas s'est avérée difficile et très gourmande en temps.
Gérer un peu mieux le temps aurait été une façon de progresser plus vite dans notre projet, ce qui ne nous a pas empêchés de rendre une version du programme fonctionnelle.
C'est le point positif de ce projet : le serveur marche, il répond au cahier des charges et est utilisable pour une démonstration, comme le souhaitait Renesas. Il restera quelques fonctionnalités à ajouter pour en faire un serveur totalement utilisable chez soi.¶
Sommaire¶
8.3) Perspectives d'amélioration¶
Le programme webserveur peut encore bénéficier d'ajout de fonctionnalités afin d'améliorer son fonctionnement.¶
Pour commencer, le programme n'est actuellement pas en mesure de gérer les pages de style (css) en fichier séparé. Ce qui pose un problème aux développeurs web qui utilisent de manière intensive cette façon de programmer. Il faudrait donc que le serveur puisse gérer ces feuilles de style correctement.¶
Du côté des pages dynamiques, seules les pages web peuvent contrôler les sorties du microcontrôleur actuellement. Il serait intéressant de pouvoir faire l'opération inverse, c’est-à-dire de lire de manière dynamique les entrées du microcontrôleur (par exemple un capteur de température). Cela augmenterait encore l'utilité d'une telle application.¶
Actuellement, une seule connexion au serveur est supportée à la fois. En effet, comme le serveur ne dispose d'aucun moyen de détecter plusieurs utilisateurs, il envoie de manière anonyme la dernière requête demandée à la dernière personne.
Une amélioration consisterait à détecter un utilisateur et traiter les requêtes en fonction de l'utilisateur, afin de gérer plusieurs connexions simultanées.¶
Une des problématiques clés de la norme wifi actuellement est la gestion de la sécurité du réseau. Or, pour l'instant, le programme ne permet pas de se connecter à des réseaux wifi sécurisés, il est donc difficile de l'utiliser dans des conditions normales. La gestion de la sécurité serait donc un objectif prioritaire d'amélioration de ce programme.¶
Enfin, une autre amélioration pourrait étendre les possibilités de ce serveur : le mode ad-hoc. ce mode consiste à utiliser le serveur comme étant directement le créateur du réseau wifi : il devient ainsi complètement autonome et ne dépend plus d'un routeur wifi externe.¶
Sommaire¶
9) Notes d'application¶
Sujet 1 : Jonathan Chassaing
Principle of TCP/IP stack¶
Sujet 2 : Florent Montes
Stream of minimalist web server design¶
Mise en œuvre du programme et de la carte :
Quick start guide project software¶
Sommaire¶
10) Bibliographie¶
- http://am.renesas.com
- http://www.redpinesignals.com¶
Sommaire¶
Mis à jour par Anonyme il y a environ 4 ans · 33 révisions