Le navigateur aux commandes de l’Arduino

Seconde partie

Hervé Troadec

Il existe actuellement, et sauf erreur, trois grandes familles de smartphones, tournant respectivement sous Androïd, iOS et Windows Mobile. Si vous envisagez d’utiliser l’un ou l’autre pour créer une télécommande WiFi « universelle », permettant à la fois le pilotage à distance et la télémétrie, il va vous falloir développer des programmes sur chacune de ces trois plates-formes, ce qui va vous imposer d’une part d’en disposer « physiquement », ce qui a un coût financier non négligeable, et d’autre part d’acquérir les compétences informatiques nécessaires à ce développement pour chacune d’entre elles, et là, bien que cette approche ne soit pas dénuée d’intérêt, c’est votre temps libre qui risque d’être fortement impacté.

Or, il existe un standard d’affichage et de programmation commun à ces trois plates-formes que vous utilisez quotidiennement par l’intermédiaire de votre navigateur : le HTML et ses deux compères que sont le CSS et le JavaScript.

Je vous propose, dans cette seconde partie, de mettre en place les techniques permettant de contourner, dans une certaine mesure, les limitations de notre serveur liées à la capacité limitée des mémoires de l’Arduino UNO, en séparant le logiciel serveur (le sketch) des données qu’il devra servir, comme les fichiers HTML, CSS, JavaScript ou autres. Nous utiliserons pour cela les possibilités que nous offre la présence sur le shield Ethernet d’un lecteur de carte microSD, et nous illustrerons ces nouvelles fonctionnalités en utilisant un fichier HTML et un fichier CSS.

Nous verrons dans la troisième partie comment éviter de recharger l’ensemble de la page lors des mises à jour, en utilisant les fonctionnalités que nous propose JavaScript avec AJAX et JSON, afin d’améliorer le concept en ce qui concerne l’aspect technique.

Commentez

- Titre : Le navigateur aux commandes de l’Arduino

- Auteur : Hervé Troadec

- Parution : 14 mars 2020

- Public visé :

- Licence : Le contenu de cet article est rédigé par Hervé Troadec et est mis à disposition selon les termes de la Licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 non transposé. Les logos Developpez.com, en-tête, pied de page, css, et look & feel de l'article sont Copyright ® 2013 Developpez.com.

Sommaire

- I. Avant propos

- II. CSS (Cascading Style Sheets)

- II-A. Introduction

- II-B. Principe de base

- II-C. Mise en œuvre

- III. Utilisation des fichiers sur notre serveur

- III-A. Lecture d’une carte microSD

- III-B. Arduino serveur de fichier HTML

- III-C. Arduino serveur de fichier CSS

- III-D. Récapitulation

- IV. Conclusion

- V. Remerciements

I - Avant propos

La rédaction de cet article assume que vous avez connaissance des matériels utilisés et des mécanismes détaillés dans la première partie. Il serait donc préférable que vous l’ayez lue avant d’entamer la lecture de cette seconde partie, car je serai amené à y faire référence à plusieurs reprises.

Comme nous avons abordé le HTML dans la première partie, nous allons ici aborder le CSS, ce qui va nous permettre à la fois de disposer de deux fichiers (HTML et CSS) pour détailler le mécanisme que nous allons mettre en place et d’effleurer les principes du CSS dont l’utilisation vous permettra d’améliorer la présentation de votre télécommande, encore qu’à ce sujet, je ne fasse que vous ouvrir le couvercle de la boîte à outils, tant mes compétences en matière d’esthétique sont limitées.

II - CSS (Cascading Style Sheets)

II-A - Introduction

À l’origine, le HTML n’était pas conçu pour permettre des présentations sophistiquées. Le but était simplement de donner accès, par l’intermédiaire d’un réseau, à des pages web (contenant de l’information sous forme de texte) stockées sur un serveur, en utilisant des liens hypertextes. Il s’agissait, en quelque sorte, d’un traitement de texte basique, augmenté de la capacité à gérer des hyperliens. Les balises, attributs et propriétés, peu nombreux, étaient à peu près cantonnés à la gestion de l’hypertexte, des titres, des paragraphes et des listes.

Cette situation n’a duré que relativement peu de temps, et, rapidement, ce langage s’est enrichi, offrant des fonctionnalités considérablement plus évoluées, comme on peut le constater en se promenant sur la toile. Ceci n’a, bien entendu, pas pu se faire sans entraîner la complexification de la structure du fichier HTML, rendant son élaboration et sa maintenance délicates. La solution à ce problème a été l’introduction du CSS ( Cascading Style Sheets ou Feuilles de Style en Cascade) qui a permis de séparer le contenu (l’information) de la mise en forme (la présentation).

II-B - Principe de base

« Le CSS, comment ça marche ? » dirait… l’autre, ou plutôt : à quoi ça sert ? Nous avons vu dans la première partie, lors de notre « approche » du HTML, l’utilisation de l’attribut « style » pour modifier, notamment, la couleur et la taille de la fonte. Cet attribut, mais il n’est pas le seul, sert à changer le comportement par défaut de la balise dans laquelle il est utilisé, avec pour objectif, dans la plupart des cas, d’améliorer la présentation. Cette utilisation « inline » a été la première possibilité de mise en forme des pages HTML. Malheureusement, la forme a, sinon pris le pas sur le contenu (encore que…), du moins pris une importance considérable dans la communication, rendant cette technique lourde et difficile à maintenir. C’est là que le CSS intervient.

Imaginons, par exemple, que vous vouliez fixer l’indentation (retrait de la première ligne) de tous les paragraphes de votre page à 30 pixels. Comme il s’agit d’un paragraphe, la balise impactée sera la balise <p>. L’attribut contenant la propriété que vous devez paramétrer, à savoir  text-indent , s’appelle  style . Vous devrez alors incorporer  style="text‑indent: 30px"  à chaque occurrence de la balise <p> de la manière suivante :

<p style="text-indent: 30px">Texte du paragraphe</p>

avec :

- <p> : la balise (tag) dont vous voulez modifier le comportement par défaut ;

- style  : l’un des attributs supportés par la balise <p>, mais le seul concerné par le CSS ;

- text-indent  : la propriété que l’on souhaite modifier ici ;

- 30px  : la nouvelle valeur de cette propriété.

Déjà, ça, en informatique on n’aime pas. Écrire de nombreuses fois la même ligne n’est pas très productif. Les « copier/coller », on sait faire, mais bon ! De plus, si d’aventure vous estimez que ce retrait est trop important ou pas assez, voire inutile, vous devrez faire autant de modifications qu’il y a de paragraphes. Ce n’est vraiment pas satisfaisant. Le CSS vous permet, avec la ligne suivante :

p {text-indent: 30px}

d’imposer à toutes les balises <p> ce formatage, et ce en une seule opération. Cette ligne pourra être placée :

- soit dans la partie « en-tête » du fichier HTML lui-même (c’est-à-dire avant la balise <body>), entre les balises <style> et </style> ;

- soit dans un fichier séparé ayant l’extension .css : dans ce cas, en supposant que votre fichier s’appelle « monfichier.css » et qu’il se trouve dans le même répertoire que votre fichier HTML, vous devrez l’invoquer dans l’en-tête du fichier HTML de la manière suivante :

<link rel="stylesheet" type="text/css" href="monfichier.css">

type="text/css" peut être omis dans la mesure où c’est la valeur par défaut quand rel="stylesheet". rel est obligatoire, ainsi que href évidemment.

Vous pouvez considérer la balise <link /> un peu comme une clause # include<>, car elle sert à lier un fichier extérieur à votre fichier HTML, la différence étant que son absence n’empêchera pas votre fichier HTML d’être fonctionnel, mais sans mise en forme.

Voici ce à quoi pourrait ressembler votre fichier HTML dans le premier cas :

<!doctype html>

<html lang="fr">

<meta charset="UTF-8" />
<title>Titre de la page</title>
<style>
p {text-indent: 30px}
</style>

<body>
<p>Paragraphe 1</p>
<p>Paragraphe 2</p>
</body>

</html>

Attention à ne pas confondre la balise <style> avec l’attribut  style . Bien que les deux soient utilisés dans le même but, leur manipulation est différente.

et dans le deuxième cas :

<!doctype html>

<html lang="fr">

<meta charset="UTF-8" />
<title>Titre de la page</title>
<link rel="stylesheet" type="text/css" href="monfichier.css">

<body>
<p>Paragraphe 1</p>
<p>Paragraphe 2</p>
</body>

</html>

pour le fichier HTML, accompagné du fichier CSS « monfichier.css » contenant :

monfichier.css

p
{
text-indent: 30px;
}

Le « ; » (point-virgule) situé en fin de ligne n’est nécessaire que pour séparer, quand il y en a plusieurs, les différentes propriétés que vous paramétrez. Vous pouvez l’omettre dans le cas où une seule propriété est paramétrée, comme c’est le cas ici, ou pour la dernière propriété de la liste, ce qui est également le cas ici.

En ce qui concerne le codage, ces deux approches sont identiques. Le code contenu dans le fichier CSS est rigoureusement le même que le code écrit entre les balises <style> et </style>de votre fichier HTML.

Si votre application comporte un seul fichier HTML, ce qui en l’occurrence est notre cas, la première approche peut être privilégiée, surtout quand, comme ici, la mise en forme est très basique. Je vous propose malgré tout d’utiliser la seconde approche qui, d’une part, se révèle assez rapidement plus judicieuse que la première, en séparant définitivement la forme du fond, mais va surtout, d’autre part, nous donner l’opportunité de créer un fichier CSS que le fichier HTML va devoir appeler, ce qui va nous permettre de détailler les mécanismes utilisés.

Vous pouvez même aller plus loin dans la modularité en dispatchant, selon des critères que vous jugeriez importants, votre code CSS entre plusieurs fichiers. Dans ce cas, vous devez appeler chacun de ces fichiers avec une balise <link /> spécifique.

II-C - Mise en œuvre

Appliquons ce que nous venons de voir au fichier HTML décrivant notre télécommande, vu dans la première partie :

<!DOCTYPE html>
<html lang="fr">
<meta charset="utf-8" />
<title>Télécommande</title>
<body>
<form method="get">
<p style="font-size: 5em">Cliquez sur un bouton</p>
<input style="font-size: 10em" type="submit" value="ON" name="on" />
<input style="font-size: 10em" type="submit" value="OFF" name="off" />
</form>
<p style="color: rgb(125,0,0); font-size: 5em">LED éteinte</p>
</body>
</html>

Le code tel que je vous le livre ici ne respecte pas la « bonne pratique » en ce qui concerne la clarté de son écriture, à la fois trop compacte et dénuée d’indentation. La raison de ce choix réside en ce que ce code est, pour l’instant, destiné à être inclus au sketch et que, dès lors, son impact sur la mémoire de l’Arduino n’est pas négligeable, tant s’en faut. Or, il faut savoir que chaque saut de ligne ajoute un caractère à l’ensemble, ainsi que chaque « cran » d’indentation.

J’aurais pu, pour aller au bout du raisonnement, supprimer un certain nombre de lignes qui ne sont pas nécessaires à son fonctionnement et mettre le tout sur une même ligne, mais je voulais malgré tout fournir un code syntaxiquement correct et un minimum lisible.

En utilisant la technique intégrant le CSS au fichier HTML, voici ce que nous obtenons :

<!DOCTYPE html>
<html lang="fr">
<meta charset="utf-8" />
<title>Télécommande</title>
<style>
input{font-size: 10em}
.titre{font-size: 5em}
.retour{color: rgb(125,0,0); font-size: 5em}
</style>
<body>
<form  method="get">
<p class="titre">Cliquez sur un bouton</p>
<input type="submit" value="ON" name="on" />
<input  type="submit" value="OFF" name="off" />
</form>
<p class="retour">LED éteinte</p>
</body>
</html>

La technique utilisant un fichier CSS externe nous donne :

- pour le fichier HTML :

<!DOCTYPE html>
<html lang="fr">
<meta charset="utf-8" />
<title>Télécommande</title>
<link rel="stylesheet" type="text/css" href="monfichier.css">
<body>
<form  method="get">
<p class="titre">Cliquez sur un bouton</p>
<input type="submit" value="ON" name="on" />
<input type="submit" value="OFF" name="off" />
</form>
<p class="retour">LED éteinte</p>
</body>
</html>

- et pour le fichier CSS :

input{font-size: 10em}
.titre{font-size: 5em}
.retour{color: rgb(125,0,0); font-size: 5em}

Le fonctionnement est rigoureusement le même pour le CSS intégré au fichier HTML et pour le CSS placé dans un fichier externe. Comme nous utiliserons le fichier CSS externe, je ne décrirai que le code correspondant à cette technique.

Essayons d’analyser ce code.

Le CSS ne s’occupe que du style. Prenons, par exemple, le cas de la première balise <input>. La ligne HTML originale correspondant à cette balise est :

<input style="font-size: 10em" type="submit" value="ON" name="on" />

Seule la partie style="font-size: 10em" sera concernée par le fichier CSS. Comment écrire cela en CSS ? C’est très simple :

- le nom de la balise à paramétrer, ici <input>, apparaîtra en début de ligne (pour faire simple, mais ce n’est pas obligatoire) ;

- les propriétés à paramétrer (ici, il n’y en a qu’une) seront placées après, les unes à la suite des autres, sur une même ligne ou sur des lignes successives, séparées par des points-virgules ( ; ), encadrées par des accolades ( {} ).

Nous obtenons la ligne suivante dans le fichier CSS :

input{font-size: 10em}

ou, comme je préfère l’écrire (mais c’est personnel) :

input
{
font-size: 10em;
}

Comme dit plus haut, seul l’attribut style est concerné : les autres attributs, type, value et name, resteront inline, car ils ne sont pas gérés par le CSS. La ligne originale deviendra :

<input type="submit" value="ON" name="on" />

La seconde utilisation de la balise <input> suivra le même processus, mis à part le paramétrage de sa propriété font-size qui, du coup, est déjà fait. On commence à voir là l’intérêt du système.

<input type="submit" value="OFF" name="off" />

Voyons maintenant le cas de la balise <p>. Le code inline de la première occurrence de cette balise est le suivant :

<p style="font-size: 5em">Cliquez sur un bouton</p>

En utilisant le même mécanisme que ci-dessus, nous obtenons :

<p>Cliquez sur un bouton</p>

pour la partie HTML, et :

P
{
font-size: 5em;
}

pour la partie CSS. Jusque-là, tout va bien. Par contre, en abordant le second paragraphe, ça se gâte. En effet, si la partie HTML ne pose pas de problème, notre code HTML inline :

<p style="color: rgb(125,0,0); font-size: 5em">LED éteinte</p>

devenant :

<p>LED éteinte</p>

le code CSS devient quant à lui :

P
{
color: rgb(125,0,0);
font-size: 5em;
}

ce qui fait que, dans notre fichier CSS, nous aurons deux paramétrages différents pour un même élément, à savoir :

P
{
font-size: 5em;
}

P
{
color: rgb(125,0,0);
font-size: 5em;
}

Ce qui fait que, comme c’est généralement (toujours ?) le cas en programmation, seul le dernier paramétrage sera pris en compte, et donc que l’affichage de ces deux paragraphes sera identique, du moins au niveau de « la forme ». Le texte, à savoir « le fond », restera quant à lui conforme à ce qui a été codé.

Bien évidemment, vous vous en doutez, une solution existe.

On pourrait envisager de réutiliser la technique inline pour caractériser les nouveaux paragraphes, mais, outre le fait qu’on se retrouverait en butte aux problèmes évoqués plus haut liés à cette technique, on mélangerait deux méthodes de mise en forme ce qui n’est pas souhaitable.

Le CSS offre deux solutions :

- l’attribut classqui permet de définir un ensemble de caractéristiques et de les appliquer à un nombre quelconque de balises ;

- l’attribut id qui permet également de définir un ensemble de caractéristiques, mais ne permet de les appliquer qu’à une seule balise.

Le fonctionnement de ces deux attributs est identique. Nous pourrions ici utiliser indifféremment l’un ou l’autre, le résultat serait le même, mais c’est à éviter absolument. L’attribut id ne doit être utilisé que dans le cas d’un traitement particulier effectué sur une seule balise. Il sert à identifier de façon univoque cette balise. Nous aurons l’occasion de revenir plus tard sur cet attribut.

L’attribut class va nous permettre de sélectionner un groupe de balises, identiques ou non, et de leur affecter un paramétrage commun.

Ce paramétrage doit avoir un nom permettant de l’invoquer depuis les balises auxquelles il est destiné. On réalise cela dans le fichier CSS, et ce peut être comparé à la déclaration d’une fonction. Le mot réservé est… « . » (le point) et il doit être suivi immédiatement du nom que vous souhaitez lui donner. Ce nom doit impérativement commencer par une lettre (majuscule ou minuscule) et ne peut comporter que des lettres, des chiffres, ainsi que les caractères « - » et « _ ». Dans notre cas, nous avons deux paramétrages distincts à créer et je vous propose de le faire en saisissant ce qui suit dans votre fichier CSS :

.titre
{
font-size: 5em;
}

.retour
{
color: rgb(125,0,0);
font-size: 5em;
}

Il ne doit pas y avoir d’espace entre la valeur et l’unité dans laquelle elle est exprimée. Le code suivant est correct :

font-size: 5em;
text-indent: 30px;

alors que celui-là ne l’est pas :

font-size: 5 em;
text-indent: 30 px;

Nous venons donc de déclarer les « classes » .titre et .retour : elles reprennent simplement les paramétrages effectués plus haut. Je mets « classes » entre guillemets, car il ne faut pas confondre avec les classes utilisées en programmation objet. Cette appellation est pratique, car elle établit un lien euphonique avec l’attribut class correspondant.

Mais ce n’est pas fini. Il faut maintenant indiquer à chacune des deux balises <p> la « classe » qu’elle doit utiliser. Pour ce faire, nous utiliserons l’attribut class dans le code HTML de la façon suivante, pour utiliser ces deux « classes » comme il se doit :

<p class="titre">Cliquez sur un bouton</p>

et

<p class="retour">LED éteinte</p>

Voilà pour le principe « général » d’utilisation des « classes ». Je dis « général » car on est loin d’en avoir fait le tour, mais pour l’utilisation que l’on va en faire, c’est suffisant. Il ne s’agit pas ici d’un tutoriel sur le CSS et je ne décris que ce qui nous est utile.

Pour ceux qui souhaitent aller plus loin en ce qui concerne le CSS, deux adresses :

- developpez.com ;

- w3schools.com.

Nous venons donc de voir, dans les grandes lignes, la façon de passer du code de mise en forme inline au fichier CSS équivalent. Comment allons-nous utiliser ce fichier avec notre « serveur » Arduino ?

III - Utilisation des fichiers sur notre serveur

Dans la première partie, tout se trouvait inclus dans le sketch Arduino, à savoir le logiciel serveur, le fichier HTML avec sa mise en forme inline, l’équivalent PHP pour traiter les commandes envoyées par le client, le traitement des données issues du capteur… Bref ! Une usine à gaz (enfin, au moins un petit briquet).

Dans tout ce fatras, le « fichier » HTML avec tout ce qu’il contient fait tache. Il ne fait pas partie du programme exécuté par l’Arduino : ce n’est techniquement que du texte qui va être envoyé tel quel au client (le navigateur) qui, lui, va se charger de l’interpréter pour afficher la télécommande à l’écran. De plus, ce code HTML va, à terme, devoir intégrer du CSS et du JavaScript. Ce texte prend de la place, que ce soit en RAM ou en mémoire flash, ce qui va rapidement limiter les possibilités théoriques du dispositif. La simplicité de notre exemple d’application autorise bien sûr cette pratique, la première partie le démontre, mais, du moins je le souhaite, vos ambitions seront plus vastes que celles de ce tutoriel, et il serait dommage de les brider si on peut faire autrement. Cela dit, il ne faut pas rêver : il y aura quand même des limites.

Le système Arduino est riche en possibilités et, entre autres choses, il permet, muni du dispositif ad hoc, de lire et d’écrire des fichiers en utilisant une mémoire de masse « universelle » : la carte SD (ou microSD).

Comble de chance, le shield Ethernet que nous avons utilisé pour réaliser notre serveur possède un lecteur de cartes microSD. Quel heureux hasard ! Mais est-ce bien un hasard ? Assurément non. Un serveur digne de ce nom, fût-il à base d’Arduino, nécessite une mémoire de masse, à défaut de quoi il devra se contenter d’un succès d’estime.

Nous allons donc, avant de poursuivre, jeter un coup d’œil sur l’utilisation de ce lecteur de carte.

III-A - Lecture d’une carte microSD

Sur le plan matériel, tout le monde sait ce qu’est une carte microSD : il est donc inutile de s’étendre là-dessus. Je pense également que vous n’aurez pas de problème pour trouver l’endroit qui lui est réservé sur le shield Ethernet.

La carte microSD devra être formatée en Fat16 ou en Fat32 (formatage généralement déjà réalisé sur les cartes du commerce), à défaut de quoi elle ne sera pas reconnue par le lecteur, ou plutôt par la bibliothèque dont on va se servir. Il est impératif également que votre système de développement (PC, portable ou autre) dispose d’un lecteur de carte microSD, soit intégré, soit sous forme d’un adaptateur externe, car vous aurez à écrire des fichiers sur cette carte.

Pour utiliser le lecteur intégré à votre shield Ethernet, l’environnement Arduino vous offre, en standard la bibliothèque SD. Il s’agit d’une version édulcorée de la bibliothèque SdFatLib développée par Bill Greiman, que vous pouvez télécharger ici. Elle fonctionnera dans la plupart des cas, mais je vous conseillerais malgré tout d’utiliser la bibliothèque originale : elle est plus rapide, offre plus de fonctions, permet l’ouverture de plusieurs fichiers simultanément, et, surtout, elle autorise les noms de fichier longs. Si, un jour, vous deviez utiliser une bibliothèque de fichiers fournie par un tiers, il y a peu de chance pour que ceux-ci respectent l’ancien standard 8.3 de Windows®.

Je vous propose, dans un premier temps, de vous montrer comment lire un fichier présent sur une carte microSD, pour en afficher le contenu sur le moniteur série. Il est donc nécessaire, avant tout, d’écrire un fichier sur cette carte. N’importe quel fichier texte ferait l’affaire, mais autant prendre immédiatement un fichier en relation avec notre tutoriel.

Reprenons l’exemple vu plus haut :

lecture-sd.html

1. <!DOCTYPE html>

3. <html lang="fr">

5. <head> <!-- La balise <head> peut être omise en HTML5 -->

6. <meta charset="utf-8" />

7. <title>Télécommande</title>

8. <style>

9. input{font-size: 10em}

10. .titre{font-size: 5em}

11. .retour{color: rgb(125,0,0); font-size: 5em}

12. </style>

13. </head>

15. <body>

16. <form  method="get">

17. <p class="titre">Cliquez sur un bouton</p>

18. <input type="submit" value="ON" name="on" />

19. <input  type="submit" value="OFF" name="off" />

20. </form>

21. <p class="retour">LED éteinte</p>

22. </body>

24. </html>

Comme vous pouvez le constater, j’ai légèrement remanié ce code pour le rendre plus lisible, notamment en ajoutant les indentations. Je peux à présent le faire sans soucis, car ce code ne sera plus intégré au sketch Arduino, et donc, la place qu’il occupe ne sera plus un problème.

Pour rester cohérent avec ce qui a été dit à ce sujet, nous ne prendrons pas le code utilisant le CSS inline. Toutefois, comme il est préférable d’aborder le problème avec un seul fichier, nous utiliserons pour l’instant le code HTML avec le CSS intégré dans l’entête.

Téléchargez ce fichier et copiez-le sur votre carte microSD. Insérez à présent cette carte dans le logement adéquat se trouvant sur votre shield Ethernet : vous êtes « matériellement » prêt pour la lecture de la carte microSD.

Matériellement seulement, car il vous faut le sketch qui va avec. Voici donc le sketch en question :

lecture-sd.ino

1. /*

2. CONDITIONS MATÉRIELLES:

3. Arduino UNO rev3 / Shield Ethernet 2

4. SPI SD: SS = 4

5. Carte microSD HC 4Gio

6. IDE 1.8.5

8. OBJECTIF:

9. Lire le contenu du fichier "lecture_sd.html" depuis la carte micro SD pour l'afficher

10. dans le terminal série

11. */

13. #include <SPI.h>     // L'inclusion explicite de la bibliothèque SPI n'est pas nécessaire

14. #include <SdFat.h>   // Inclusion de la bibliothèque SdFat

15. SdFat SD;            // Création d’une instance de SdFat

17. //CONSTANTE

18. const int carteSD = 4; // Broche de sélection par défaut pour la communication SPI avec la carte SD

20. //INITIALISATIONS

21. void setup()

22. {

23. Serial.begin(115200);   // Penser à paramétrer le terminal série avec la même valeur

24. Serial.println("SETUP en cours ...");

25. File fichier;           // On instancie un objet "File" fourni par la bibliothèque SdFat

26. /* Initialisation de la carte SD */

27. Serial.println("Initialisation de la carte SD");

28. if (SD.begin(carteSD))  // Si la fonction d'initialisation renvoi TRUE,

29. {

30. Serial.println("Initialisation OK!");

31. }

32. else                    // sinon, message d'erreur et on quitte le SETUP

33. {

34. Serial.println("Initialisation impossible:\n\tAbandon du setup!");

35. return;  // Sort du setup

36. }

37. Serial.println("============================================");

38. if (SD.exists("lecture-sd.html"))                            // Si le fichier "lecture_sd.html"

39. {                                                            // existe, on l'ouvre en lecture puis

40. fichier = SD.open("lecture-sd.html", FILE_READ);           // on lit et on envoi son contenu,

41. Serial.println("Contenu du fichier 'lecture-sd.html'\n");  // caractère par caractère, vers le

42. while (fichier.available())                                // moniteur série pour l'afficher.

43. {

44. Serial.write(fichier.read());

45. }

46. fichier.close();

47. }

48. else  //Sinon message d'erreur et on quitte le SETUP

49. {

50. Serial.println("Acces impossible au fichier 'lecture-sd.html':\n\tAbandon du setup!");

51. return;  //Sort du setup

52. }

53. }

55. //PROGRAMME

56. void loop()

57. {

59. }

Le fonctionnement global du sketch est indiqué dans les commentaires. Je vais malgré tout préciser quelques lignes :

- #include <SPI.h>(ligne15) : l’inclusion de cette bibliothèque n’est pas nécessaire dans la mesure où la bibliothèque SdFat s’en charge déjà ;

- deux tests sont effectués :

- le premier, if (SD.begin(carteSD))(ligne 28) permet à la fois d’initialiser le lecteur de carte en utilisant la fonction begin(), de s’assurer que l’inscription du lecteur de carte microSD sur le bus SPI s’est bien passée et qu’une carte microSD valide est bien présente dans le slot ad hoc,

- le second, if (SD.exists("lecture-sd.html")(ligne 38) vérifie l’existence du fichier désiré avant d’effectuer une quelconque opération dessus ;

- fichier = SD.open("lecture-sd.html", FILE_READ);(ligne 40) : ouverture du fichier en lecture. Comme il s’agit du mode d’ouverture par défaut,FILE_READpeut être omis, contrairement àFILE_WRITE, par exemple, si l’on voulait l’ouvrir en écriture ;

- Serial.write(fichier.read())(ligne 44) : pour plus de clarté, cette ligne pourrait être décomposée comme suit :

1. char car = fichier.read();

2. Serial.write(car);

Cette technique de transfert de fichier caractère par caractère est simple d’emploi et fiable. Son inconvénient principal dans notre contexte est sa relative lenteur. Si, par la suite, vous comptez utiliser des frameworks CSS ou JavaScript, ou des images, pesant plusieurs centaines de kilooctets, sachez que c’est possible, mais que le temps de chargement ne sera pas négligeable.

Téléversez ce sketch puis ouvrez le moniteur série. Vous devriez obtenir ceci :

J’espère que vous n’espériez pas obtenir l’affichage de la page HTML, auquel cas vous devez être déçu. Le moniteur série n’est pas un navigateur et ne peut malheureusement afficher que du texte brut. C’est d’ailleurs tout ce qu’on lui demande.

Nous avons donc notre fichier HTML apparemment accessible : il est temps de voir de quelle manière le serveur va pouvoir le mettre à la disposition du client pour permettre à celui-ci d’afficher la page correspondante.

III-B - Arduino serveur de fichier HTML

Reprenons le sketch de base vu dans la première partie, destiné à établir une connexion fonctionnelle entre le serveur et le client :

1. #include <Ethernet.h>

3. byte macSerre[] = {0x90, 0xA2, 0xDA, 0x10, 0x4F, 0x25};

4. IPAddress IPSerre(192,168,1,200);

5. EthernetServer serveurHTTP(80);

7. void setup()

8. {

9. Ethernet.begin(macSerre, IPSerre);

10. serveurHTTP.begin();

11. Serial.begin(115200);

12. }

14. void loop()

15. {

16. EthernetClient client = serveurHTTP.available();

17. if (client)

18. {

19. if (client.connected())

20. {

21. String reception;

22. while (client.available())

23. {

24. char carLu = client.read();

25. if (carLu != 10)

26. {

27. reception += carLu;

28. }

29. else

30. {

31. break;

32. }

33. }

34. Serial.println(reception);

35. if (reception.startsWith("GET / HTTP/1.1"))

36. {

37. client.println(F("HTTP/1.1 200 OK"));

38. client.println(F("Content-Type: text/html"));

39. client.println(F("Connection: close"));

40. client.println();

41. }

42. client.stop();

43. }

44. }

45. }

Nous allons le modifier comme suit :

tuto.ino

1. #include <SdFat.h>

2. #include <Ethernet.h>

4. SdFat SD;

6. const int carteSD = 4;

8. byte macSerre[] = {0x90, 0xA2, 0xDA, 0x10, 0x4F, 0x25};

9. IPAddress IPSerre(192,168,1,200);

10. EthernetServer serveurHTTP(80);

12. void setup()

13. {

14. SD.begin(carteSD);

15. Ethernet.begin(macSerre, IPSerre);

16. serveurHTTP.begin();

17. Serial.begin(115200);

18. }

20. void loop()

21. {

22. EthernetClient client = serveurHTTP.available();

23. if (client)

24. {

25. if (client.connected())

26. {

27. String reception;

28. while (client.available())

29. {

30. char carLu = client.read();

31. if (carLu != 10)

32. {

33. reception += carLu;

34. }

35. else

36. {

37. break;

38. }

39. }

40. Serial.println(reception);

41. if (reception.startsWith("GET / HTTP/1.1"))

42. {

43. client.println(F("HTTP/1.1 200 OK"));

44. client.println(F("Content-Type: text/html"));

45. client.println(F("Connection: close"));

46. client.println();

47. if (SD.exists("lecture_sd_1.html"))

48. {

49. File fichier = SD.open("lecture_sd.html", FILE_READ);

50. while (fichier.available())

51. {

52. client.write(fichier.read());

53. }

54. fichier.close();

55. }

56. else

57. {

58. client.println(F("Fichier 'lecture_sd.html' introuvable..."));

59. }

60. }

61. client.stop();

62. }

63. }

64. }

Quelles sont les modifications effectuées ? Comme il s’agit essentiellement de la fusion du sketch serveur de base avec le sketch de lecture d’une carte microSD, lesquels ont été détaillés précédemment, je ne préciserai que deux points :

- #include <Ethernet.h>(ligne 2) : comme je l’ai mentionné dans la première partie, et à l’attention de ceux qui auraient fait l’impasse dessus, la bibliothèque Ethernet officielle a été mise à jour et gère, depuis sa version 2.0, les puces WIZnet® W5100, 5200 et 5500. La bibliothèque Ethernet2, écrite dans le but de gérer la puce W5500 qui équipe le shield Ethernet version 2 n’est donc plus nécessaire et le projet ne sera plus maintenu. D’ailleurs, le shield Ethernet version 1 n’est plus fabriqué par Arduino. Si ce n’est pas déjà fait, vous pouvez mettre à jour votre bibliothèque officielle en version 2.0 en passant par le menu « Outils » de votre EDI Arduino puis « Inclure une bibliothèque → Gérer les bibliothèques » ;

- à partir de la ligne 47 jusqu’à la ligne 59, j’utilise exactement le même code que celui permettant de lire le fichier « lecture_sd.html » présent sur la carte microSD et d’envoyer son contenu sur le moniteur série de l’EDI Arduino, à un petit détail prêt : la ligne Serial.write(fichier.read())devient client.write(fichier.read())pour acheminer le contenu du fichier non plus sur le terminal série, mais vers le client Ethernet, de même que les lignes :

Serial.println("Acces impossible au fichier 'lecture-sd.html':\n\tAbandon du setup!");
return;  //Sort du setup

- deviennent :

tuto.ino

client.println(F("Fichier 'lecture_sd.html' introuvable..."));

pour rediriger de la même manière le message d’erreur vers le client. Comme vous pouvez le constater, le mécanisme est rigoureusement identique et les écritures tout à fait cohérentes.

Téléversez ce sketch et connectez-vous au serveur : l’interface de votre télécommande doit s’afficher dans la fenêtre de votre navigateur.

Nous savons donc maintenant demander, depuis le client, une page web stockée sur la carte microSD, ce qui nous permet de nous affranchir totalement de la limite imposée par la faible capacité mémoire de l’Arduino UNO, du moins en ce qui concerne la taille du code HTML. Mais cela n’est pas gratuit. L’utilisation de la bibliothèque SdFat nous coûte à peu près 8,4 Kio de mémoire flash (emplacement du programme) et 840 octets de RAM (emplacement des données), ce qui veut dire que, tant que le volume des données stockées sur la carte microSD sera inférieur à approximativement 10 Kio, ce choix peut être discutable.

Pour info, j’ai déterminé ces valeurs avec le sketch minimum suivant :

Bon ! on s’est débarrassé de la partie HTML qui « encombrait » notre sketch, lequel est devenu, du coup, nettement plus lisible. Par contre, on a toujours du code CSS qui « encombre » notre code HTML.

Question : comment va-t-on faire pour utiliser du code CSS issu d’un autre fichier que celui contenant le code HTML ?

III-C - Arduino serveur de fichier CSS

Réponse : en utilisant exactement le même mécanisme !

Comme pour le chapitre précédent, si vous voulez « servir » un fichier CSS depuis la carte microSD, il est impératif que ce fichier se trouve sur cette carte. Que va contenir ce fichier : tout simplement le code CSS qui se trouve entre les balises <style> et </style>, à savoir :

tuto.css

1. input

2. {

3. font-size: 10em;

4. }

6. .titre

7. {

8. font-size: 5em;

9. }

11. .retour

12. {

13. color: rgb(125,0,0);

14. font-size: 5em;

15. }

Bien que j’ai fait remarquer plus haut que le point-virgule ( ; ) n’est nécessaire que quand il sépare le paramétrage de deux propriétés, je conseille de le mettre systématiquement. Cela limite d’une part le risque de l’oublier lors de la saisie elle-même et d’autre part le risque d’oublier de l’ajouter à l’ancienne dernière ligne, lors du rajout d’une ou de plusieurs lignes.

Je vous propose de copier le code ci-dessus dans un fichier appelé tuto.css, ou tout autre nom, si vous êtes sûr de ne pas vous mélanger les crayons, mais en conservant le suffixe .css naturellement (par principe, car ce n’est pas nécessaire).

Je suppose que vous avez deviné qu’il va vous falloir écrire ce fichier sur la carte microSD, mais ne vous précipitez pas. Pour utiliser ce fichier, il va falloir également modifier le fichier HTML. Celui-ci va, en effet, devoir appeler le fichier CSS pour pouvoir le charger, et la mise en forme intégrée à l’entête va pouvoir être supprimée, ce qui est le but.

Voici ce que ça va donner :

tuto.html

1. <!DOCTYPE html>

3. <html lang="fr">

5. <head> <!-- La balise <head> peut être omise en HTML5 -->

6. <meta charset="utf-8" />

7. <link rel="stylesheet" type="text/css" href="tuto.css">

8. <title>Télécommande</title>

9. </head>

11. <body>

12. <form  method="get">

13. <p class="titre">Cliquez sur un bouton</p>

14. <input type="submit" value="ON" name="on" />

15. <input  type="submit" value="OFF" name="off" />

16. </form>

17. <p class="retour">LED éteinte</p>

18. </body>

20. </html>

Copiez ce code dans un fichier que vous appellerez tuto.html pour rester cohérent avec tuto.css, et à présent, vous pouvez écrire les deux fichiers sur votre carte microSD. Conservez pour le moment le fichier lecture-sd.html.

Si vous êtes curieux, créez un dossier vide sur votre PC, placez-y le fichier tuto.html et ouvrez-le avec votre navigateur. Ajoutez dans le même dossier le fichier tuto.css et ouvrez à nouveau tuto.html. Comparez les affichages.

Vous noterez également que l’absence du fichier tuto.css ne déclenche pas d’erreur. La page web est simplement affichée sans mise en forme.

Insérez à présent la carte microSD dans le slot qui lui est réservé sur votre prototype, puis connectez-vous au serveur. Pas de chance ! votre navigateur n’affiche pas du tout ce que vous espériez, mais quelque chose comme ceci :

Ce message d’erreur révèle deux problèmes :

1. Le premier problème est d’ordre « mécanique ». En effet, comme vous n’avez pas modifié votre sketch, par ma faute puisque je ne vous l’ai pas demandé (ce qui engendre d’ailleurs le problème n°2), vous essayez toujours de vous connecter à la page correspondant au fichier lecture-sd.html. Comme je vous ai demandé, juste au-dessus, de conserver ce fichier, pourquoi est-il introuvable ? La raison en est simple. En enlevant la carte microSD pour ajouter les fichiers tuto.html et tuto.css depuis votre PC, vous avez déconnecté le lecteur de carte du bus SPI. Malheureusement, la bibliothèque SdFat ne gère pas la réinscription automatique du lecteur sur le bus SPI lors de la réinsertion de la carte microSD. Pour que celle-ci soit à nouveau reconnue, vous devez réinitialiser le lecteur en exécutant un SD.begin(carteSD);. Cette commande n’est accessible que depuis le setup(). Comme celui-ci n’est exécuté qu’une fois, au démarrage du sketch, vous devez soit « éteindre » votre carte Arduino puis la « rallumer », soit téléverser à nouveau le sketch, soit effectuer un reset de la carte à l’aide du bouton ad hoc. Je préconise bien sûr la troisième méthode ;

2. Le second problème, comme on vient de le voir, est qu’il faut modifier le sketch pour qu’il prenne en compte le nouveau fichier HTML. La modification est triviale, il vous suffit à priori de remplacer les occurrences de lecture-sd.htmlpar tuto.html.

Voici le fragment de code concerné par la modification :

tuto.ino

if (SD.exists("tuto.html"))
{
File fichier = SD.open("tuto.html", FILE_READ);
while (fichier.available())
{
client.write(fichier.read());
}
fichier.close();
}
else
{
client.println(F("Fichier 'tuto.html' introuvable..."));
}

Téléversez ce code et connectez-vous. Hélas, rien ne fonctionne aujourd’hui. Voilà ce que l’on obtient :

Bon ! La télécommande est bien là, c’est déjà ça, mais où est passée la mise en forme ? Je vous propose, pour le découvrir, d’aller voir du côté du moniteur série de votre EDI Arduino. Ouvrez donc ce moniteur et connectez-vous à nouveau. Vous devriez obtenir quelque chose qui ressemble à ça :

Décortiquons :

- la première ligne nous est familière. Il s’agit de la requête standard envoyée au serveur par le navigateur pour demander l’affichage de notre télécommande. Pour plus de détails à ce sujet, voir le chapitre IV-B-2. Connexion fonctionnelle dans la première partie ;

- vient ensuite la ligne GET /tuto.css HTTP/1.1 : que signifie cette ligne ? Lors du chargement de la page par le navigateur, celui-ci interprète le code HTML ligne par ligne. Il arrive à un moment sur la ligne contenant l’instruction <link rel="stylesheet" type="text/css" href="tuto.css"> . Cette instruction peut être comparée à l’instruction #include <lib.h> que vous utilisez dans vos sketches pour utiliser du code contenu dans un fichier externe (une bibliothèque par exemple). Elle demande au navigateur de charger le fichier tuto.css dont le contenu va, en quelque sorte, être ajouté au code HTML à l’endroit où se trouve cette instruction pour être utilisé comme s’il se trouvait entre les balises <style> et </style>. Le navigateur génère alors cette requête, dont vous pouvez constater la conformité de la structure avec ce que nous avons vu dans la première partie, et l’envoie au serveur. Comme nous l’avons vu dans la première partie, la requête doit être traitée par le serveur, lequel se charge également d’envoyer un accusé de réception, à défaut de quoi le client répète sa requête neuf fois (donc dix requêtes sont envoyées). Si aucune réponse ne lui parvient et s’il n’a pas autre chose à faire, le serveur ferme la connexion. Ce traitement n’a pas encore été réalisé, mais ça ne va pas tarder.

- Enfin, la ligne GET /favicon.ico HTTP/1.1 : cette requête dépend du navigateur et elle est envoyée automatiquement, ou pas. Son but est de charger une icône se trouvant à la racine du site web pour l’affecter en général à l’onglet représentant la page dans laquelle s’affiche le site. Cette requête n’offrant pas de réel intérêt pour ce tutoriel, j’avais dans un premier temps décidé de l’ignorer. Pourtant, ces dix lignes qui s’affichent dans le moniteur m’agacent et dénotent un manque de finition. Je vais donc traiter ce problème un peu plus bas, dès que nous aurons écrit deux petites fonctions bien pratiques.

Donc, comme promis ci-dessus, nous allons traiter la requête GET /tuto.css HTTP/1.1. Nous savons, dans les grandes lignes, comment traiter ce type de requêtes : nous l’avons déjà fait pour la demande d’envoi du fichier tuto.html et le principe est rigoureusement le même.

Voici notre nouveau sketch :

Test-serveur.ino

1. #include <SdFat.h>

2. #include <Ethernet.h>

4. SdFat SD;

6. const int carteSD = 4;

8. byte macSerre[] = {0x90, 0xA2, 0xDA, 0x10, 0x4F, 0x25};

9. IPAddress IPSerre(192,168,1,200);

10. EthernetServer serveurHTTP(80);

12. void setup()

13. {

14. SD.begin(carteSD);

15. Ethernet.begin(macSerre, IPSerre);

16. serveurHTTP.begin();

17. Serial.begin(115200);

18. }

20. void loop()

21. {

22. EthernetClient client = serveurHTTP.available();

23. if (client)

24. {

25. if (client.connected())

26. {

27. String reception;

28. while (client.available())

29. {

30. char carLu = client.read();

31. if (carLu != 10)

32. {

33. reception += carLu;

34. }

35. else

36. {

37. break;

38. }

39. }

40. Serial.println(reception);

41. if (reception.startsWith("GET / HTTP/1.1"))

42. {

43. client.println(F("HTTP/1.1 200 OK"));

44. client.println(F("Content-Type: text/html"));

45. client.println(F("Connection: close"));

46. client.println();

47. if (SD.exists("tuto.html"))

48. {

49. File fichier = SD.open("tuto.html", FILE_READ);

50. while (fichier.available())

51. {

52. client.write(fichier.read());

53. }

54. fichier.close();

55. }

56. else

57. {

58. client.println(F("Fichier 'tuto.html' introuvable..."));

59. }

60. }

61. else if (reception.startsWith("GET /tuto.css HTTP/1.1"))

62. {

63. client.println(F("HTTP/1.1 200 OK"));

64. client.println(F("Content-Type: text/css"));

65. client.println(F("Connection: close"));

66. client.println();

67. if (SD.exists("tuto.css"))

68. {

69. File fichier = SD.open("tuto.css", FILE_READ);

70. while (fichier.available())

71. {

72. client.write(fichier.read());

73. }

74. fichier.close();

75. }

76. else

77. {

78. client.println(F("Fichier 'tuto.css' introuvable..."));

79. }

80. }

81. client.stop();

82. }

83. }

84. }

Quelles sont les nouveautés ? Le code que nous avons ajouté, bien sûr. Tout se passe entre la ligne 61 et la ligne 80, ces deux lignes étant incluses. Mais quelles sont les réelles nouveautés dans ce code ? Comparez le fragment situé entre les lignes 41 et 60 avec celui situé entre les lignes 61 et 80 : c’est pratiquement le même. Les modifications portent sur :

- le test pour isoler la requête à laquelle on va répondre, ligne 61. GET /tuto.css HTTP/1.1 remplace GET / HTTP/1.1 ;

- l’indication, dans l’accusé de réception destiné au client, du type de données que celui-ci va recevoir, à savoir text/css en remplacement de text/html utilisé précédemment. Cette précision est essentielle, car en cas d’omission, le navigateur essayera par défaut d’interpréter le texte comme étant du code HTML. Puisque ce n’en est pas, il le considérera comme du simple texte et l’affichera comme tel si c’est possible ;

- le passage du fichier tuto.css comme paramètre dans les lignes 67, 69 et 78, en remplacement du fichier tuto.html utilisé précédemment.

Les changements ne portent que sur les paramètres. Techniquement, c’est le même code. Il serait donc peut-être judicieux de mettre tout ça dans une fonction, d’autant que nous userons par la suite du même mécanisme pour charger un fichier JavaScript.

Mais ne nous emballons pas…

Nous allons en fait écrire deux fonctions : l’une pour créer l’accusé de réception, l’autre pour l’envoi du fichier proprement dit.

Le rôle de la première fonction va être de générer l’accusé de réception. En voici le code :

Fonction arHtml()

void arHtml(EthernetClient nomClient, char type)
{
nomClient.println(F("HTTP/1.1 200 OK"));
nomClient.print(F("Content-Type: "));
nomClient.println(type);
nomClient.println(F("Connection: close"));
nomClient.println();
}

Cette fonction, nommée arHtml (pour accusé de réception Html), ne retourne aucune valeur : pour cette raison elle n’est pas typée et sa déclaration doit donc commencer par le mot clé void (vide). Elle demande deux paramètres :

- nomClient de type EthernetClient : ce paramètre recevra à l’utilisation l’instance EthernetClient créée lors de la connexion et dont on a besoin pour connaître le destinataire de l’accusé de réception afin de construire les instructions nomClient.println() ;

- type de type String : ce paramètre, quant à lui, va recevoir le renseignement relatif au type des données qui vont être envoyées au client, renseignement nécessaire à une interprétation correcte des dites données par le navigateur.

Le rôle de la deuxième fonction va être d’envoyer le fichier demandé au client. Voici son code :

Fonction envoiFichier()

void envoiFichier(EthernetClient nomClient, String fichierEnCours)
{
char tableau[fichierEnCours.length()+1];
fichierEnCours.toCharArray(tableau, fichierEnCours.length()+1);
if (SD.exists(tableau))
{
File fichier = SD.open(tableau, FILE_READ);
while (fichier.available())
{
nomClient.write(fichier.read());
}
fichier.close();
}
else
{
nomClient.println("Fichier '" + fichierEnCours + "' introuvable...");
}

La construction de cette fonction suit la même démarche que celle utilisée pour la fonction précédente : je ne la détaillerai donc pas. Je vais juste dire un mot sur les deux premières lignes. La fonction SD.exists() n’accepte pas d’argument de type String. Or, la variable fichierEnCours, qui devrait lui être passée en argument est justement un type String. Ces deux lignes ont simplement pour fonction de « transtyper » cette variable en une autre variable appelée tableau qui elle, est de type tableau de caractères, et comme telle, est acceptée par la fonction SD.exists(). Elles utilisent la méthode toCharArray() fournie par l’objet String dont c’est précisément l’usage.

III-D - Récapitulation

Nous venons de détailler les processus permettant au serveur de fournir les fichiers demandés par le client, à condition bien sûr que ces fichiers soient stockés sur la carte microSD insérée dans le slot présent sur le shield Ethernet. Cette technique vous permet d’héberger un site web complet, avec son fichier HTML, son (ses) fichier(s) de mise en forme CSS et son (ses) éventuel(s) fichier(s) JavaScript, à condition qu’ils ne dépassent pas la capacité de la carte que vous utilisez. La bibliothèque SdFat gérant les cartes SD et SDHC, votre marge de manœuvre est confortable puisque vous pouvez y stocker jusqu’à 32 Gio de données, textes, images, etc.

La technique utilisée dans la première partie ne vous offrait pas cette possibilité, en raison de la capacité de stockage limitée de la mémoire offerte par votre Arduino UNO, encore que, eu égard à la simplicité de la réalisation proposée dans cet article, on aurait pu le faire.

Un autre problème se serait également posé : l’utilisation d’une image. Comme promis plus haut, nous allons rajouter une petite icône à notre télécommande. Je vous propose celle-ci : , mais si vous en préférez une autre, n’hésitez pas. Après tout, c’est votre télécommande. Sinon, téléchargez le fichier icone.png et copiez-le sur la carte microSD. Modifiez le fichier tuto-1.html comme suit (ajout de la ligne 8), soit directement sur la carte microSD, soit la version qui se trouve sur votre PC. Dans ce cas, n’oubliez pas de mettre à jour le fichier se trouvant sur la carte microSD. Remettez celle-ci dans son slot sur le shield Ethernet.

Le nouveau fichier tuto-1.html :

tuto-1.html

1. <!DOCTYPE html>

3. <html lang="fr">

5. <head> <!-- La balise <head> peut être omise en HTML5 -->

6. <meta charset="utf-8" />

7. <link rel="stylesheet" type="text/css" href="tuto-1.css">

8. <link rel="icon" type="image/png" href="icone.png">

9. <title>Télécommande</title>

10. </head>

12. <body>

13. <form  method="get">

14. <p class="titre">Cliquez sur un bouton</p>

15. <input type="submit" value="ON" name="on" />

16. <input  type="submit" value="OFF" name="off" />

17. </form>

18. <p class="retour">LED éteinte</p>

19. </body>

21. </html>

et le nouveau sketch serveur dans son intégralité :

test-serveur.ino

1. #include <SdFat.h>

2. #include <Ethernet.h>

4. SdFat SD;

6. const int carteSD = 4;

8. byte macSerre[] = {0x90, 0xA2, 0xDA, 0x10, 0x4F, 0x25};

9. IPAddress IPSerre(192,168,1,200);

10. EthernetServer serveurHTTP(80);

12. void setup()

13. {

14. SD.begin(carteSD);

15. Ethernet.begin(macSerre, IPSerre);

16. serveurHTTP.begin();

17. Serial.begin(115200);

18. }

20. void loop()

21. {

22. EthernetClient client = serveurHTTP.available();

23. if (client)

24. {

25. if (client.connected())

26. {

27. String reception;

28. while (client.available())

29. {

30. char carLu = client.read();

31. if (carLu != 10)

32. {

33. reception += carLu;

34. }

35. else

36. {

37. break;

38. }

39. }

40. Serial.println(reception);

41. if (reception.startsWith("GET / HTTP/1.1"))

42. {

43. arHtml(client, "text/html");

44. envoiFichier(client, "tuto-1.html");

45. }

46. else if (reception.startsWith("GET /tuto-1.css HTTP/1.1"))

47. {

48. arHtml(client, "text/css");

49. envoiFichier(client, "tuto-1.css");

50. }

51. else if (reception.startsWith("GET /icone.png HTTP/1.1"))

52. {

53. arHtml(client, "image/png");

54. envoiFichier(client, "icône.png");

55. }

56. client.stop();

57. }

58. }

59. }

61. // FONCTIONS

63. void arHtml(EthernetClient nomClient, char type)

64. {

65. nomClient.println(F("HTTP/1.1 200 OK"));

66. nomClient.print(F("Content-Type: "));

67. nomClient.println(type);

68. nomClient.println(F("Connection: close"));

69. nomClient.println();

70. }

72. void envoiFichier(EthernetClient nomClient, String fichierEnCours)

73. {

74. char tableau[fichierEnCours.length()+1];

75. fichierEnCours.toCharArray(tableau, fichierEnCours.length()+1);

76. if (SD.exists(tableau))

77. {

78. File fichier = SD.open(tableau, FILE_READ);

79. while (fichier.available())

80. {

81. nomClient.write(fichier.read());

82. }

83. fichier.close();

84. }

85. else

86. {

87. nomClient.println("Fichier '" + fichierEnCours + "' introuvable...");

88. }

89. }

Téléversez ce sketch et connectez-vous. Voici ce que vous obtenez :

Il s’agit, sans surprise, de la page que vous connaissez déjà, avec le petit plus dû à l’icône apparaissant dans l’onglet.

L’affichage sur le moniteur est enfin convenable. Juste pour le fun, nous sommes là pour expérimenter, reconnectez-vous : vous pouvez constater l’absence de la requête concernant le téléchargement de l’icône. Comment expliquer cela, d’autant que l’icône est toujours à sa place dans l’onglet ? Tout simplement, le navigateur dispose d’un mécanisme permettant, entre autres choses, d’augmenter la vitesse d’affichage et d’économiser le trafic sur le réseau : la mise en cache. Grâce à ce dispositif, l’icône a été mémorisée sur le PC, ce qui fait qu’il est inutile de la recharger tant qu’on ne la modifie pas. Il n’y a donc pas de requête.

Ce sketch est parfaitement fonctionnel, mais il faut bien dire qu’à part envoyer la page HTML que vous aviez réalisée dans la première partie, il ne fait pas grand-chose. Pourtant, dans les coulisses, il y a eu pas mal de changements.

Vous avez peut-être remarqué que si vous cliquez sur un des boutons, pour voir, non seulement la LED ne change pas d’état, mais en plus votre navigateur vous informe de la réinitialisation de votre page et n’affiche donc plus votre télécommande. Ceci est normal. En effet, le code HTML que nous avons utilisé, et qui vient de la première partie, est lui aussi fonctionnel, ce qui fait que le clic sur un des boutons envoie bien une requête au serveur. Or, nous n’avons rien prévu pour traiter cette requête dans notre sketch, et donc le serveur ne renvoie rien, pas même l’accusé de réception, ce qui entraîne la réinitialisation de la connexion, comme nous l’avons vu dans le tutoriel précédent.

Je vous laisse, à titre d’exercice, le soin de compléter ce sketch pour résoudre ce problème. Vous avez tous les éléments pour le faire. Comme je suis plutôt d’un naturel serviable, je vais quand même vous donner un lien pour télécharger le sketch complet. Je vous encourage malgré tout à essayer de l’écrire vous-même. Au niveau formation, il n’y a rien de mieux.

Par contre, et là vous allez probablement être déçu, en l’état actuel des choses, seule la partie télécommande est opérationnelle : les fonctionnalités concernant la télémétrie ne vont pas pouvoir être implémentées. Comme le code HTML est à présent contenu dans un fichier localisé sur la carte microSD, il n’est plus accessible directement par le sketch. Son contenu ne pourra donc pas être modifié avant son envoi et votre page s’affichera toujours identique à elle-même.

IV - Conclusion

Les techniques que nous venons de voir sont-elles donc inutilisables dans notre contexte et avons-nous fait ce travail pour rien ? Non bien sûr, sans quoi l’intérêt de ce tutoriel aurait été très limité.

D’abord, j’ai dit que le code HTML n’était plus « accessible directement par le sketch ». Cela sous-entend qu’il l’est de manière indirecte. La bibliothèque SdFat nous permet en effet aussi bien d’écrire que de lire sur la carte microSD. Il est donc possible de générer un fichier HTML tenant compte des mises à jour que l’on souhaite afficher chez le client et d’envoyer ensuite ce fichier en utilisant les méthodes que nous venons de voir.

Cependant, cette manière d’opérer va compliquer le code de façon non négligeable, d’une part, et d’autre part l’impact de ce code sur la mémoire va limiter considérablement notre marge de manœuvre concernant l’évolution du système. En conséquence, cette pratique n’offre plus vraiment d’intérêt comparée à la manière dont nous avons traité le problème dans la première partie.

Ensuite, et heureusement, il y a une manière bien plus élégante et efficace pour surmonter cette difficulté : je vous propose de découvrir, dans la troisième et dernière partie de ce tutoriel, comment utiliser JavaScript et JSON pour mettre en œuvre un système de requêtes AJAX qui va permettre de ne transmettre qu’une fois les fichiers, lors de la connexion, en transférant au client la charge de générer les mises à jour de la page, ce qui contribuera à alléger la charge de notre serveur pour lui permettre de faire son travail de microcontrôleur.

V - Remerciements

Je remercie f-leb pour sa relecture technique et ses suggestions.

Je remercie également escartefigue pour sa relecture orthographique.