J'avance lentement mais surement dans le code qui permettra de faire fonctionner tout le diorama.
Et je me heurte à un problème que j'avais déjà rencontré quand je codais sur Arduino: l'espace mémoire !
Je continue toutefois d'avancer dans ma programmation, et voici un aperçu de ce que cela donne.
Le fonctionnement des écrans
L'écran principal est à gauche. Le secondaire est à droite.
Toutes les actions sont définies selon les menus et les réglages qu'on réalise sur l'écran principal.
Quand à l'écran secondaire, il n'est là que pour afficher des informations utiles selon le contexte.
Par exemple, en mode autonome, l'écran principal n'a pas lieu d'afficher quoi que ce soit.
En revanche, l'écran secondaire va afficher toutes les attractions, si elles sont ouvertes, fermées, si un cycle de fonctionnement est en cours, etc...
En mode manuel, l'écran principal permettra de contrôler les paramètres d'une attraction, et l'écran secondaire affichera ses 'constantes' (moteur tournant ? Leds allumées ? ...)
En mode maintenance, l'écran principal proposera différentes options de gestion de toutes les attractions.
Dans ce cas, l'écran secondaire affichera les données techniques de toute la maquette (tensions, courants, disponibilités des ESP...)
Dans ce mode, l'écran principal peut également définir la maintenance d'une attraction spécifique.
L'écran secondaire se focalisera alors sur cette attraction, pour en afficher les données techniques (modèle de moteur, nombre de leds, état du moteur, des leds, tensions, courants...)
Soucis de mémoire !
Les ESP32 classiques disposent d'une mémoire flash de 4Mb.
Lorsqu'on compile le code qu'on crée (sur Arduino ou bien ESPHome), y sont inclues toutes les librairies nécessaires pour que le code fonctionne.
Et ces librairie peuvent prendre pas mal de place.
Même si je délègue la plus grande partie possible du travail à Home Assistant, il me faut, sur chaque ESP, programmer:
- Les écrans d'affichage
- Les capteurs (sensor):
- De l'état de toutes les attractions
- Des ESP moteur de chaque manège
- Des ESP lumières de chaque manèges (il y en a plusieurs par manège)
- Des automatismes Home Assistants
- Les lectures / publications MQTT pour tout le monde
- Les conditions d'état de tous ces capteurs, et les actions à mener selon l'état
Voici un schéma récapitulatif:
Alors que je n'en suis qu'à environs 30% du code total, la mémoire flash des deux écrans est déjà remplie à 90 %.
Mathématiquement, ça ne sera pas jouable avec cet espace mémoire.
Car même si les librairies utilisent au bas mot 40% de la mémoire (1.6Mb), il y a donc 50% qui est actuellement utilisé pour mon code (2Mb).
Selon mes calculs, mon code demandera 7 Mb de donnée.
On arrive au final autour de 225% d'espace à provisionner par rapport à ce que l'ESP actuel peut accueillir sur chaque écran (en tenant compte d'éventuelles autres librairies nécessaires).
Et je ne tiens pas compte de la sollicitation du processeur, qui risque de galérer pour tout traiter, quand bien même j'avais suffisamment d'espace mémoire.
Pour ne pas arranger les choses, j'ai utilisé des écrans "tout intégré".
Pour chaque écran, la puce ESP32 est directement soudée sur un PCB juste derrière.
C'est donc un kit complet, ESP + connecteurs + écran.
Naturellement, si je dois changer l'ESP, je dois donc changer également l'écran.
L'écran principal est un modèle ESP32-3248S035
L'écran secondaire est un modèle ESP32-2432S028
En soi, ce n'est pas vraiment un problème, car j'ai des écrans 'seuls' que je peux raccorder à un ESP, et ceux que j'utilise actuellement seront certainement utiles pour de futurs projets (j'ai déjà ma petite idée).
La question est: Existe t-il des ESP qui disposent d'un espace mémoire plus important ?
Et la réponse est OUI. Il existe 3 grandes familles d'ESP qui me sont utiles:
- ESP8266 : Généralement équipé de 4 MB de mémoire flash.
- ESP32 : Souvent disponible avec 4 MB de flash, mais certaines versions peuvent aller jusqu'à 16 MB (comme l'ESP32-WROOM-32D).
- ESP32-WROVER : Ce module contient non seulement 16 MB de mémoire flash mais aussi 4 MB de PSRAM, ce qui est utile pour des applications plus complexes (comme les interfaces graphiques avec LVGL).
Le dernier modèle m'intéresse particulièrement, car mon code utilise justement du LVGL.
Le doux nom technique de cet ESP est: ESP32-S3-WROOM-1-N16R8.
Ses caractéristiques sont très intéressantes, notamment au niveau du processeur, qui lui aussi, est plus puissant (j'ai souligné ce qui m'intéresse le plus, et dont j'aurais besoin pour le projet):
- CPU and On-Chip Memory
• ESP32-S3 series of SoCs embedded, Xtensa®
dual-core 32-bit LX7 microprocessor (with single
precision FPU), up to 240 MHz
• 384 KB ROM
• 512 KB SRAM
• 16 KB SRAM in RTC
• Up to 16 MB PSRAM
Wi-Fi
• 802.11 b/g/n
• Bit rate: 802.11n up to 150 Mbps
• A-MPDU and A-MSDU aggregation
• 0.4 µs guard interval support
• Center frequency range of operating channel:
2412 ~ 2484 MHz
Bluetooth
• Bluetooth LE: Bluetooth 5, Bluetooth mesh
• Speed: 125 Kbps, 500 Kbps, 1 Mbps, 2 Mbps
• Advertising extensions
• Multiple advertisement sets
• Channel selection algorithm #2
• Internal co-existence mechanism between Wi-Fi
and Bluetooth to share the same antenna
Peripherals
• GPIO, SPI, LCD interface, Camera interface,
UART, I2C, I2S, remote control, pulse counter,
LED PWM, full-speed USB 2.0 OTG, USB
Serial/JTAG controller, MCPWM, SDIO host,
GDMA, TWAI® controller (compatible with ISO
11898-1), ADC, touch sensor, temperature
sensor, timers and watchdogs
Integrated Components on Module
• 40 MHz crystal oscillator
• Up to 16 MB Quad SPI flash
Antenna Options
• On-board PCB antenna (ESP32-S3-WROOM-1)
• External antenna via a connector
(ESP32-S3-WROOM-1U)
Operating Conditions
• Operating voltage/Power supply: 3.0 ~ 3.6 V
• Operating ambient temperature:
– 65 °C version: –40 ~ 65 °C
– 85 °C version: –40 ~ 85 °C
– 105 °C version: –40 ~ 105 °C
Certification
• RF certification
• Green certification: RoHS/REACH
Test
• HTOL/HTSL/uHAST/TCT/ESD
Ce modèle répond à toutes mes problématiques.
Si c'est concluant, alors il me faudra basculer sur de nouveaux écrans. Ca demandera quelques petits ajustements dans le code (en fait, la configuration du touchscreen pour l'écran principal), mais c'est tout à fait gérable.
A terme, je pense que je ferais réaliser une carte PCB qui permettra d'un coté d'enficher l'écran, et de l'autre l'ESP.
Ce sera plus propre.
Reste à savoir si ESPHome voudra bien l'utiliser... La suite donc, dès que j'aurais reçu l'ESP.