Polytech Projets Ge

h1=. P13B04 Conception d'un serveur Wifi sur plateforme Rx63N

p=. !https://forge.clermont-universite.fr/attachments/download/16367/p13b04_Renesas_20130506104552_20130506110315.jpg!

*Projet GE2-GE3 2013* :

*Entreprise / Client* : Renesas électronic / Tolentino Martins

*Auteurs* : Jonathan Chassaing, Florent Montes

*Responsable Projet* : Michel James

*Tuteur industriel* : Gérard Chazelle

---

h1. Sommaire

[[1. Résumé]] 

[[2. Abstract]] 

[[3. Introduction]] 

[[4. Présentation du Sujet]] 

p(((. [[1. Synoptique général]] 

[[2. Présentation des éléments du système]] 

p(((((. [[1. Carte Gr-Sakura]] 

[[2. Microcontrôleur RX63N]] 

[[3. Module Wifi]] 

p(((. [[3. Problématiques]] 

[[5. Cahier des Charges]] 

[[6.Développement]] 

p(((. [[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]]  

[[7. Gestion de Projet]] 

[[8. Bilan]] 

p(((. [[1. Etat d'avancement]] 

[[2. Analyse Critique]] 

[[3. Perspectives d'amélioration]] 

[[9. Notes d'application]] 

[[10. Bibliographie]]

---

h1<. *1) Résumé* 

h2. 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.

h2<. Mots clés :

Serveur Web embarqué

Wifi

Gr-Sakura

RX63N

KPIT GNURX

h2<. *%{color:red}Sommaire%* 

---

h1<. *2) Abstract*

h2. 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.

h2. Mots clés :

Serveur Web embarqué

Wifi

Gr-Sakura

RX63N

KPIT GNURX 

h2<. *%{color:red}Sommaire%* 

---

h1<. *3) Introduction*

h2. 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.

h2<. *%{color:red}Sommaire%* 

---

h1<. *4) Présentation du Sujet*

h2<. *4.1) Synoptique général*

p=. !https://forge.clermont-universite.fr/attachments/download/16368/p13b04_synoptique_1_20140102150429_20140102151307.png!

h2. 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. 

h2<. *%{color:red}Sommaire%* 

h2<. *4.2) Présentation des éléments du système*

h2<. *4.2.1) Carte Gr-Sakura*

h2. La carte utilisée pour la réalisation du projet sera la "GR-SAKURA":http://sakuraboard.net/index_en.html (voir photo ci-dessous). Elle est fabriquée par Wakamatsu Tsusho en partenariat avec "Renesas":https://www.renesas.com/eu/en. 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)":http://sakuraboard.net/index_en.html.

p=. !https://forge.clermont-universite.fr/attachments/download/16369/p13b04_carte_sakura_20130503142014_20130503142104.png!

"détail des caractéristiques de la carte":http://sakuraboard.net/gr-sakura_en.html

h2<. *%{color:red}Sommaire%*

h2<. *4.2.2) Microcontrôleur RX63N*

h2. Le microcontrôleur utilisé sur ce projet est le RX63N, distribué par "Renesas":https://www.renesas.com/eu/en. Il fait partie de la famille des RX, dont les grandes lignes sont résumées sur le schéma ci-dessous.

RX Family

p=. !https://forge.clermont-universite.fr/attachments/download/16370/p13b04_RX_family_20130512173749_20130512173802.gif!

h2. Ce microcontrôleur possède des caractéristiques suivantes :

h2(((. - Calculs sur 32bits

- Fréquence max 100MHz

- 1 MBytes main flash memory

- 128kBytes SRAM

- 128 ports E/S

- Bus RSPI

- Ethernet Mac

p=. !https://forge.clermont-universite.fr/attachments/download/16371/p13b04_schemaRX_20130512175519_20130512175541.gif!

h2. 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.

h2<. *%{color:red}Sommaire%*

h2<. *4.2.3) Module Wifi Redpine RS9110*

h2. Le module wifi choisi pour ce projet est le Redpine RS9110-N-11-22.

p=. !https://forge.clermont-universite.fr/attachments/download/16372/p13b04_Redpine_RS9110_20130512175519_20130512175553.jpg!

h2. Ce module possède les caractéristiques suivantes :

h2(((. - 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16373/p13b04_Redpine_block_20130512180208_20130512180223.jpg!

h2. Afin de simplifier la mise en œuvre du module WiFi, nous avons choisi le modèle compatible avec la "carte de développement RDK":https://www.renesas.com/us/en de Renesas. Dans un premier temps, ceci va nous permettre d’utiliser les applications note fournies avec le module Redpine.

p=. !https://forge.clermont-universite.fr/attachments/download/16374/p13b04_wifi_rdk_20140103111606_20140103115030.png!

h2<. *%{color:red}Sommaire%*

h2<. *4.3) Problématiques*

h2. Le projet s’organise essentiellement autour de trois grandes problématiques :

h2(((. - Connexion du module WiFi à RX63N

h2(((. - Communication entre le programme Webserveur présent sur la carte GR-SAKURA et la plateforme de contrôle WiFi

h2(((. - Communication entre la carte capteurs actionneurs et le programme Webserveur

p=. !https://forge.clermont-universite.fr/attachments/download/16375/p13b04_synoptique_2_20140102150429_20140102151711.png!

h2<. *%{color:red}Sommaire%*

---

h1<. *5) Cahier des Charges*

h2(((. - 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

p=. !https://forge.clermont-universite.fr/attachments/download/16376/p13b04_cahier_des_charges_20130503100208_20130503100520.png!

h2<. *%{color:red}Sommaire%*

---

h1<. *6) Développement*

h2<. *6.1) Adaptation du module wifi sur la carte Gr-Sakura*

h2. 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. 

p=. !https://forge.clermont-universite.fr/attachments/download/16377/p13b04_CAO_20140103100837_20140103101448.png!

h2. 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).

p=. !https://forge.clermont-universite.fr/attachments/download/16378/p13b04_adaptation_20140103103005_20140103110400.gif!

h2. 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.

h2<. *%{color:red}Sommaire%*

h2<. *6.2) Communication entre le Module %{color:red}WiFi% et le RX63N*

h2. 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. 

p=. !https://forge.clermont-universite.fr/attachments/download/16379/p13b04_SPI_20140115171006_20140115171656.png!

h2. 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 :

h2(((. - Initialisation du module WiFi

- Ouverture socket

- Fermeture socket

- Lecture des données

- Envoi des données

h2<. *%{color:red}Sommaire%*

h2<. *6.3) Pile TCP/IP*

h2. 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16380/p13b04_pile_20140124091617_20140124091755.png!

h2. 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.

h2<. *%{color:red}Sommaire%*

h2<. *6.4) Fonctionnement de l’application*

h2. 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.

h2. 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16381/p13b04_application_wifi_20140115164610_20140115170104.png!

h2. 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é. 

h3. 1. Initialisation:

h2. 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

h3. 2. Ouverture socket:

h2. 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.

h3. 3. Lecture des données reçues:

h2. 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.

h3. 4. Web-serveur :

h2. 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.

h3. 5. Fermeture socket :

h2. 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.

h2<. *%{color:red}Sommaire%*

h2. 6.5) Récupération du Serveur-web Ethernet

h2. 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16382/p13b04_structure_programme_renesas_20140122190504_20140122190530.png!

h2. 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.

h2<. *%{color:red}Sommaire%*

h2. 6.6) Serveur-web Minimaliste

h2. 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16383/p13b04_serveur_mini_20140115164610_20140115170540.png!

h2<. *%{color:red}Sommaire%*

h2. 6.7) Création et insertion des pages web dans le Serveur

h2. 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16384/p13b04_page_web_20140123012950_20140123013009.png!

h2. 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.

h2. 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.

p=. !https://forge.clermont-universite.fr/attachments/download/16385/p13b04_pasge_web_montage_20140123012950_20140123013028.png!

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.

h2<. *%{color:red}Sommaire%*

h2. 6.8) Organisation du Serveur

h2. 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. 

p=. !!