C'est très bien tout ça, mais pour que ça tourne il faut quand même écrire un peu de code.
Je vais abréger sur toutes les conneries que j'ai pu faire, mais j'ai fini par faire du Rust sur l'ESP32 et du TinyGo sur le nRF52840. Après avoir beaucoup galéré à envoyer des données en HTTP avec les commandes AT idoines (d'abord avec les commandes HTTP(S) puis avec les commandes commandes TCP/IP) j'ai fini par faire du PPP pour pouvoir utiliser les bibliothèques HTTP déjà existantes sans trop avoir à gérer les détails de la communication avec le modem. Je pense que ça aurait pu marcher si je n'avais eu que des petits messages à transmettre, mais pour des images de quelques centaines de kilooctets ce n'était pas assez fiable.
Utiliser du PPP ça veut dire que le modem EG800K est out puisque même si la fiche indique que le PPP est supporté "optionnellement", en pratique c'est non. Quectel ne propose pas de support aux utilisateurs finaux, à part un forum où on peut demander des trucs, mais un employé m'a juste envoyé la dernière version du firmware (c'est déjà bien) mais qui ne supporte pas le PPP (et que je ne peux pas flasher sous Linux). Par contre, ça veut dire que je peux plus facilement supporter d'autres modems, comme le A7670 de Simcom.
Au départ, il était prévu que l'ESP32 indique au nRF52840 quand se mettre en veille à l'aide d'une connexion dédiée, deux GPIO connectés, mais finalement puisqu'ils sont tous les deux déjà connectés en I2C, j'ai fini par faire du nRF52840 un « esclave » I2C, ça permet d'avoir un protocole déjà établi pour faire passer des informations (comme la durée de la mise en veille).
Comme j'ai pas encore beaucoup d'expérience en Rust, j'ai souvent demandé de l'aide à des LLM, ça aide pas mal tant qu'on comprend assez bien ce qu'ils font pour les remettre sur les rails quand ils commencent à délirer. Et puis autant profiter pour mon propre usage d'une petite partie des milliards de dollars dont ils disposent, après tout (je n'ai rien payé, j'ai seulement utilisé les offres gratuites même si il a parfois fallu plusieurs jours de "please go on, you have new tokens available" à Claude pour finir d'analyser des problèmes que j'avais du mal à résoudre moi-même).
Le code (actuel, en tout cas celui que j'ai pensé à pousser sur GitHub, donc pas forcément adapté au PCB du billet précédent) Rust est ici sur Github.
Pour le TinyGo c'est bien plus simple, à la fois parce que le rôle du nRF52840 est plus limité et parce que le Go en général est plus simple que le Rust quand on a juste une expérience générale des autres langages communs (et puis je contribue de temps en temps à Photoprism et à Gonic donc je connais déjà).
J'aurais voulu faire du Rust sur le nRF52840, mais malgré des posts détaillés et et des projets de démo je ne suis pas parvenu à un truc qui marchait, peut-être aussi parce que le SuperMini nRF52840 et le Seed XIAO utilisent un bootloader qui n'est pas vraiment compatible avec probe-rs et qu'il faudrait programmer le microcontrolleur directement avec une sonde de debug que j'ai, mais chiante à connecter puisque ça passe là aussi par des pogo pins, bref j'ai arrêté là.
Le code TinyGo est là, en deux versions (Seeed XIAO et nicenano/nRFMicro).