Polytech Projets Ge

!https://forge.clermont-universite.fr/attachments/download/15958/renesas_20160104112006_20160104112055.jpg! 

!https://forge.clermont-universite.fr/attachments/download/15959/logo_20160104111513_20160104111520.png!

---

*Projet GE4-GE5 2015* : Wifi Webserveur

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

*Auteurs* : Corentin Corde, Papa amadou Seck

*Responsable Projet* : Michel James

*Tuteur industriel* : Jonathan Bernard

---

p(((((((. *Résumé*

Le projet « serveur Wifi sur plateforme RZ-A1L » 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 ». Il s'agit d'une nouvelle famille de microcontrôleur basé sur une cible 32 bits de technologie ARM (cortex A9). Pour la réalisation de ce projet, nous utiliserons la pile TCP/IP CycloneTCP. Dans un premier temps, nous avons choisi puis adapté un module Wifi sur la carte de développement. Dans un deuxième temps, nous avons adapté un ancien projet de serveur web fonctionnant en filaire à notre application WIFI. 

Mots clés :

Serveur Web embarqué

Wifi

Renesas

RZ-A1L

---

p=. *Abstract*

The "WiFi server on RZA1L platform" project concerns the realization of a web server on a RENESAS microcontroller. The company wants the realization of this type of project to demonstrate the performance of their chip on an application of "wireless web server." This is a new microcontroller family based on technology 32-bit target (ARM Cortex A9). For this project, we will use a stack tcp/ip CycloneTCP. Initially, we selected and adapted a WiFi module on the development board. Secondly, we have adapted an old web server project running with ethernet to WIFI application.

---

p=. *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 RZ.

Cette entreprise désire mettre en avant les performances de son microcontrôleur RZ-A1L à travers une application de type serveur web WiFi embarquée en utilisant des outils de développement gratuit et open source.

---

p=. *Présentation du Sujet*

*Synoptique général*

La figure ci-dessous représente le synoptique général de notre application.

p=. !https://forge.clermont-universite.fr/attachments/download/15962/synoptique_20160105164028_20160105164917.png!

Le cœur de l’application est le microcontrôleur RZ-A1L présent sur la carte de développement, celui-ci devra être connecté à un module WiFi afin de rendre possible la communication sans fil. Grâce à ce module, le RZ-A1L 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 Wifi et la carte de développement. Quant au driver, il servira à adapter la partie hardware avec le software.

*Présentation des éléments du système*

p((. Carte RZ-A1L

La carte utilisée pour la réalisation du projet sera la carte RZ-A1L. Elle est fabriquée par la société Renesas. Elle est disponible pour le moment que chez Renesas car il s'agit de la dernière famille de microcontrôleur de Renesas. Le cœur de cette carte et un microcontrôleur de type ARM Cortex A9.

p=. !https://forge.clermont-universite.fr/attachments/download/15961/carte_rz-A1_20150523093323_20150523093439.jpg!

*Microcontrôleur RZ-A1L*

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

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

p((((. Calculs sur 32bits

Fréquence max 400MHz

Nombreux bus de communication

Ethernet Mac (100Mbps)

p=. !https://forge.clermont-universite.fr/attachments/download/15963/p13b04_schemaRZ_20150523094508_20150523094521.png!

L'avantage de ce microcontrôleur dans notre projet est son interface avec une carte SD. Cela va nous permettre de communiquer avec le module wifi choisi avec le client.

*Module Wifi Murata SN8000*

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

Module murata

p=. !https://forge.clermont-universite.fr/attachments/download/15964/Murata_SN800_20150523095522_20150523095632.png!

Ce module possède les caractéristiques suivantes :

p((. Norme wifi 2.4GHz IEEE 802.11b/g/n

Mode AP & STA dual mode (routeur ou non)

Data Rate WLAN 11, 54, 64 Mbps

Modes de sécurité WPA/WPA2-PSK, WEP et TKIP

Interface hôte : SDIO/SPI

Sans pile TCP/IP

p=. !https://forge.clermont-universite.fr/attachments/download/15965/Murata_block_20150523095522_20150523095548.png!

Ce module a ete choisi car il peut communiquer en SDIO (carte SD). Il s'agit d'une volonté du client de pouvoir insérer le moduel wifi comme une carte SD.

---

p=. *Problématiques*

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

p((. Connexion du module WiFi à la carte RZ-A1L par l'intermédiaire du port SD. Il faut donc réaliser une carte adaptation. Le client veut par ailleurs une carte de très bonne qualité afin de pouvoir se servir de cette carte sur d'autre plateforme Renesas.

p((. Porter le projet de Webserveur présent en ethernet en wifi sur la carte RZ-A1L.

p((. Réaliser un démonstrateur utilisable par les ingénieurs Renesas pour montrer les capacités de la carte. Exemple contrôler des I/O de la carte par internet.

p=. *Gestion de projet*

*Cahier des charges*

p((. Microprocesseur RZA1L sur plateforme

Webserveur Ethernet existant

Portage du webserveur en WiFi

Utilisation de ressources gratuites (outils de développement et de conception)

p=. !https://forge.clermont-universite.fr/attachments/download/15966/cahier_des_charges_20160105165211_20160105165309.png!

*WBS*

Pour mener à bien notre projet nous avons choisi de séparer les tâches à réaliser de cette façon.

p=. !https://forge.clermont-universite.fr/attachments/download/15967/WBS_20160105171210_20160105171230.png!

---

p=. *Développement*

*CAO Interface SDIO*

Le client souhaite interfacer le module Wifi avec le port SD de la carte de développement (RZA1L). Pour ce faire, il faut donc communiquer avec le module en mode SDIO. 

p=. !https://forge.clermont-universite.fr/attachments/download/15968/isis_20160104101948_20160104102013.png!

p=. !https://forge.clermont-universite.fr/attachments/download/15969/cao_20160104101707_20160104101728.png!

*Module SN8000*

Le module Wifi SN8000 de Murata peut être interfacé soit en SDIO (en passant par une carte SD) soit par SPI. Le cahier des charges initial imposé de communiqué en SDIO, car ce mode permet d'atteindre un débit beaucoup plus important qu'avec la SPI. Comme vu précédemment, nous avons réaliser une CAO permettant d'interfacer ce module avec ce mode. Comme nous n'avons pas eu la possibilité d'imprimer cette carte, nous avons dû utiliser les cartes en mode SPI pour communiquer. Nous allons donc voir le développement SPI de ce module.

"Datasheet BCM43362":https://forge.clermont-universite.fr/attachments/download/15970/MMP43362-DS101-R.pdf

Le protocole SPI de ce module supporte une communication par mots de 16 bits ou 32 bits. Il peut supporter aussi une communication en mode Big Endian ou Little Indian. Cependant, il faut faire très attention, car le module par défaut est en mode *16 bits Little Indian.*

Nous avons donc différentes trames de communication possible.

p=. !https://forge.clermont-universite.fr/attachments/download/15971/Trames_20151215094949_20151215095008.png!

+Établir la communication SPI avec le module:+

Pour communiquer avec le module Wifi, il faut suivre une procédure décrite dans la datasheet. Il faut après la mise en reset du module Wifi respecter des temps d'attentes. Après un certain temps, nous pouvons lire en polling l'adresse 0x14 du module. Cette adresse est accessible uniquement en lecture et contient un pattern prédéfini sur 32 bits (32'hFEEDB EAD). Si nous arrivons à le lire, cela permet de dire que la communication SPI est fonctionnelle.

La procédure de démarrage à respecter est la suivante:

p=. !https://forge.clermont-universite.fr/attachments/download/15972/boot_20151215100228_20151215100242.png!

Il faut donc après la mise en reset attendre au moins 3ms avant de commencer à envoyer la trame de lecture. Le module par défaut est en mode 16 bit et little indian. Nous allons détailler maintenant quelques fonctions que nous avons réalisées pour le configurer le module.

La structure d'une trame de commande pour le module SN8000 est la suivante:

p=. !https://forge.clermont-universite.fr/attachments/download/15973/commande_20151231104700_20151231104711.png!

+Les fonctions de base pour le module:+

Nous avons développé trois fonctions pour le module. Une pour lire le pattern de test et une pour écrire dans un pattern. Ces deux fonctions ont pour but de vérifier que la communication SPI est fonctionnelle. Enfin, une dernière fonction qui permet d'aller modifier des paramètres dans le registre de configuration du module.

Dans un premier temps la fonction qui permet de lire le Pattern de test:

p=. !https://forge.clermont-universite.fr/attachments/download/15974/read_pattern_20160105183208_20160105183350.png!

Nous allons donc lire de l'adresse 0x0014 à 0X0017 un pattern enregistré dans la puce du module. Le pattern que nous devons retrouver est le suivant:*0XFEEDBEAD*

La fonction write Pattern permet elle d'écrire dans un registre prévu à cet effet et ensuite de relire ce que nous avons écrit afin de vérifier la communication.

p=. !https://forge.clermont-universite.fr/attachments/download/15975/write_pattern_20160105183208_20160105183432.png!

Ici, nous écrivons *0xAABBCCDD* dans un registre et nous relisons ensuite ce même registre. Si nous relisons la bonne valeur, nous pouvons valider la communication.

Enfin, la dernière fonction que nous avons écrite permet d'écrire dans le registre de configuration. Voici ce que propose ce registre:

p=. !https://forge.clermont-universite.fr/attachments/download/15976/configuration_20151231110840_20151231110851.png!

Par exemple, il est intéressant de mettre le module en mot de 32 bits, car c'est plus facile d'écrire les trames ensuite. Ce registre permet surtout une fois que notre communication SPI est fonctionnelle de réveiller complètement notre module. Ainsi, il faut mettre son *bit 7* à 1 pour réveiller le module et démarrer son oscillateur et la PLL dont il a besoin pour échanger des données.

Une fois que le module est réveillé, la partie bas niveau est terminée. Il faut ensuite utiliser la stack de *Broadcom* pour échanger des données avec le module *WiFi.*

*WICED Wi-Fi SDK Broadcom*

WICED pour Wireless Internet Connectivity for Embedded Devices est une surcouche de haut niveau qui permet de créer des applications réseau embarquées en utilisant les puces Broadcoam. Il s'agit d'une librairie optimisée qui contient tous les drivers WIFI nécessaires pour fonctionner avec les puces. Dans notre cas, nous utilisons une puce *Broadcom 43362.*

Il est donc indispensable d'utiliser Wiced SDK *WiFi* de broadcom pour utiliser les fonctions avancées du module *WiFi*. Pour pouvoir ajouter le module *WiFi* à la librairie, il est nécessaire d'ajouter des fichiers à la librairie.

Premièrement, il existe un dossier *Platform* qui contient tous les fichiers sources et header des microcontrôleurs disponibles. Il faut donc rajouter les fichiers nécessaires au fonctionnement du RZA1L. 

p<. !https://forge.clermont-universite.fr/attachments/download/15977/platform_20160101154631_20160101154642.png!

Le RZA1L possède un cortex A9, il faut donc rajouter un dossier que nous appelleront *ARM_CA9* qui permet de faire fonctionner le cortex A9 (définitions de macros, mapping des interruptions, etc.). Ensuite, nous ajoutons RZA1L dans le sous-dossier *MCU* avec de nombreux fichiers sources et des headers nécessaires au fonctionnement du microcontrôleur. Nous parlerons en particulier d'un fichier très important que l'on doit nommer *wwd_SPI.c.* Il s'agit d'un fichier qui permet de définir les fonctions SPI que la librairie WICED va utiliser pour envoyer des trames au module. C'est donc dans ce fichier que nous devons adapter nos fonctions SPI (bas niveau) que nous avons développées précédemment. (L'ensemble des fichiers à rajouter à la stack Wiced pour le RZA1L est compressé et disponible dans la partie Document.)

Dans ce fichier wwd_SPI.c, il y a deux fonctions essentielles à créer.

La fonction d'initialisation qui va venir paramétrer la spi de notre microcontrôleur pour fonctionner correctement avec le module wifi.

!https://forge.clermont-universite.fr/attachments/download/15978/init_20160105181805_20160105181821.png!

La SPI est initialisée au début avec un bit rate de 11,11Mbit/s, avec des mots de 8 bits. Nous configurons aussi dans cette fonction, les différents pins liés à la communication (MOSI,MISO,CS,RST...)

La fonction la plus importante à tester est la fonction host_platform_spi_transfer qui va utiliser les routines bas niveau de SPI précédemment élaboré avec le RZA1L pour envoyer les trames au module.

!https://forge.clermont-universite.fr/attachments/download/15979/spi_transfert_20160105181620_20160105181654.png!

Ensuite, pour valider notre implémentation SPI dans la stack Wiced nous avons testé si nous pouvions initialiser le module Wifi et lire son pattern de TEST avec les fonctions de wiced.

Nous n'allons pas détailler tout le code pour faire cela, mais juste les fonctions principales à utiliser. Le code complet est disponible dans la section Documents.

Une fois le RZA1L intégré avec Wiced il faut donc utiliser la fonction *wwd_management_wifi_on( )* qui va appeler plusieurs fonctions:

*host_platform_bus_init( )* qui va venir initialiser la spi et les pins.

*wwd_bus_init( )* qui est une fonction qui test le pattern du module wifi en se servant donc de la fonction host_platform_spi_transfer. Cette fonction change aussi le registre de configuration du module wifi pour le configurer en mots de 32bits et en BIG ENDIAN. Car les trames de Wiced pour des fonctions plus avancées sont formatées de cette façon. Une fois appelée cette fonction nous arrivons bien à lire le pattern ce qui permet de démontrer que notre implémentation du RZA1L avec la stack est fonctionnel.

*CycloneTCP*

*CycloneTCP* est une stack TCP/IP d'une société grenobloise que nous devons utiliser pour notre projet. Il s'agit d'une double stack TCP/IP supportant l'IPV4 et l'IPV6.

!https://forge.clermont-universite.fr/attachments/download/15980/tcp_ip_20160105185406_20160105185425.png!

Cette stack TCP/IP est déjà intégré pour le RZA1L et il existe un driver Ethernet pour faire fonctionner une demo Web serveur. Notre problématique dans notre projet était de porter cette démo en changeant l'interface de communication. (passer de l'Ethernet en WiFi). Le travail à réaliser consisté donc à créer un driver pour faire fonctionner la stack Wiced et "CycloneTCP":https://www.oryx-embedded.com/products/CycloneTCP. Cependant, par manque de temps cette partie n'a pas pu être réalisée. De plus, il n'existe aucun exemple de driver WiFi pour Cyclone TCP afin de savoir comment on fait ou pour avoir des pistes d'études. Nous avons contacté l'entreprise pour avoir plus d'information et il existe un driver WiFi pour une cible microchip, mais le code n'étant pas open source nous n'avons pas pu l'obtenir pour voir à quoi ça ressemblé.

*Page web*

Pour la partie webserveur, nous avons crée notre propre page en HTML et CSS. Le but de la création de cette page web est le contrôle des entrées et sorties. Donc comme nous pouvons le voir sur la page ci-dessous, on a créé deux boutons. A partir de ces boutons, on peut faire clignoter la « userLED » de la carte RZ/A1L.

Pour faire cela, nous utilisons les requêtes XHTML. Du côté client, les requêtes sont en Javascript et du côté serveur nous avons des routines de réception XHR. La communication se passe comme suit : le client envoie une requête concernant un fichier.xml. Ce fichier est inexistant dans le serveur et ce dernier réagit en faisant appel aux routines de fallback. Ces routines sont appelées lorsque le serveur ne trouve pas une page demandée. Grâce à ses routines de fallback, nous pouvons codées des actions en C. 

!https://forge.clermont-universite.fr/attachments/download/15981/pageweb_20160114094455_20160114095219.png!

Dans notre cas, un clic sur un bouton de la page web envoie une requête demandant un fichier « led.xml ». Ce fichier demeurant introuvable par le serveur qui fait appel à la routine fallback dans laquelle nous avons codé les actions allumer et éteindre la led.

!https://forge.clermont-universite.fr/attachments/download/15982/request_20160114094455_20160114094525.png!

---

p=.  *Bilan*

*Etat d'avancement*

Notre Projet n'a pas rempli entièrement tous les points du cahier des charges suite à certains problèmes techniques qui sont survenus.

- Nous avons fait imprimer des cartes adaptation en SPI du module wifi avec la carte RZA1L à la demande du client (hors cahier des charges). Nous lui avons envoyé soudé et tester le plus rapidement possible.

- Nous avons élaboré une carte d'adaptation du module Wifi SN8000 pour le RZA1L avec une interface SD. Nous n'avons malheureusement pas pu les faire imprimer pour cause de budget, mais la CAO est entièrement finie.

- Nous avons donc dû changer notre stratégie de développement et nous avons utilisé une carte avec interface SPI que nous avions tiré pour le client. Nous avons donc développé le driver SPI pour utiliser le module WIFI et nous l'avons intégré à la stack WICED de Broadcom.

- La partie avec "CycloneTCP":http://www.oryx-embedded.com/cyclone_tcp.html n'a malheureusement pas était effectué.

*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. Les outils étant assez pointu et nouveau nous n'avions pas forcement assez de recul pour identifier les points les plus durs. Cependant, même si le web serveur n'est encore pas fonctionnel nous sommes satisfaits du boulot accompli. Nous avons su nous adapter au problème de budget qui ne nous a pas permis de réaliser la carte SD, en utilisant la carte SPI en notre possession. Concernant, cette carte (PMOD SPI) tout l'aspect drivers à pu être terminé et intégré avec Wiced ce dont nous sommes très satisfaits.

Nous remercions Renesas pour nous avoir proposé ce projet qui fut très formateur, car ce sont des outils qui nous étaient inconnus notamment le développement de driver et l'utilisation d'une cible 32 bits.

---

p=. *Documents*

Soutenance de Projet ge5a : diapo.pdf?

Poster Ge5a? : "poster":https://forge.clermont-universite.fr/attachments/download/15985/poster.pdf

Archives contenant les codes sources des programmes : code

Projet SDIO Part 1

Projet SDIO Part 2

Projet SPI Part 1

Projet SPI Part 2

Archives contenant la C.A.O. : cao