I. Avant-propos

Quel choix avons-nous pour expérimenter avec le microcontrôleur ESP8266EX ?

Dans la famille ESP8266, il n’y a, en pratique, que trois cartes qui se prêtent à l’expérimentation, à savoir qui disposent de broches enfichables : ESP-01, ESP-05 et ESP-201.

  • L’ESP-01, qui dispose de quatre broches GPIO dont deux réservées à la liaison série. Il n’est pas enfichable sur une plaque de prototypage.
  • L’ESP-05, qui ne dispose que de deux broches GPIO, réservées à la liaison série, et est plutôt destiné à fournir la fonctionnalité WiFi, par exemple à une carte Arduino, au travers de cette liaison.
  • L’ESP-201, qui correspond à un ESP-12E équipé de broches, et qui fournit l’accès à toutes les fonctionnalités de l’ESP8266EX. Toutefois, la disposition de ses broches rend malaisée son utilisation sur les supports de prototypage standards. Il offre la double fonctionnalité de l’antenne intégrée et de l’antenne externe.

Ces cartes nécessitent l’utilisation d’un adaptateur UART/USB pour être programmées.

Au-delà de cette famille, il existe des modules comme NodeMcu ou Wemos, implémentant l’ESP-12E, offrant une interface UART/USB et essentiellement destinés au développement. Ils n’ont pas vocation à être embarqués dans le produit final, du moins dans le domaine industriel, lequel hébergera plutôt le module ESP-12E. Ces modules correspondent en gros à un ESP-201 équipé d’un adaptateur UART/USB et d’un régulateur de tension, et dont la disposition des broches est compatible avec les supports de prototypage.

Pourquoi avoir choisi l’ESP-01 comme support matériel pour ce tutoriel. Ce n’est en effet pas la carte la plus polyvalente parmi celles présentées ci-dessus, et les applications que ce manque de polyvalence permettra seront limitées. Voici, pêle-mêle, quelques éléments de réponse à cette question, dans un ordre qui n’est pas forcément représentatif de leur pertinence respective :

  • le coût : il s’agit, à priori, de la carte la moins chère de la famille ESP8266EX, et concernant l’expérimentation, c’est un plus indéniable. Par dix, on les trouve à environ un euro pièce, c’est dire qu’en cas de crash, il n’y a pas de drame ;
  • sans avoir la polyvalence de ses grandes sœurs, elle n’en dispose pas moins de la WiFi, de deux broches GPIO et de l’implémentation possible d’un bus I2C ou d’un bus 1-wire ce qui est loin d’être négligeable ;
  • étant donné que ce tutoriel est réalisé sur la carte la moins polyvalente de la série, il sera valable pour toutes les autres cartes sans aucune restriction ;
  • l’absence d’interface UART intégrée et le peu de composants implantés ont un impact bénéfique sur la consommation, bien que ce bénéfice soit relativement négligeable en cas d’utilisation de la WiFi, cette dernière étant grosse consommatrice d’énergie ;
  • l’encombrement minimal de cette carte la rend intégrable dans pratiquement n’importe quel projet, pour peu que ses capacités suffisent à ce projet ;
  • enfin, cette minicarte dispose en quelque sorte d’un miniécosystème sous la forme de petits « shields » offrant quelques fonctionnalités intéressantes comme l’interfaçage avec un relais ou un capteur de température.
Image non disponible

Ce module relais tient sans problème dans la boite d’encastrement standard d’un interrupteur mural et permet de transformer celui-ci en interrupteur télécommandé par un smartphone en utilisant la fonctionnalité WiFi.
Il faut bien entendu lui fournir une alimentation, ce qui est réalisé avec le module alimentation présenté ci-dessous, qui se logera également sans difficulté dans le boîtier encastré.
Le prix de ce module est d’environ 2,50 € livré depuis la Chine.

Image non disponible

Comme on peut le voir sur cette capture, il s’agit ici d’un module basé sur le capteur de température/humidité DHT22. Accompagné de l’alimentation présentée ci-dessous, et installé dans un boîtier ventilé, il pourra être mis en place partout où vous disposez du 220 V.
L’affichage de la température se fera sur une tablette ou sur un smartphone.
Le prix de ce module est d’environ 3,00 € livré depuis la Chine.

Image non disponible

Module alimentation 220V-5V 700 mA. Idéal pour alimenter les modules ci-dessus qui nécessitent 5V.
Le prix de ce module est d’environ 1,70 € livré depuis la Chine.

L’utilisation du 220 V est potentiellement dangereuse. Les modules ci-dessus ne bénéficiant d’aucune isolation, les précautions à prendre lors de leur manipulation et le respect des normes concernant leur intégration dans un quelconque dispositif relève de votre responsabilité.

Soyez prudent !

Comme on peut le constater, cette petite carte a donc bien des atouts et mérite qu’on y prête attention. Nous allons voir, dans ce tutoriel, comment « booster » ses possibilités.

II. Introduction

Deux des limitations les plus gênantes de l’ESP-01 sont, à mes yeux, son flashage acrobatique et son manque cruel de sorties GPIO. On peut (dans une certaine mesure, ne rêvons pas) contourner ces insuffisances grâce à deux techniques plus simples d’emploi qu’il n’y paraît, et au choix judicieux de l’application à implémenter.

Nous allons, dans un premier temps, mettre en place une technique de mise à jour sans fil qui va utiliser la liaison Wifi en lieu et place de la liaison série : l’OTA (Over The Air). Cette technique va à la fois nous permettre de nous passer de la manipulation contraignante de l’adaptateur USB-UART et nous faire gagner une entrée/sortie GPIO, celle anciennement utilisée en réception (Rx) par la liaison série. Malheureusement, l’entrée/sortie correspondant à la transmission (Tx) de la liaison série n’est pas opérationnelle, peut-être à cause de la LED intégrée qui y est connectée. Nous passons donc de deux broches GPIO opérationnelles à trois (ce n’est pas Byzance, mais c’est mieux que rien), et d’un protocole de téléversement pas très souple à un protocole standard ne nécessitant aucune manipulation spécifique, et surtout aucune liaison physique.

Dans un deuxième temps, nous allons voir comment créer un système de fichiers dans la partie disponible de la mémoire flash et comment l’utiliser. La première étape consistera à installer l’outil de téléversement du système de fichiers dans l’EDI Arduino et à apprendre comment l’utiliser (simplissime), la seconde se réduisant à l’utilisation de la bibliothèque LittleFS.h, équivalent de la bibliothèque SdFat.h dédiée à la gestion des cartes microSD. Comme l’utilisation d’un lecteur de carte microSD nécessite l’utilisation d’un bus SPI, soit quatre broches GPIO, cela revient à ajouter virtuellement ces quatre broches GPIO à notre ESP-01. Pour que ce soit intéressant, il faut naturellement que notre application en ait besoin et c’est pourquoi je parlais plus haut du choix judicieux de l’application.

On pourra m’opposer à juste titre la très grande différence de capacité entre un ESP-01, disons 400 kio et une carte microSD standard, disons 4 Gio, soit un facteur de 1 pour 10 000. Pour être honnête, je ne considère pas ce critère vraiment pertinent dans la mesure où le traitement de 4 Gio de données n’est clairement pas à la portée d’un Arduino UNO, carte à laquelle je compare, à tort ou à raison, l’ESP-01.

Le simple transfert, depuis un shield Ethernet 2, d’un fichier JavaScript d’une centaine de kilooctets dans une application client-serveur prend plusieurs dizaines de secondes : c’est dissuasif. Ce genre d’architecture ne permet raisonnablement que de traiter des fichiers d’une dizaine de kilooctets, et ce n’est déjà pas si mal.

Nous verrons enfin comment implémenter une petite application graphique destinée à afficher sur un navigateur la température et l’hygrométrie fournies par un capteur DHT22. Ce capteur ne nécessitant qu’une broche GPIO en plus de son alimentation pour fonctionner, il restera deux broches GPIO inutilisées. Tout bien considéré, leur nombre est donc « largement » suffisant puisqu’on pourrait même connecter, en I2C, un capteur barométrique comme le BMP280 pour en faire une vraie petite station météo.

III. Prérequis

III-A. Matériel

Pour réaliser cette manipulation, nous n’aurons pas besoin de casser la tirelire, seuls les trois modules suivants étant indispensables :

Matériel

Description

Image non disponible

ESP-01 :

  • microcontrôleur ESP8266EX ;
  • fréquence CPU : 80 MHz ;
  • fréquence flash : 40 MHz ;
  • mémoire flash externe : 958 448 ko ;
  • mémoire dynamique : 81 920 ko ;
  • alimentation : 3,3 V ;
  • GPIO en mode UART : 2 ;
  • GPIO en mode OTA : 3.
Image non disponible

Brochage de l’ESP-01

  • VCC : 3,3 V ;
  • GND : 0 V (masse) ;
  • GPIO 1 : GPIO + U0TXD ⟶ Fonction transmission UART pendant le flashage ;
  • GPIO 3 : GPIO + U0RXD ⟶ Fonction réception UART pendant le flashage ;
  • EN : CHIP-EN ⟶ Activation du chip :

    • état haut = chip actif,
    • état bas = chip inactif,
    • la broche doit être connectée ;
  • RST : EXT_RSTB ⟶ Réinitialisation :

    • état normal niveau haut (pull up),
    • niveau bas pour réinitialiser ;
  • GPIO 0 : GPIO + doit être maintenue à l’état bas pendant le flashage ;
  • GPIO 2 : GPIO.

Note :
le document technique recommande d’utiliser EN plutôt que RST pour la réinitialisation.

Image non disponible

Adaptateur USB↔UART pour ESP-01 :

  • chip CH340 ;
  • switch mode programmation / mode standard ;
  • alimentation : 5 V (USB) ;
  • niveau logique : 3,3 V.
Image non disponible

DHT22 :

  • alimentation : 3,3 V à 6,0 V ;
  • sortie numérique sur bus 1 conducteur ;
  • échelle de mesure :

    • température : -40 à +80 °C,
    • humidité relative : 0 à 100 % ;
  • précision :

    • température : ± 0,5 °C,
    • humidité relative : ± 5 % ;
  • résolution :

    • température : 0,1 °C,
    • humidité relative : 0,1 %.

Une fois l’OTA mise en place, vous devrez bien sûr ajouter les éléments propres à votre projet, tout comme vous l’auriez fait sans cette technique.

Pour information, voici les trois versions de l’ESP-01 actuellement disponibles sur le marché :

Module

Couleur du PCB

Mémoire flash

LED témoin d’alimentation

LED_BUILTIN

ESP-01

Bleu

512 Kio

Rouge

Bleue sur TX

ESP-01

Noir

1 Mio

Rouge

Bleue sur TX

ESP-01S

Noir

1 Mio

Absente

Bleue sur GPIO 2

L’ESP-01 « bleu » (512 Kio) n’a plus vraiment d’intérêt dans la mesure où on le trouve au même prix que ceux disposant de 1 Mio de mémoire flash. De plus, il est contre-indiqué pour être utilisé conjointement avec l’OTA (voir remarque plus bas).

Pour les autres versions, je destinerais plutôt l’ESP-01 standard au prototypage, quand il est parfois utile (voire prudent) d’être en mesure de vérifier d’un coup d’œil si le module est alimenté, et la version « S » à la « production » pour éviter les consommations inutiles, surtout en cas d’utilisation d’alimentation autonome.

III-B. Logiciel

Pour suivre ce tutoriel, il vous faudra :

  • l’EDI Arduino version 1.6.8 ou plus récente (version actuelle : 1.8.12) ;
  • le gestionnaire de carte ESP8266 installé : si ce n’est pas encore le cas, le tutoriel Débuter avec le module WiFi ESP8266 vous indiquera la marche à suivre (version actuelle : 2.6.3) ;
  • l’interpréteur Python 3 installé sur votre système (version actuelle : 3.8.2) : sous Linux, Python est installé d’origine. Si vous êtes sous Mac OSX® ou Windows® et que python 3 n’est pas installé, rendez-vous sur la page de téléchargement concernée, respectivement ici et .

Vous verrez souvent indiqué sur Internet que la version 2.7 de Python est requise. Cela vient du fait que le portage sous Python 3 est très récent. Vous ne devriez cependant pas avoir de problème, quelle que soit la version que vous utilisez.

Je vous conseillerais malgré tout, si ce n’est déjà fait, d’installer la version 3, car il est probable que dans un avenir plus ou moins proche, seul le portage sous Python 3 sera maintenu.

Il vous faut également expliquer à l’EDI que vous allez travailler avec un ESP8266EX :

Image non disponible

Comme il n’y a pas d’item spécifique pour le module ESP-01, vous devrez opter pour la configuration générique ESP8266 (attention à ne pas confondre avec l’ESP8285).

IV. Programmation de l’ESP-01 avec l’adaptateur

Avant tout, il vous faut un sketch. Plutôt que le « blink » habituel, je vous propose le sketch suivant :

info-esp.ino
Cacher/Afficher le codeSélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
ADC_MODE(ADC_VCC);

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

void loop()
{
  /* ESP8266EX */
  Serial.println("INFO ESP8266EX");
  Serial.printf("Numéro de série de l'ESP8266EX .....: %u\n", ESP.getChipId());
  float frequenceCpu = float(ESP.getCpuFreqMHz());
  Serial.printf("Fréquence du CPU ...................: %4.1f MHz\n", frequenceCpu);
  float vcc = float(ESP.getVcc()) / 1000;
  Serial.printf("Alimentation .......................: %4.2f V\n", vcc);  
  String chaine = ESP.getCoreVersion();
  chaine.replace('_', '.');
  Serial.print("Version du gestionnaire de carte...: ");
  Serial.println(chaine); 
  Serial.printf("Version du SDK .....................: %s\n\n", ESP.getSdkVersion());
  /* Mémoire flash */
  Serial.println("INFO FLASH");
  Serial.printf("Numéro de série du chip ............: %u\n", ESP.getFlashChipId());
  float frequenceFlash = float(ESP.getFlashChipSpeed()) /1000000;
  Serial.printf("Fréquence ..........................: %4.1f MHz\n", frequenceFlash);  
  Serial.printf("capacité effective .................: %u octets\n", ESP.getFlashChipRealSize());
  Serial.printf("capacité paramétrée dans l'EDI .....: %u octets\n", ESP.getFlashChipSize());
  Serial.printf("Taille du sketch ...................: %u octets\n", ESP.getSketchSize());
  Serial.printf("Mémoire disponible .................: %u octets\n\n\n", ESP.getFreeSketchSpace());
  delay(10000);
}

qui va avoir l’avantage de nous fournir quelques renseignements de base sur notre ESP-01 et sur la mémoire flash dont il est pourvu, ainsi que sur la configuration concernant celle-ci dans l’EDI.

Ensuite, vous devez connecter le module ESP-01 à l’adaptateur. Voici ce que ça donne en image :

Image non disponible

Effectuez à présent les manipulations suivantes :

  • positionner le commutateur sur « PROG » (sérigraphie sur la carte) ;
  • brancher l’adaptateur sur une prise USB du PC ;
  • attendre une seconde environ puis basculer le commutateur sur « UART » ;
  • sélectionner le port série correspondant à votre matériel ;
  • téléverser le sketch comme d’habitude ;
  • débrancher l’adaptateur de la prise USB.

À partir de maintenant, soit l’utilisation du sketch nécessite la liaison série : dans ce cas vous devrez rebrancher l’adaptateur sur le PC ; soit la liaison série est inutile : vous devrez alors déconnecter l'ESP-01 de l’adaptateur pour l’utiliser dans le prototypage de votre projet, car le type de connexion utilisé ne laisse pas l’accès aux broches. C’est là que vous allez apprécier l’OTA. N’oubliez pas de raccorder la broche EN au VCC (+ 3,3 V) pour activer le microcontrôleur.

Pour ce qui nous concerne dans l’immédiat, comme le sketch que nous venons de téléverser est destiné à envoyer des données sur le moniteur série de l’EDI, vous allez ouvrir celui-ci et reconnecter l’adaptateur au PC.

Vous devriez obtenir ce genre de chose :

Image non disponible

V. OTA (Over The Air)

L’OTA est une technique de mise à jour devenue courante depuis l’avènement des smartphones et des tablettes. L’appareil télécharge depuis Internet, via le réseau Wifi routé par la box, la nouvelle version d’un logiciel puis, après vérification du bon déroulement de l’opération, met à jour ce logiciel. C’est ce que nous allons faire, avec notre petit ESP-01 dans le rôle du smartphone.

Outre la différence de technologie entre les deux méthodes de téléversement, Série ou Wifi, le déroulement des opérations n’est pas le même. Lors du téléversement Série, on écrase purement et simplement l’ancienne version en la remplaçant par la nouvelle. Dans le cas du téléversement OTA, on commence par compresser le fichier binaire issu de la compilation du nouveau sketch, ensuite on téléverse cette nouvelle version dans une zone disponible de la mémoire flash réservée au programme, puis on vérifie l’intégrité du fichier téléchargé à l’aide d’une somme de contrôle MD5. Si cette vérification est concluante, on décompresse la nouvelle version à l’emplacement de l’ancienne, ce qui a pour effet d’écraser celle-ci.

Pour cette raison, la taille du sketch compilé (le fichier binaire), ne doit pas excéder la moitié de la mémoire flash allouée au programme, car celle-ci contient deux versions du sketch : la version en cours et la version compressée. En théorie, on pourrait dire que la somme de la taille du binaire et de la taille du binaire compressé ne devrait pas excéder la taille disponible pour le programme, ce qui conduirait à la possibilité d’écrire des sketchs occupant plus de la moitié de la mémoire programme. Il y a cependant deux inconvénients :

  • le premier, et le plus important, est que la documentation ne précise pas si la version compressée est copiée à la fin de la mémoire programme ou à partir du milieu. Dans le premier cas, le sketch décompressé pourrait occuper plus de la moitié de la mémoire, mais pas dans le second ;
  • le deuxième inconvénient est que pour pouvoir faire la somme des deux fichiers (le binaire standard et le binaire compressé) il faut connaître leur taille, et que celle du binaire compressé n’est connue que lors du téléversement (le renseignement est affiché dans la console), donc trop tard.

Réserver deux fois la taille du sketch est donc plus simple et plus sûr, d’autant que la place ne manque pas.

V-A. Organisation de la mémoire

Le microcontrôleur ESP8266EX qui équipe le module ESP-01 ne possède pas de mémoire flash interne. En cela, d’ailleurs, l’appellation « microcontrôleur » n’est pas justifiée, car un microcontrôleur incorpore, en théorie, une mémoire programme statique sous forme de PROM, EEPROM ou, plus récemment, de mémoire flash. On va malgré tout continuer à l’appeler comme ça. Ce microcontrôleur n’a pas été conçu, à l’origine, pour être autonome, mais plutôt pour apporter la fonctionnalité Wifi à d’autres systèmes. Le voici, par exemple, implémenté par Arduino sur la carte UNO WiFi :

Image non disponible

La carte citée ci-dessus n’existe plus et je n’en parle que pour illustrer mon propos. Elle est remplacée par la carte « UNO WIFI rev.2 ».

Cette carte est architecturée autour du nouveau contrôleur 8 bits ATmega4809 de Microchip, qui remplace le contrôleur ATMega328P de chez Atmel, et embarque la puce WiFi NINA-W102 de chez u-blox en remplacement de la puce ESP8266EX de chez Espressif.

Pour acquérir cette autonomie, ce qui se justifie au regard de ses possibilités intrinsèques, il faut lui adjoindre de la mémoire non volatile pour stocker un programme. On utilise pour cela un chip mémoire flash série, comme le M25P10, avec lequel il communiquera via un bus SPI, ce protocole étant totalement transparent pour l’utilisateur final.

L’ESP8266EX peut gérer théoriquement jusqu’à 16 Mio de mémoire flash. Cela ne dépend que de la capacité du chip mémoire auquel il est connecté. En ce qui concerne l’ESP-01, comme vu plus haut, trois versions sont disponibles : une avec 512 Kio et deux avec 1 Mio ; dont seules les versions implémentant 1 Mio seront utilisables ici.

J’utilise personnellement la version 1 Mio qui dispose d’un voyant d’alimentation pour les raisons vues plus haut, mais c’est affaire de choix.

Ce tutoriel peut être adapté à toutes les versions commercialisées de l’ESP-XX, même à la version ESP-05 qui ne dispose à la base d’aucune broche GPIO, grâce à la libération de la broche Rx (GPIO3) par l’OTA.

Tout est logiciel, il n’y a rien de figé dans l’organisation de la mémoire flash et l’on peut donc imaginer nombre de structures différentes : cela demande toutefois du savoir-faire et du travail. Heureusement, des développeurs compétents nous ont concocté des bibliothèques qui s’occupent de tout ça. Ils nous laissent même la possibilité de configurer, dans une certaine mesure, la répartition de cette mémoire pour l’adapter au mieux à nos projets en jouant sur la quantité de mémoire allouée au sketch et au système de fichiers.

Nous disposons théoriquement de 1 Mio de mémoire flash. En réalité, un espace est réservé à partir de l’adresse 0xFB000, ce qui rend les vingt derniers kilooctets inexploitables par l’utilisateur final (que nous sommes). Ils sont en fait utilisés par des fichiers de configuration et des programmes « système » destinés entre autres à gérer la Wifi. Il nous reste donc environ 1004 Kio à répartir entre le sketch et un système de fichiers.

Comme nous l’avons vu, en ce qui concerne le sketch, il faut réserver au moins deux fois sa taille, car il y en aura toujours deux versions dans la mémoire flash. Quant au système de fichiers, tout dépend de l’utilisation que l’on veut en faire. Cela peut aller de zéro octet si on n’en a pas besoin, et dans ce cas le sketch peut occuper jusqu’à 502 Kio (1004 / 2), jusqu’à 512 Kio, et dans ce cas le sketch ne devra pas excéder 246 Kio ((1004 – 512) / 2).

Cette dernière configuration, qui est proposée dans le paramétrage, ne semble pas viable dans l’environnement Arduino. En effet, le sketch minimal Arduino, avec donc un setup() vide et une loop() vide, occupe déjà 255 656 octets, soit à peu près 250 kio, ce qui dépasse la limite théoriquement acceptable : l’ESP8266EX a en effet besoin d’un certain nombre de bibliothèques pour fonctionner dans l’environnement Arduino, et ces bibliothèques prennent de la place.

De plus, dans la documentation technique de l’ESP8266EX, Espressif stipule que l’OTA ne peut pas être utilisé sur les versions pourvues de seulement 512 kio de mémoire flash, soit la configuration dans laquelle on se retrouve si l’on réserve 512 kio sur 1 Mio pour le système de fichiers.

Bien que nous n’utilisions pas, dans l’immédiat, le système de fichiers, nous garderons la configuration par défaut : elle privilégie la place accordée au sketch, mais réserve suffisamment de place pour notre utilisation future de ce système de fichiers. Cela dit, à part la configuration vue ci-dessus, toutes les autres sont utilisables sans risque particulier. Il faut bien remarquer que même la configuration qui réserve 256 Kio pour le système de fichiers laisse malgré tout environ 124 Kio pour le sketch, déduction faite de la place occupée par les bibliothèques ESP8266EX, qu’il faut comparer aux 32 Kio de l’Arduino UNO. Il y a donc de quoi travailler sans trop se poser de question.

La capture suivante montre le paramétrage proposé par défaut dans l’EDI, à savoir 64 Kio de mémoire réservée au système de fichiers, et ~470 Kio de mémoire programme utilisable, soit ~940 Kio (470 × 2). Comme on l’a vu, cette quantité de mémoire réservée au sketch actif peut ne pas être une limite absolue étant donné que le sketch téléchargé est compressé.

Image non disponible

Vous avez peut-être remarqué que j’ai augmenté la vitesse de téléversement par rapport à sa valeur par défaut. Comme cela, je gagne un peu de temps, mais dans la mesure où les téléversements suivants sont censés être effectués en OTA, ce n’est pas vraiment nécessaire.

Voici, par exemple, à quoi peut ressembler la mémoire de L’ESP-01 après téléversement de notre sketch :

Image non disponible

Pour des raisons de lisibilité des textes, l’échelle n’est pas respectée, mais le principe est là :

  • la compilation de sketch.ino engendre le fichier sketch.bin ;
  • sketch.bin est compressé pour donner sketch.bin.gz ;
  • sketch.bin.gz est téléversé dans la deuxième moitié de la mémoire programme puis vérifié à l’aide d’une somme de contrôle ;
  • si la vérification est positive, sketch.bin.gz est décompressé à l’adresse 0x0000 et le programme démarre.

V-B. Mise en place de l’OTA

La gestion de l’OTA est purement logicielle. Voici donc le sketch minimal permettant d’initialiser cette gestion :

esp-ota.ino
Cacher/Afficher le codeSélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
#include <ArduinoOTA.h>

const char* ssid = "identité_du_routeur";  // Généralement, "routeur" = "box"
const char* password = "mot_de_passe_du_routeur";

void setup() 
{
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.waitForConnectResult() != WL_CONNECTED) 
  {
    delay(1000);
    ESP.restart();
  }
  ArduinoOTA.begin();
}

void loop()
{
  ArduinoOTA.handle();
}

C’est tout. Je ne sais pas ce que vous en pensez, mais il est difficile de faire plus simple. La bibliothèque ArduinoOTA s’occupe de tout, notamment de charger les bibliothèques dont on a besoin. Les étapes sont les suivantes :

  • importation de la bibliothèque ArduinoOTA ;
  • fourniture des « identifiant et mot de passe » pour la connexion Wifi au routeur (box), comme pour connecter une tablette ;
  • lancement de la procédure de connexion : cette procédure est répétée toutes les secondes jusqu’à ce que la connexion soit établie ;
  • démarrage du service OTA ;
  • utilisation des routines OTA dans la boucle principale (loop()).

Si l’on fait abstraction du code concernant la connexion Wifi proprement dite, la mise en place de l’OTA ne demande que trois lignes.

Téléversez ce code et attendez… Enfin non, n’attendez pas trop quand même. Il ne va rien se passer.

Regardez la console en bas de l’EDI :

Image non disponible

On vous demande de faire un « reset » physique « via RTS pin » (RST pin peut-être) pour que les changements soient pris en compte. Comme il n’y a pas de bouton reset implémenté sur l’ESP-01, on fait ça à la hussarde : on débranche et on rebranche.

Maintenant, vous pouvez patienter quelques secondes sans perdre inutilement votre temps : si tout s’est bien passé, vous constaterez, en déroulant le menu « Outils ⇨ Port », l’apparition d’une nouvelle catégorie de ports intitulée « Ports réseau », et un nouvel item dans cette catégorie : il s’agit, vous vous en doutez, du port que vous allez utiliser pour faire vos mises à jour OTA. Son nom est constitué du numéro d’identification de votre ESP8266, que vous connaissez déjà grâce au sketch info-esp.ino, et de l’adresse IP que lui a attribuée le routeur sur le réseau.

Image non disponible

L’appellation « Ports réseau » est discutable et est à mon avis utilisée pour faire un parallèle avec « Ports série ». Il s’agit en fait d’une URL.

Si vous ne pouvez pas changer l’adresse IP, qui est laissée à la seule initiative du routeur, vous pouvez par contre personnaliser la partie identification, de manière à retrouver plus facilement l’ESP concerné par le sketch en cours dans l’EDI, dans le cas où vous en auriez plusieurs de connectés.

Il vous suffira de saisir la ligne suivante avant la ligne ArduinoOTA.begin(); :

 
Sélectionnez
ArduinoOTA.setHostname("Bureau");

« Bureau » étant bien entendu un exemple. Dans ce cas, l’intitulé du port devient Bureau at 192.168.1.37.

V-C. Mise à jour OTA

Comme nous n’avons pas encore téléversé de sketch, à part bien sûr celui concernant la mise en place de l’OTA, ce que nous allons faire maintenant n’est pas, stricto sensu, une mise à jour. Cependant, en pratique, il n’y a aucune différence.

Le code vu dans le chapitre précédent fera à présent toujours partie de votre sketch. La mise en place doit impérativement être renouvelée à chaque écriture, car le code en cours va être écrasé par le nouveau, avec toutes ses fonctionnalités, y compris l’OTA.

Ce code a été une première fois envoyé via la liaison série, c’était la seule disponible, et il va à partir de maintenant être acheminé via l’OTA puisque celle-ci est opérationnelle. Si vous l’oubliez, votre mise à jour fonctionnera, mais vous ne bénéficierez plus de l’OTA. Ce n’est pas dramatique dans la mesure où on peut recommencer la manipulation en utilisant le port série, mais si ça vous impose un démontage de l’ESP, c’est ennuyeux. Ce n’est pas le but de la manœuvre.

Pour que l’on parle bien de la même chose, maintenant que vous avez le « squelette » OTA en place (que vous pouvez d’ailleurs sauvegarder dans un fichier appelé par exemple template‑ota.ino), le mot sketch ne concernera plus que ce que vous auriez écrit si vous n’utilisiez pas l’OTA. Et en l’occurrence, vous écrirez vos sketchs exactement comme d’habitude.

Pour faire simple et pour revenir à la tradition, nous allons faire clignoter une LED. Réalisez le montage suivant, ou du moins quelque chose d’analogue :

Image non disponible

et téléversez le code que voilà :

maj-ota.ino
Cacher/Afficher le codeSélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
/***** Include et  déclarations OTA ***********************/
#include <ArduinoOTA.h>
const char* ssid = "identité_du_routeur";
const char* password = "mot_de_passe_du_routeur";
/**********************************************************/

// Déclarations du sketch
int led = 2;
unsigned long reference = 0;

void setup()
{
  // Setup du sketch
  pinMode(led, OUTPUT);



  /***** Setup OTA ****************************************/
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.waitForConnectResult() != WL_CONNECTED)
  {
    delay(1000);
    ESP.restart();
  }
  ArduinoOTA.begin();
  /********************************************************/
}


void loop()
{
  /***** Procédure OTA ************************************/
  ArduinoOTA.handle();
  /********************************************************/

  // Sketch
  unsigned long instant = millis();
  if (instant - reference >= 500)
  {
    reference = instant;
    digitalWrite(led,  ! digitalRead(led));
  }
}

Si votre LED est bien élevée, elle devrait clignoter.

Peut-être vous demandez-vous pour quelle raison je n’utilise pas la procédure delay() pour réaliser le clignotement, comme elle est utilisée dans le sketch « blink.ino ». Ce n’est, bien entendu, pas pour le plaisir de compliquer le code.

La fonction ArduinoOTA.handle()a pour but de répondre à une requête OTA, émise généralement lors d’une demande de mise à jour. Pour cette raison, elle est placée dans la boucle principale qui l’appelle en permanence, car la requête peut arriver n’importe quand.

Lors de l’utilisation de la procédure delay(), le déroulement du programme est bloqué pendant le temps paramétré, ce qui fait que, si la requête arrive pendant ce temps-là, elle sera ignorée, et la mise à jour ne pourra pas s’effectuer.

Donc, à retenir : il ne faut pas utiliser de procédure bloquante quand on utilise l’OTA.

Ne soyez pas étonné si le résultat n’est pas immédiat. Le code que vous venez de téléverser doit d’abord être vérifié puis, seulement si le résultat est conforme, il va être décompressé à la place de l’ancienne version. Ces opérations prennent du temps. Prévoyez environ vingt-cinq secondes.

Dans la capture suivante, les zones grisées représentent le code auquel vous ne devez pas toucher, du moins si vous désirez conserver les fonctionnalités OTA. Vous ne vous en occupez plus : il fait partie des meubles. Pour le reste, vous faites ce que vous voulez.

Image non disponible

V-D. Utilisation standard de la WiFi

On peut s’interroger quant à la possibilité d’utiliser la WiFi dans nos sketchs, alors qu’on sait qu’elle est utilisée par l’OTA : c’est évidemment possible, heureusement. L’OTA ne vous limite en rien, et mis à part les quelques lignes nécessaires à son fonctionnement, vous n’avez rien à changer à vos habitudes de travail.

Voici par exemple un sketch permettant de télécommander l’allumage d’une LED depuis un navigateur, adapté librement, pour l’OTA, du sketch « WiFiManualWebServer.ino » que vous trouverez dans le menu Fichier ⇨ Exemples ⇨ ESP8266WiFi. Ce sketch utilise le même montage que le sketch précédent.

serveur-wifi-ota.ino
Cacher/Afficher le codeSélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
/***** Include et  déclarations OTA ***********************/
#include <ArduinoOTA.h>
const char* ssid = "identité_du_routeur";
const char* password = "mot_de_passe_du_routeur";
/**********************************************************/

// Déclarations du sketch

WiFiServer serveur(80);

const int led = 2;
const int ledTx = 1;


void setup()
{
  // Setup du sketch
  pinMode(ledTx, OUTPUT);
  digitalWrite(ledTx, HIGH);

  /***** Setup OTA ****************************************/
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.waitForConnectResult() != WL_CONNECTED)
  {
    delay(1000);
    ESP.restart();
  }
  ArduinoOTA.begin();
  /********************************************************/

  serveur.begin();
  
  // La led émet 5 flashes pour avertir de la fin de la mise à jour
  for (int i = 0; i < 5; i++)
  {
    digitalWrite(ledTx, LOW);
    delay(100);
    digitalWrite(ledTx, HIGH);
    delay(300);    
  }
}


void loop()
{
  /***** Procédure OTA ************************************/
  ArduinoOTA.handle();
  /********************************************************/

  // Sketch
  WiFiClient client = serveur.available();
  if (!client) return;
  client.setTimeout(1000);
  String reception = client.readStringUntil('\r'); // On ne lit que la première ligne
  while (client.available()) client.read(); // puis on vide le buffer
  // On traite la requête  
  if (reception.indexOf(F("?ON")) != -1) digitalWrite(led, HIGH);
  else digitalWrite(led, LOW);
  // On envoie la réponse
  client.println(F("HTTP/1.1 200 OK"));
  client.println(F("Content-Type: text/html"));
  client.println("");
  client.println(F("<!DOCTYPE HTML>"));
  client.println(F("<html>\n"));
  client.println(F("<meta charset='utf-8'/>\n"));
  client.println(F("<body>"));
  client.print(F("\t<p>La LED est "));
  if (digitalRead(led) == HIGH) client.print(F("allumée !"));
  else client.print(F("éteinte !"));
  client.println("</p>");
  client.print(F("\t<p>Cliquez <a href='?ON'>ici</a> pour allumer la LED, ou <a href='?OFF'>ici</a> pour l'éteindre.</p>"));
  client.println(F("</body>\n"));
  client.print(F("</html>"));
}

Lors de la mise au point d’un sketch, on est amené à faire des téléversements fréquents. Utiliser la procédure OTA ne change rien à cet état de fait. Or, comme vu plus haut, une fois le téléversement OTA effectué, ce dont l’EDI nous fait part, le sketch n’est pas immédiatement opérationnel. C’est pour cette raison que j’ajoute les lignes suivantes :

 
Sélectionnez
  for (int i = 0; i < 5; i++)
  {
    digitalWrite(ledTx, LOW);
    delay(100);
    digitalWrite(ledTx, HIGH);
    delay(300);    
  }

destinées à faire clignoter la LED bleue à la fin du setup().

De cette manière, je suis averti du moment où je peux commencer à utiliser mon dispositif. Cela peut sembler superflu au premier abord, mais je vous assure qu’au deuxième « rabord », c’est bien pratique, et ça permet en plus de donner une utilité à cette LED.

V-E. Quelques précisions

  • La durée d’une mise à jour peut facilement dépasser les trente secondes. Elle commence avec la compilation, puis continue avec la compression, le téléversement, la vérification, la décompression et le redémarrage. Soyez patient.
  • Quand vous effectuez une mise à jour OTA, votre module peut très bien, et c’est l’intérêt, être en fonction en dehors de votre environnement immédiat : vous ne savez donc pas forcément ce qu’il est en train de faire. Or, l’exécution du programme en cours peut être interrompue pendant quelques dizaines de secondes, en fonction de la taille du code. Si le traitement de l’action en cours dépend de cette exécution, il peut être judicieux de veiller soit à l’achèvement préalable de cette action si elle est critique, soit à la reprise de son traitement par la nouvelle version au lancement de celle-ci.
  • Utilisation de la broche GPIO 1 :

    • son usage standard est la connexion Tx de l’UART ;
    • la LED intégrée est reliée à cette sortie, mais ne peut pas être invoquée en tant que LED_BUILTIN. On y accède avec son numéro GPIO (1). À noter qu’elle est allumée à l’état bas ;
    • la broche en elle-même ne semble pas utilisable en tant que broche GPIO.
  • Utilisation du reset matériel (mise à l’état bas de la broche RST) :

    • déconseillé par Espressif au profit de l’utilisation de la broche EN ;
    • à proscrire en cas d’utilisation de l’OTA : le chip ne redémarre pas.
  • Broche EN : pour un fonctionnement standard du module, la broche EN doit être maintenue à l’état haut (3,3 V). En positionnant cette broche à l’état bas, on met le microcontrôleur à l’état de veille, c’est-à-dire en état de consommation minimale d’énergie. Le déroulement du programme est arrêté. Cette broche ne doit pas rester « en l’air », et sera donc généralement connectée au VCC par l’intermédiaire d’une résistance de tirage (typiquement 10 kΩ), ce qui permettra la mise à la masse à l’aide d’un bouton en cas de besoin (reset).

VI. Le système de fichiers

Comme vous avez pu le constater précédemment, la quantité de mémoire flash allouée au microprogramme utilisateur de l’ESP-01 peut être modulée en fonction des besoins. Typiquement, sur le mégaoctet de mémoire disponible, environ 750 kio sont utilisables ce qui dépasse largement la taille moyenne d’un sketch, surtout quand on est habitué à tout faire tenir dans les 32 kio du contrôleur ATmega328 qui équipe un Arduino UNO. Bien que la donne soit différente si vous utilisez l’OTA, et quand vous aurez commencé, vous ne pourrez plus vous en passer, c’est du moins mon cas, vous aurez malgré tout de 400 à 500 kio de mémoire inemployée, en fonction de la taille de votre sketch.

Vous pouvez exploiter cette mémoire en y créant un système de fichiers dans lequel vous pourrez :

  • copier des fichiers depuis votre PC à l’aide d’un utilitaire installé dans l’EDI Arduino ;
  • accéder à ces fichiers en lecture ou en écriture depuis votre sketch ;
  • créer et manipuler des fichiers depuis votre sketch ;
  • en bref, faire comme si vous aviez un lecteur de carte microSD et la bibliothèque SdFat, en tenant compte toutefois de la différence de capacités, lesquelles ne sont pas comparables.

VI-A. Le système de fichiers SPIFFS

Je cite le système de fichiers SPIFFS (SPI Flash File System) pour la forme, car nous ne l’utiliserons pas. Il fonctionne très bien et est parfaitement adapté aux espaces mémoire et aux fichiers de taille réduite en raison de la petite taille de ses clusters (256 octets). De plus, c’est le système de fichiers « historique » et c’est celui que j’utilise (ou du moins que j’utilisais jusqu’à présent). Malheureusement, son évolution est en stand by et il va probablement être supprimé dans les prochaines versions du gestionnaire de cartes ESP8266, au profit du système LittleFS plus performant et activement maintenu. Il est donc préférable, pour des raisons de pérennité, de passer au petit nouveau.

Pour info, le système de fichiers SPIFFS est toujours présent dans la version 2.7.4 qui est actuellement la dernière version.

VI-B. Le système de fichiers LittleFS

Réputé pour être plus rapide que le SPIFFS dans la plupart des cas, il implémente en outre une véritable arborescence avec gestion des répertoires. Son inconvénient majeur pour l’utilisation dans une configuration modeste, comme celle de l’ESP-01, est la taille de ses clusters : 4 kio. À part ça, son utilisation est pratiquement identique à celle du SPIFFS et le passage de l’un à l’autre ne pose aucun problème.

VI-B-1. Installation de ESP8266LittleFS

Il va falloir, dans un premier temps, « installer » l’outil de téléversement du système de fichiers dans l’EDI Arduino. Je mets « installer » entre guillemets, car il s’agit en réalité d’une simple copie de fichier dans un répertoire spécifique.

Commencez dans un premier temps par télécharger sur Github la dernière version du fichier ESP8266LittleFS-x.y.z, actuellement ESP8266LittleFS-2.6.0, puis décompressez-la dans le répertoire /tools qui se trouve dans la racine du répertoire d’installation de l’EDI Arduino que vous utilisez. Si ce répertoire (/tools) n’existe pas, ce qui peut être le cas si vous n’avez pas encore installé d’outil externe, créez-le.

N’hésitez pas à vérifier ici que la procédure d’installation n’a pas changé, on ne sait jamais.

Vous devriez obtenir une arborescence de ce genre :

/home/user/../arduino-1.8.12/tools/ESP8266LittleFS/tool/esp8266littlefs.jar

en admettant que le répertoire de votre version courante d’Arduino s’appelle /arduino‑1.8.12. Lors de futures mises à jour, il vous suffira de remplacer le fichier esp8266littlefs.jar par la nouvelle version.

Ouvrez l’EDI Arduino ou relancez-le s’il était déjà ouvert puis déroulez le menu « Outils ». L’entrée ESP8266 LittleFS Data Upload doit s’y trouver :

Image non disponible

Vous pouvez remarquer, juste en dessous, l’entrée ESP8266 Sketch Data Upload qui correspond au même outil, mais pour le système de fichiers SPIFFS.

VI-B-2. Téléversement des fichiers

Votre outil de téléversement est prêt à être utilisé, voici son mode d’emploi :

  • chargez un sketch dans l’EDI : n’importe quel sketch conviendrait, mais il est plus logique de charger celui qui utilisera le système de fichiers que vous allez mettre en place ;
  • dans le dossier de ce sketch, créez le dossier /data ;
  • dans le dossier /data, copiez les fichiers que vous voulez transférer sur votre ESP-01, en utilisant l’arborescence qui vous convient, le nom proprement dit de chaque fichier ou dossier, indépendamment de son chemin, étant limité à 31 caractères, suffixe inclus .

Vous devez considérer le dossier /data comme étant la racine du système de fichiers que vous allez créer dans la mémoire de votre ESP-01.

Depuis votre sketch, vous pourrez invoquer les fichiers se trouvant à la racine avec ou sans le préfixe « / », c’est-à-dire que le fichier /data/fichier sera invoqué indifféremment sous la forme fichier ou /fichier ; par contre, les fichiers se trouvant dans des sous-répertoires, comme /data/chemin/fichier, seront invoqués classiquement, c’est-à-dire sous la forme /chemin/fichier.

Le nombre de fichiers et de répertoires n’est limité que par la quantité de mémoire attribuée au système de fichiers dans votre paramétrage.

À partir de maintenant, de deux choses l’une :

N’oubliez pas également de vérifier que la bonne carte est sélectionnée : c’est arrivé à des gens très biens de téléverser sur la mauvaise carte.

Il ne vous reste plus à présent qu’à cliquer sur Outils ⇨ ESP8266 LittleFS Data Upload et le téléversement du système de fichiers commence. Une autre différence notable entre les deux modes de téléversement réside dans la différence sensible des durées de transfert, à l’avantage indéniable de l’OTA.

À ce stade, il faut bien prendre en compte que vous téléversez l’image du système de fichiers contenu dans votre dossier data, et que cette image va écraser le système fichiers, s’il existe, déjà présent dans la mémoire flash. Il n’est pas possible avec cette méthode d’ajouter individuellement, depuis un PC, un fichier (ou dossier) à un système de fichiers existant.

Par contre, bien entendu, le sketch n’est quant à lui pas affecté par cette opération. Les deux emplacements mémoire sont distincts l’un de l’autre.

VII. Application exemple

Maintenant qu’on en sait un peu plus sur ces deux techniques, on va les mettre en œuvre dans une petite application qui pourra éventuellement servir de squelette pour des applications plus sophistiquées.

VII-A. Préparation

Commencez par réaliser ce montage (ou un montage équivalent) :

Image non disponible

À l’emplacement qui vous conviendra le mieux, créez le dossier /meteo. Dans ce dossier, créez un fichier texte vide, nommez-le meteo.ino et copiez dedans le sketch suivant :

meteo.ino
Cacher/Afficher le codeSélectionnez

Pour la suite, créer le fichier toto.ino signifiera créer un fichier texte vide et le nommer toto.ino.

Toujours dans le dossier /meteo, créez le dossier /data et ouvrez-le. Dans ce dossier :

  • créez le fichier meteo.htmlet copiez dedans le code suivant :
meteo.html
Cacher/Afficher le codeSélectionnez
  • créez le fichier tCadran.js et copiez dedans le code suivant :
tCadran.js
Cacher/Afficher le codeSélectionnez
  • créez le fichier ajax.js et copiez dedans le code suivant :
ajax.js
Cacher/Afficher le codeSélectionnez
  • créez le fichier thermo.js et copiez dedans le code suivant :
thermo.js
Cacher/Afficher le codeSélectionnez
  • créez le fichier hygro.js et copiez dedans le code suivant :
hygro.js
Cacher/Afficher le codeSélectionnez

Cette application est fournie à titre d’exemple pour illustrer ce que l’on a vu dans cet article. Je ne vais donc pas la détailler, car ce n’est pas le sujet de ce tutoriel. Vous trouverez l’explication des mécanismes liés au fonctionnement du serveur et du client dans les tutoriels :

VII-B. Téléversements

Vous avez deux téléversements à effectuer : le sketch et les fichiers contenus dans le répertoire /data. Vous pouvez bien entendu effectuer ces deux téléversements dans l’ordre qui vous convient, mais comme vous ne disposez pas encore de la fonctionnalité OTA, il est préférable de téléverser d’abord le sketch, en utilisant le port série, pour mettre en même temps cette fonctionnalité en place. Comme cela, dans un deuxième temps, vous pourrez téléverser le système de fichiers en utilisant l’OTA.

La marche à suivre est simple :

C’est tout. Toutes vos prochaines mises à jour, que ce soit pour le sketch ou pour le système de fichiers se feront via l’OTA.

VII-C. Connexion

Ouvrez votre navigateur préféré et connectez-vous à l’adresse que vous a attribuée votre routeur DHCP et que vous avez utilisée pour le téléversement OTA. Vous devriez obtenir quelque chose qui ressemble à ceci :

Image non disponible

Chacun de ces deux cadrans représente une instance de l’objet TCadran (Type Cadran) implémenté dans le fichier JavaScript tCadran.js. La meilleure place pour l’appel de ce fichier est l’entête du fichier HTML, mais ce n’est pas obligatoire. Il suffit qu’il soit appelé avant la (ou les) demande(s) de création d’une instance de cet objet.

Pour cette réalisation, le code de création de ces deux instances se trouve respectivement dans les fichiers thermo.js et hygro.js. L’appel de ces deux fichiers se fait dans la section <body></body> du fichier HTML, à l’emplacement où l’on souhaite dessiner chaque cadran. La personnalisation des cadrans se fait dans ces fichiers en modifiant les paramètres. N’hésitez pas à le faire.

Pour tester les modifications, il faut pouvoir afficher facilement les cadrans. Il est hors de question de téléverser les fichiers à chaque fois : cela deviendrait rapidement pénible.

Dans votre dossier /data, modifiez la dernière ligne de ces deux fichiers comme suit :

 
Sélectionnez
});

devient :

 
Sélectionnez
}).dessineCadran();

En faisant cela, vous lancerez la procédure dessineCadran() de l’objet instancié en début de fichier, dont la fonction est de dessiner le cadran en suivant le paramétrage contenu dans le fichier, à chaque fois que ce fichier sera invoqué, c’est-à-dire à chaque fois que vous ouvrirez (ou actualiserez) le fichier HTML dans votre navigateur. Bien entendu, dans cette configuration, il n’y aura pas de mise à jour de l’affichage, et la valeur indiquée correspondra à la valeur saisie à la ligne :

 
Sélectionnez
4.
  mesure          : 22.5,

valeur que vous pouvez également modifier pour vos essais.

Une fois le résultat désiré obtenu, restaurez la dernière ligne à sa valeur originale et téléversez votre système de fichiers.

VIII. Conclusion

Merci d’avoir prêté intérêt à ce tutoriel. J’espère qu’il aura pu vous être utile. Vous trouverez le dossier /meteo et tout ce qu’il contient prêts à l’emploi dans cette archive.

Je n’ai, à l’évidence, pas traité toutes les fonctionnalités offertes par la bibliothèque ArduinoOTA, notamment celles liées à la sécurité. Il en est de même pour la bibliothèque LittleFS, et ses nombreuses méthodes de manipulation des fichiers.

Pour aller plus loin, je vous engage à consulter les documentations suivantes :

IX. Remerciements

Mes remerciements vont à f-leb pour ses observations et conseils techniques, ainsi qu’à Claude Leloup pour sa relecture orthotypographique.