Le navigateur aux commandes de l’Arduino : télécommande et télémétrie.

Voici le code minimal pour vous connecter au réseau Ethernet :

#include <Ethernet.h>

byte macSerre[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
IPAddress IPSerre(192,168,1,200);
EthernetServer serveurHTTP(80);

void setup()
{
  Ethernet.begin(macSerre, IPSerre);
  serveurHTTP.begin();
  Serial.begin(115200);
}

void loop()
{
  EthernetClient client = serveurHTTP.available();
  if (client)
  {
    if (client.connected())
    {
      while (client.available())
      {
        Serial.write(client.read());
      }
      client.stop();
    }
  }
}

Que fait ce code ? Rien en apparence, mais en réalité, tout est là ou presque, et, comme vous pouvez le constater, tout tient en quelques lignes. Analyse rapide :

#include <Ethernet.h>

Chargement de la bibliothèque Ethernet.

byte macSerre[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
IPAddress IPSerre(192,168,1,200);
EthernetServer serveurHTTP(80);

Déclaration des constantes destinées à paramétrer votre connexion Ethernet :

• macSerre[] : identifiant mac de votre serveur. Cet identifiant, bien que nécessaire au paramétrage, n’a pas de valeur imposée. Vous devez donc remplir ce tableau avec six octets quelconques, le seul impératif étant de vous assurer qu’aucun autre matériel, sur le réseau, n’a la même séquence ;
• IPSerre() : adresse IP que vous souhaitez attribuer à votre serveur sur le réseau. Cette attribution est optionnelle. Si vous avez un routeur DHCP, ce qui est le cas la plupart du temps (box Internet), vous pouvez le laisser attribuer automatiquement une adresse dans la plage DHCP. Je conseille malgré tout de laisser la plage DHCP disponible pour les connexions « nomades », mais cela n’engage que moi. Le matériel que vous allez piloter étant « sédentaire », il est préférable que vous fixiez vous-même une adresse à l’extérieur de la plage DHCP. Connectez-vous au gestionnaire de votre box pour connaître les limites des plages. En ce qui me concerne, et pour vous donner un exemple concret, le serveur DHCP de ma Livebox réserve les adresses comprises entre 192.168.1.10 et 192.168.1.150, d’une part, et la Livebox elle-même occupe l’adresse 192.168.1.1 d’autre part. Les autres adresses sont donc disponibles (sauf celles que j’ai déjà attribuées, bien sûr), et j’ai choisi l’adresse 192.168.1.200 pour ce tutoriel.
• ServeurHTTP() : port (porte logicielle) par lequel le matériel utilisant le protocole HTTP aura accès au système d’exploitation. Le port « 80 » est classiquement réservé à ce protocole, et nous l’utiliserons donc, mais ce n’est pas obligatoire.

Ethernet.begin(macSerre, IPSerre);
serveurHTTP.begin();
Serial.begin(115200);

Dans la section « setup() », on trouve :

• Ethernet.begin() : procédure d’initialisation de la connexion Ethernet avec les paramètres définis précédemment. Si vous avez opté pour une attribution automatique (DHCP) de l’adresse du serveur, vous ne devez fournir que l’adresse matérielle (macSerre) à cette procédure ;
• serveurHTTP.begin() : démarrage du serveur ;
• Serial.begin(115200) : initialisation de la liaison série pour visualiser les données relatives à la connexion en cours dans le moniteur série de l’IDE. Cette ligne est inutile pour la connexion proprement dite.

EthernetClient client = serveurHTTP.available();
if (client)
{
  if (client.connected())
  {
    while (client.available())
    {
      Serial.write(client.read());
    }
    client.stop();
  }
}

Dans la boucle principale, nous avons :

• EthernetClient client = serveurHTTP.available() : teste à chaque itération une éventuelle tentative de connexion, et, dans l’affirmative, crée une instance EthernetClient pour ce nouveau client.
• if (client) : si le client existe ;
• if (client.connected()) : si le client est connecté ;
• while (client.available()) : tant qu’il reste un caractère dans le tampon, on le lit avec client.Read() et on l’écrit sur le moniteur série avec Serial.write() ;
• enfin, on ferme la connexion.

Téléversez ce sketch sur votre serveur puis lancez le moniteur série fourni par l’EDI. Réglez la vitesse de transmission à la valeur que vous avez choisie, ici 115 200 bd. À présent, saisissez, dans la zone ad hoc de votre navigateur, l’adresse IP que vous avez choisie pour ce tutoriel, ici 192.168.1.200 et connectez-vous.

Vous devriez obtenir, mises à part les différences dues au navigateur utilisé, les affichages suivants :

sur le navigateur, et :

sur le moniteur série de l’EDI.

Comment analyser ceci ?

Déjà, il s’est passé quelque chose. C’est satisfaisant en soi. Le navigateur nous indique que la connexion a été réinitialisée, nous verrons pourquoi un peu plus loin, quant au moniteur, il affiche successivement dix fois le message suivant :

GET / HTTP/1.1
Host: 192.168.1.200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr-FR,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Ce message est envoyé par le navigateur au serveur à chaque tentative de connexion de la part du client. Il peut différer de celui qui s’affiche sur votre moniteur, car votre contexte peut être différent du mien, notamment en ce qui concerne le navigateur, mais il aura vraiment un air de famille. Par contre, la première ligne, GET / HTTP/1.1, sera exactement la même. Du moins je vous le souhaite, car dans le cas contraire, nous avons un problème.

Pourquoi ce message s’affiche-t-il dix fois de suite. Eh bien ! votre navigateur sait qu’il peut y avoir de la « friture sur la ligne », si je puis employer cette vieille expression qui nous vient de l’époque de la TSF (Télégraphie Sans Fil). Il tente donc plusieurs fois de se connecter, jusqu’à obtenir un accusé de réception du serveur. Or, il se trouve que dans le sketch, nous n’avons rien prévu de ce genre. Alors, après dix tentatives infructueuses, le navigateur abandonne la partie, considérant que la ligne est en dérangement. Et c’est le résultat de cette impossibilité de se connecter qu’il affiche en disant que la connexion a été réinitialisée.

En ce qui nous concerne, cette analyse est mauvaise. Les dix demandes de connexion envoyées par le client sont bien parvenues au serveur : la preuve en est donnée par les dix affichages dans le moniteur série. Vous allez donc simplement modifier votre sketch afin qu’il fasse parvenir au client un accusé de réception de sa demande. De plus, vous allez vous assurer qu’il s’agit bien d’une requête HTTP demandant l’envoi d’une page HTML en vérifiant que la première ligne est bien de la forme GET / HTTP/1.1.

Voici votre nouveau sketch :

#include <Ethernet.h>

byte macSerre[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
IPAddress IPSerre(192,168,1,200);
EthernetServer serveurHTTP(80);

void setup()
{
  Ethernet.begin(macSerre, IPSerre);
  serveurHTTP.begin();
  Serial.begin(115200);
}

void loop()
{
  EthernetClient client = serveurHTTP.available();
  if (client)
  {
    if (client.connected())
    {
      String reception;
      while (client.available())
      {
        char carLu = client.read();
        if (carLu != 10)
        {
          reception += carLu;
        }
        else
        {
          break;
        }
      }
      Serial.println(reception);
      if (reception.startsWith("GET / HTTP/1.1"))
      {
        client.println(F("HTTP/1.1 200 OK"));
        client.println(F("Content-Type: text/html"));
        client.println(F("Connection: close"));
        client.println();
      }
      client.stop();
    }
  }
}

Détail des modifications :

String reception;

Déclaration de la variable locale reception de type String (chaîne de caractères).

char carLu = client.read();

Transfert du caractère disponible en sortie de tampon vers la variable locale carLu : il s’agit bien d’un transfert, à savoir que ce caractère va être copié depuis le tampon, collé dans la variable, puis supprimé du tampon, ce qui permet au caractère suivant de devenir disponible pour la lecture suivante. On comprend que ce mécanisme permet d’accéder successivement à tous les caractères contenus dans le tampon, tout en vidant celui-ci.

if (carLu != 10)
{
  reception += carLu;
}
else
{
  break;
}

Pourquoi ce test, alors que la ligne reception += carlu; suffit pour récupérer la chaîne reçue ? En fait, comme nous le verrons ultérieurement, seule la première ligne envoyée par le navigateur du client nous intéresse. Chaque ligne se termine par le caractère de code ASCII 10, appelé caractère de fin de ligne (LF pour Line Feed en anglais). Ce test, qui nous permet de détecter la fin de la première ligne, va donc également nous permettre d’empêcher la récupération des caractères inutiles contenus dans le tampon. Cela permet, d’une part, de gagner du temps, et, d’autre part, de ne stocker dans la variable reception que les renseignements utiles et donc d’éviter d’encombrer pour rien la mémoire vive dont la capacité n’est pas phénoménale. On utilise ensuite break; pour sortir de la boucle while, sinon tous les caractères, excepté ceux de fin de ligne, seront lus et stockés.

if (reception.startsWith("GET / HTTP/1.1"))
{
  client.println(F("HTTP/1.1 200 OK"));
  client.println(F("Content-Type: text/html"));
  client.println(F("Connection: close"));
  client.println();
}

La modification principale est dans ce fragment de code :

• le test sur la chaîne GET / HTTP/1.1 envoyée par le client, qu’on appellera « requête » à partir de maintenant, renseigne le serveur sur la nature de cette requête et sur la version du protocole utilisé. Elle fait partie du protocole HTTP et indique au serveur qu’on attend de lui l’envoi d’une ressource, quelle qu’elle soit, dans la limite de sa compatibilité avec le protocole en question, ici HTTP/1.1. Vous ne pourrez pas envoyer des carottes… encore qu’avec l’évolution des techniques, allez savoir !
  Cette requête utilise la méthode GET et serait généralement suivie, lors d’une navigation standard, de l’adresse d’une page WEB (URL). Notre serveur étant un peu atypique, ce n’est pas exactement le cas ici, où seule l’adresse du serveur est utile ;

• ce renseignement va être exploité par le serveur pour construire l’accusé de réception qu’attend le client. Pour notre application, cet accusé de réception ne nécessite que quatre lignes, mais il y en aura souvent plus dans le cas général :

  • le serveur envoie d’abord la chaîne HTTP/1.1 200 OK indiquant au client que la demande lui est bien parvenue, qu’elle a été comprise et qu’elle va être exécutée. Quand vous demandez l’affichage d’une page WEB, c’est le logiciel serveur, par exemple « Apache », qui se charge de cette réponse. Si la ressource n’est pas disponible, le serveur remplacera le nombre 200 par le nombre 404, que vous avez certainement déjà eu l’occasion de voir affiché par votre navigateur. Il ne s’agit pas, dans ce cas, d’un problème de connexion, mais, dans la plupart des cas, d’un lien obsolète,
  • le serveur va ensuite indiquer la nature de ce qu’il va envoyer, en respectant bien entendu le format adéquat. Comme nous allons, dans un premier temps, envoyer une page HTML, la nature de l’envoi sera text/html, text parce qu’il s’agit de texte et html pour indiquer que ce texte représente du code HTML, que le navigateur devra interpréter comme tel,
  • la troisième ligne indique que la connexion sera fermée en fin de transaction,
  • quant à la quatrième ligne, vide, elle est obligatoire, car elle sert de délimiteur pour indiquer au client la fin de l’accusé de réception et le début de l’envoi de l’objet de la requête.

Téléversez ce sketch et connectez-vous au serveur. Vous devriez obtenir ceci :

Le navigateur n’indique plus de problème de connexion, et le moniteur n’affiche plus qu’une seule fois le message, celui-ci réduit à la première ligne qui, seule, nous intéresse.

Bon ! c’est pas tout : ça fonctionne peut-être bien, mais ça n’affiche pas grand-chose. Effectivement, vous n’avez rien envoyé après l’accusé de réception : c’est votre faute. Non, je plaisante. Ne vous inquiétez pas, on va arranger ça.

Que ceux qui ne connaissent pas le HTML se rassurent : l’usage que nous allons faire de ce langage, dans le cadre de ce tutoriel, sera très limité. Cela dit, la présentation en souffrira, mais ce n’est pas l’objet ici.

Pour faire très court, le HTML (HyperText Markup Langage) est, à l’origine, un langage de description de page basé sur l’utilisation de balises, en quelque sorte des « instructions », pour faire un parallèle avec un langage de programmation, et qui implémente le protocole HTTP pour permettre la navigation d’une zone de texte à une autre, qu’elles soient situées dans le même document ou dans des documents différents, et que ces documents se trouvent sur un même PC ou sur des PC reliés par un réseau.

Un fichier HTML est un simple fichier texte, dont l’extension est « .html », ce qui fait que, pour coder du HTML, un éditeur de texte suffit. L’utilisation d’un traitement de texte est à proscrire dans la mesure où le fichier généré par celui-ci n’est pas un fichier texte. Considérant ce que vous allez coder, n’importe quel éditeur fera l’affaire, mais, si vous disposez d’un éditeur offrant la coloration syntaxique, ce n’en sera que mieux.

D’abord, et je ne devrais pas le dire, HTML est très permissif, ou du moins, les moteurs de rendu des navigateurs ne sont pas à cheval sur la syntaxe. Ce sont des interpréteurs et ils interprètent au sens premier du terme. Ce qu’ils comprennent, ils le traduisent et l’utilisent, le reste, ils l’ignorent.

Je vous propose de saisir (copier) le code HTML suivant dans un éditeur de texte :

<!DOCTYPE html>

<html lang="fr">

  <meta charset="utf-8" />
  <title>Ma première page</title>

  <body>
    <div>
      <h3>Informations sur la page</h3>
      <p>Cette page HTML ne contient qu’un peu de texte, avec un minimum de mise en forme pour l’exemple. Elle fait appel aux fonctionnalités de base d’un navigateur, à savoir afficher du texte et établir un hyperlien. Sa syntaxe satisfait aux exigences du W3C.</p>
      <p>Le <a href="https://fr.wikipedia.org/wiki/World_Wide_Web_Consortium">W3C</a> (<i>World Wide Web Consortium</i>), est l’organisme ayant en charge la promotion et la standardisation du Web.</p>
    </div>
  </body>

</html>

<meta charset="utf-8" />
<title>Ma première page</title>
<h3>Informations sur la page</h3>
<p>Cette page HTML ne contient qu’un peu de texte, avec un minimum mise en forme pour l’exemple. Elle fait appel aux fonctionnalités de base d’un navigateur, à savoir afficher du texte et établir un hyperlien. Sa syntaxe satisfait aux exigences du W3C.</p>
<p>Le <a href="https://fr.wikipedia.org/wiki/World_Wide_Web_Consortium">W3C</a> (<i>World Wide Web Consortium</i>), est l’organisme ayant en charge la promotion et la standardisation du Web.</p>

Voici quelques explications :

La structure de base d’un fichier HTML5 est la suivante :

<!DOCTYPE html>

<html>

  <title></title>

  <body>

  </body>

</html>

• la ligne <!DOCTYPE html> indique au navigateur que le langage utilisé ici est le HTML5 (voir ici) ;
• l’ensemble du code se trouve entre les balises <html> et </html> (voir ici) ;
• le texte situé entre les balises <title> et </title> représente le libellé de l’onglet de votre navigateur qui concerne cette page (voir ici). Il peut également apparaître dans la barre de titre ;
• l’intégralité de la description de la page se trouve entre les balises <body> et </body> (voir ici).

En ce qui concerne notre page :

• la ligne <meta charset="utf-8" /> indique au navigateur que les caractères sont encodés en UTF-8. Si l’éditeur que vous utilisez encode dans un autre format, vous devrez spécifier ce format, à défaut de quoi les diacritiques ne seront pas traités correctement (voir ici et là) ;
• les balises <div> et </div> délimitent un bloc cohérent au niveau de la présentation de la page (voir ici) ;
• les balises <h3> et </h3> déterminent un niveau de titre et formatent le texte inséré entre elles en conséquence (voir ici) ;
• les balises <p> et </p> délimitent un paragraphe (voir ici) ;
• les balises <i> et </i> servent à mettre en italique le texte qu’elles encadrent ;
• les balises <a> et </a> servent à définir un hyperlien en utilisant l’« attribut » href (voir ici et là).

L’impact des balises sur le texte qu’elles concernent peut être modifié globalement ou individuellement en utilisant des « attributs », mais je n’irai pas plus loin sur ce chapitre. Soyez persuadé que les possibilités sont vastes, et je vous encourage à creuser le sujet.

Sauvegardez ce texte dans un fichier, par exemple « test.html », et ouvrez-le dans votre navigateur pour voir ce que ça donne.

Maintenant que vous avez votre page HTML, comment allez-vous y accéder depuis le client ? Parce que c’est quand même ça le but de la manœuvre.

Eh bien ! vous allez procéder de la même façon que pour récupérer l’accusé de réception, en envoyant le texte du fichier HTML au client en utilisant l’instruction client.println().

Modifiez le sketch précédent en complétant l’accusé de réception comme suit :

client.println(F("HTTP/1.1 200 OK"));
client.println(F("Content-Type: text/html"));
client.println(F("Connection: close"));
client.println();
client.println(F( "<!DOCTYPE html>"
                  "<html lang=\"fr\">"
                  "<meta charset=\"utf-8\" />"
                  "<title>Ma première page</title>"
                  "<body>"
                  "<div>"
                  "<h3>Informations sur la page</h3>"
                  "<p>Cette page HTML ne contient qu’un peu de texte, avec un minimum de mise en forme pour l’exemple. Elle fait appel aux fonctionnalités de base d'un navigateur, à savoir afficher du texte et établir un hyperlien. Sa syntaxe satisfait aux exigences du W3C.</p>"
                  "<p>Le <a href=\"https://fr.wikipedia.org/wiki/World_Wide_Web_Consortium\">W3C</a> (<i>World Wide Web Consortium</i>), est l’organisme ayant en charge la promotion et la standardisation du Web.</p>"
                  "</div>"
                  "</body>"
                  "</html>"));

J’ai disposé la chaîne constituant le fichier HTML de telle manière qu’elle soit facile à lire dans l’éditeur, ce qui facilite l’écriture quand on construit la page directement dans le sketch, mais ce n’est pas obligatoire.

Téléversez le nouveau sketch et connectez-vous comme d’habitude. Votre navigateur devrait afficher ceci :

Vérifiez le libellé de l’onglet et n’hésitez pas à cliquer sur le lien. Il vous enverra sur la page Wikipédia consacrée au W3C. Par curiosité, faites un clic droit sur la page et sélectionnez « Code source de la page » ou ce qui y ressemble dans votre navigateur. Vous constaterez que tout le code est sur une seule ligne. La façon dont il est présenté dans l’EDI n’a donc rien changé véritablement.

Il est possible, voire probable, que vous soyez actuellement devant votre PC ou votre portable. Il serait cependant bon de vérifier que ça fonctionne avec un smartphone ou une tablette : c’est le moment.

Maintenant que vous savez envoyer une page HTML, c’est-à-dire du texte (ou plutôt des octets, puisque c’est tout ce que sait acheminer le réseau), depuis le serveur vers le client, il va être intéressant d’envisager la possibilité de faire l’opération inverse, à savoir envoyer du texte depuis le client vers le serveur.

Vous savez déjà que le client peut envoyer du texte au serveur. Souvenez-vous des messages affichés dans le moniteur du serveur (le moniteur série de l’EDI) : il s’agissait bien de texte envoyé par le navigateur, donc par le client, lors de sa demande de connexion. Souvenez-vous également que j’avais précisé que seule la première ligne allait nous intéresser, et que nous avions fait en sorte de ne recevoir qu’elle.

Je vous propose une petite expérience : connectez-vous à votre serveur, mais en ajoutant /toto à votre adresse. Pour moi, ça donnera 192.168.1.200/toto. Vous devriez obtenir quelque chose comme :

La connexion a été réinitialisée. C’est pourtant la bonne adresse, et jusque-là, ça ne fonctionnait pas si mal.

Mais voici l’explication :

Il y a effectivement eu dix tentatives de connexion, à l’issue desquelles le navigateur, ne recevant pas l’accusé de réception, rend compte de l’impossibilité de se connecter.

Rien de plus normal ! Comme vous pouvez le constater, notre « toto » (qu’est-ce qu’on peut le faire travailler, ce brave toto) est parvenu au serveur, incorporé à la première ligne du message envoyé par le client lors de sa demande de connexion. Cela nous montre comment on va pouvoir entamer le dialogue, seulement la conséquence est que notre test :

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

n’est plus valable. Mais, de la même manière que « toute casserole trouve son couvercle », tout problème a sa solution (du moins quand ça veut rigoler).

Qu’est-ce qui nous intéresse vraiment dans ce début de message ?

• HTTP/1.1 ? Non ! C’est simplement votre navigateur qui informe votre serveur qu’il utilise ce protocole pour causer avec lui. Comme, dans le cadre de votre application, ce renseignement ne sera l’objet d’aucun traitement, vous n’avez pas besoin de tester sa présence.
• GET ? Ben non, pas plus en fait, dans la mesure où, toujours dans le cadre de votre application, vous n’utiliserez que cette méthode. Le fonctionnement de cette méthode, comme vous venez de le voir, consiste simplement à ajouter la requête à l’URL. Une URL pouvant contenir jusqu’à 3000 caractères environ, vous avez de la marge.

En résumé, techniquement parlant, ce test est inutile. Nous l’utiliserons quand même. Vous allez probablement vous poser la question : « Qu’est-ce qu’il nous fait là, pépère ? ». Je me la pose moi-même assez souvent.

La prudence nous impose d’effectuer un test pour nous assurer de la bonne réception de la requête (sans oublier toutefois que le test en question n’offre pas une sécurité absolue). Le problème est que nous aurons affaire à deux types de requêtes :

• lors de la connexion, la seule chose que l’on demande au serveur est l’envoi de la page. Le message reçu sera GET / HTTP/1.1 ;
• les requêtes suivantes seront des commandes spécifiques, et le message reçu sera de la forme GET /?toto HTTP/1.1.

Nous modifierons donc notre test comme suit :

reception.trim();
if ((reception.startsWith("GET /") && (reception.endsWith(" HTTP/1.1"))

La première ligne supprime les espaces et les caractères non imprimables, s’il y en a, situés au début et à la fin de la chaîne reception. En l’occurrence, il y a un caractère non imprimable en fin de chaîne, et sans cette précaution, le test ne passe pas.

La seconde ligne parle d’elle-même. Elle vérifie que la chaîne reçue commence par GET / et se termine par HTTP/1.1, ce qui fait que, qu’il y ait ou non un message inséré entre ces deux portions de chaîne, mais à la condition que cette chaîne soit présente, entière ou encadrant le message, le test sera passé.

Maintenant que les principes de fonctionnement sont posés, nous pouvons passer à une première application pratique.

Voici une présentation rapide du composant :

• boîtier TO92 (3 pins) :

  

• Disponible également dans les boîtiers TO-CAN (3), TO-220 (3) et SOIC (8) ;

• brochage du boîtier utilisé :

  

• J’attire votre attention sur le fait qu’il s’agit d’une vue du dessous. Lors de mes premiers essais avec ce composant, il y a quelques années, j’étais passé à côté de ce détail et je m’étais gratté la tête un moment avant de comprendre. Le composant ne m’en a pas voulu : il est plutôt robuste ;

• application typique :

  

• Utilisé tel quel, la plage de température couverte s’étend de 2 °C à 150 °C ;

• gabarit du boîtier utilisé :

  

• Les mesures sont en millimètre (mm).

Ce composant est un circuit intégré dont la fonction est de mesurer la température ambiante et de générer, sur la broche de sortie (OUTPUT), une tension proportionnelle à cette température. La tension en question est généralement destinée à alimenter, après traitement, un dispositif d’affichage ou de régulation.

Voilà ! Vous savez tous de ce petit composant. Enfin quand je dis « tout », je suis loin du compte, mais c’est tout ce dont nous avons besoin pour ce tutoriel. Je vous conseille la lecture de son datasheet : vous verrez que l’adjonction de quelques composants permet d’aller plus loin.

Comme on vient de le voir, le LM35 fournit, en sortie, une tension proportionnelle à la température mesurée. Le problème est que la tension est une grandeur analogique et qu’elle n’est pas manipulable en tant que telle par un système informatique qui ne connaît que le binaire. Il faut donc trouver un moyen d’exprimer cette grandeur dans cette base. Par chance, le circuit ATmega328P, microcontrôleur sur lequel est basé l’Arduino UNO, implémente un dispositif dont c’est justement la fonction : le convertisseur analogique-numérique (CAN, ou ADC pour Analog to Digital Converter). Cette fonctionnalité n’est accessible que sur les broches A0 à A5. Les broches GPIO 0 à 13 ne font pas partie du club.

La première des choses à faire va donc être de câbler le LM35 en conséquence. Je vous propose pour cela de réaliser la maquette suivante :

Difficile de faire plus simple : outre les broches + et ‒ que vous allez raccorder à l’alimentation, la broche OUTPUT doit être raccordée à l’une des entrées analogique de l’Arduino UNO. Je vous propose arbitrairement la broche A0.

Le convertisseur analogique-numérique (CAN) de l’Arduino UNO a une résolution de 10 bits, c’est-à-dire qu’il va retourner une valeur, comprise entre 0 et 1023 (2¹⁰-1), représentant la proportion, en 1024^ième, entre la tension présente sur son entrée et une tension de référence.

Soit N la valeur renvoyée par le convertisseur analogique-numérique, V_LM la tension fournie par le capteur LM35 et V_REF la tension de référence, on a la relation :

Nous déduisons naturellement de (1) la relation suivante :

On sait que la tension de sortie augmente de 10 mV, soit 0,01 V quand la température augmente de 1 °C et qu’elle est de 0 V à 0 °C (c’est du moins ce que l’on va considérer).
Si on appelle T la température, on aura donc la relation :

ou encore

On tire de (2) et (3) la relation :

Par défaut, à moins d’appliquer une tension de référence différente sur sa broche AREF, la tension de référence utilisée par l’Arduino UNO est le 5 V de son alimentation. La relation (4) devient :

formule que nous allons utiliser pour calculer notre température en fonction de N, valeur renvoyée par la ligne de code :

N = analogRead(numBroche);

numBroche étant le numéro la broche analogique affectée à la sortie du capteur LM35, c’est-à-dire 0 en ce qui nous concerne, puisqu’on a opté pour la broche A0.

La première limitation est liée à la résolution proprement dite du convertisseur. Celui de l’Arduino UNO effectue une conversion sur 10 bits, c’est-à -dire que, pour faire simple, il va découper une tension de référence en 2¹⁰ « tranches » égales et regarder à quelle tranche correspond la tension à convertir, à la suite de quoi il retournera le rang de la tranche en question. Cette limitation étant intrinsèque au matériel, il n’est pas possible de la contourner.

La seconde limitation est liée à l’(in)adéquation de la plage de mesure avec la tension de référence. Cette limitation sera minimale si la plage de mesure est égale à la tension de référence et maximale si la plage de mesure est inférieure ou égale à la valeur de la « tranche » vue plus haut. Elle prendra, naturellement, des valeurs intermédiaires à l’intérieur de ces limites.

Dans les conditions de notre réalisation, la tension de référence utilisée est la tension par défaut et correspond au 5 V de l’alimentation de la carte. Chaque « tranche » est donc égale à 5 / (2¹⁰-1) ≃ 0,00489 V soit 4,89 mV. La plage de mesure du LM35 tel que câblé ici s’étend de 2°C à 150°C, soit 148°C, ce qui correspond à 1,48 V. Cette valeur, qui représente moins d’un tiers des 5 V de référence, laisse à penser que la conversion ne sera pas réalisée au mieux des possibilités du dispositif.

Deux solutions s’offrent à vous pour optimiser cette conversion :

1. Amplifier le signal pour que son maximum approche, sans les dépasser, les 5 V de référence. Ceci demande de faire appel à un dispositif électronique externe ;
2. Changer la référence. Pour réaliser cela, vous devrez utiliser l’une des trois commandes suivantes (pour l’Arduino UNO) :

analogReference(DEFAULT); // Référence interne de 5 V
analogReference(INTERNAL); // Référence interne de 1,1 V
analogReference(EXTERNAL); // Utilisation externe de la broche AREF

La première ligne peut être omise. Il s’agit de la référence par défaut appliquée à la broche AREF (pour Analog REFerence). La seconde ligne impose la tension de 1,1 V, générée en interne, à la broche AREF. La troisième ligne vous offre la possibilité d’imposer une tension externe de votre choix à la broche AREF.

Je n’irai pas plus loin sur ce sujet, car cela sort du cadre de cet article. Je vous engage à consulter la page analogReference sur le site officiel Arduino.

Je vous propose ce premier sketch pour vous montrer ce que ça peut donner :

const byte LM35 = 0;

void setup()
{
  Serial.begin(115200);
}

void loop()
{
  byte lecture = analogRead(LM35);
  float temperature = float(lecture) * 500 / 1024;
  Serial.print("Température : ");
  Serial.print(temperature, 1);
  Serial.println(" °C");
  delay(2500);
}

Quelques explications concernant ce sketch :

• byte lecture = analogRead(LM35); : effectue une numérisation de la tension présente sur la broche dont le numéro est la valeur de la constante LM35, ici 0, et stocke le résultat dans la variable lecture de type byte ;
• float temperature = float(lecture) * 500 / 1024; : effectue le calcul expliqué plus haut et stocke le résultat dans la variable temperature de type float. Le transtypage float(lecture) est nécessaire pour ne pas perdre les décimales ;
• Serial.print(temperature, 1); : affiche la température dans le moniteur série, avec une décimale ;
• puis on introduit un délai de 2,5 s pour ne pas monopoliser la liaison série et calmer l’affichage.

Votre moniteur série va afficher quelque chose qui peut ressembler à ça :

On ne peut pas dire que ce résultat soit enthousiasmant. Sur neuf mesures effectuées, on constate des fluctuations entraînant un ∆T de près de 5 °C, ce qui est énorme. De plus, indépendamment de la fiabilité du capteur ou de la conversion, la numérisation sur 10 bits ne permet, avec une tension de référence de 5 V, qu’un affichage à 0,5 °C près environ (500 / 1024 ⋍ 0,5).

Ce n’est pas très satisfaisant. Nous allons donc traiter ce problème avant d’aller plus loin.

Je vais faire l’hypothèse que les données issues du capteur ne sont pas fausses en elles-mêmes, mais plutôt réparties autour de la valeur exacte suivant une courbe de type « gaussien ».

Dans ce cas, pour avoir un résultat plus conforme à la réalité, il suffit d’effectuer une série de mesures successives et d’en faire la moyenne. Voici le sketch qui va réaliser cela :

const byte LM35 = 0;
const word iteration = 100;

void setup()
{
  Serial.begin(115200);
}

void loop()
{
  long lecture = 0;
  for (word i = 0; i < iteration; i++)
  {
    lecture += analogRead(LM35);
  }
  float temperature = float(lecture) *500 /1024 /iteration;
  Serial.println(temperature, 1);
  delay(1000);
}

Détails du sketch :

long lecture = 0;
for (word i = 0; i < iteration; i++)
{
  lecture += analogRead(LM35);
}

On numérise iteration fois la température (ici, 100 fois) et on ajoute au fur et à mesure le résultat à la variable lecture, qui a été déclarée avant le début de la boucle.

float temperature = float(lecture) *500 /1024 /iteration;

On calcule la température résultante comme dans le sketch précédent, en n’oubliant pas de diviser par le nombre d’itérations.

Ceci nous a permis de descendre le ∆T à 0,5 °C environ, ce qui est plus acceptable. Je vous propose de regrouper le code utile dans une fonction, ce qui facilitera son utilisation ultérieurement.

const byte LM35 = 0;
const word iteration = 100;

void setup()
{
  Serial.begin(115200);
}

void loop()
{
  Serial.println(temperature(LM35, 100), 1);
  delay(1000);
}

float temperature(byte broche, word iteration)
{
  long lecture = 0;
  for (word i = 0; i < iteration; i++)
  {
    lecture += analogRead(broche);
  }
  return(float(lecture) *500 /1024 /iteration);
}