Héberger un site web sur une cigarette électronique jetable
(bogdanthegeek.github.io)- Projet expérimental consistant à faire tourner un serveur web à l’aide du microcontrôleur ARM Cortex-M0+ peu puissant intégré dans une cigarette électronique jetable
- Analyse de la puce PY32F002B de PUYA, dotée de 24 Kio de flash et 3 Kio de RAM, avec mise en œuvre d’une connexion réseau en mode SLIP
- Portage des communications TCP/IP et des fonctions de serveur HTTP via un tty virtuel à l’aide du semihosting, du protocole SLIP et de la pile TCP/IP uIP
- Le système était au départ très lent, mais l’optimisation des buffers et l’amélioration du traitement des données ont fortement accru la réactivité et la vitesse de chargement des pages
- Même dans un environnement à très faible mémoire, il a été possible d’exécuter du code serveur dynamique et de fournir des endpoints API
- Le code est publié ; un hébergement réel est possible, mais les ressources comme la mémoire restent très limitées
Introduction
- L’auteur précise d’abord que cet article n’est pas servi directement par le serveur web tournant sur la cigarette électronique jetable, mais qu’un autre serveur fournit le même contenu
- Un exemple de fonctionnement réel est visible sur http://ewaste.fka.wtf/
Contexte
- Depuis plusieurs années, l’auteur récupère des cigarettes électroniques jetables auprès de connaissances afin de recycler les batteries
- Il s’est récemment intéressé au fait que ces appareils deviennent de plus en plus sophistiqués, avec l’apparition de USB-C et de batteries rechargeables
- En les démontant, il a découvert un microcontrôleur ARM Cortex-M0+ avec flash intégrée de marque PUYA, une puce bien connue dans le monde des microcontrôleurs à bas coût
- Il a collecté ces microcontrôleurs sur plusieurs modèles, et leur analyse est facilitée par la présence d’un étiquetage des broches de débogage
Matériel utilisé
- Le marquage de la puce était
PUYA C642F15, mais il s’agirait en réalité d’un modèle de la famille PY32F002B - Caractéristiques principales :
- cœur Cortex-M0+ à 24 MHz
- 24 Kio de flash
- 3 Kio de RAM
- plusieurs périphériques sont présents, mais non utilisés dans ce projet
- Les performances sont faibles par rapport à un smartphone classique, mais dans un environnement embarqué, il est tout à fait possible de construire un serveur web minimal
Connexion réseau
- Ce n’était pas l’idée de départ, mais l’auteur a eu l’idée de faire tourner un serveur web en expérimentant le concept de semihosting
- Le semihosting est une méthode permettant de simuler des appels système sur un système ARM embarqué
- en plaçant des valeurs/pointeurs dans les registres puis en déclenchant un breakpoint, le débogueur interprète cela et exécute l’opération demandée
- il sert généralement à transmettre des logs, mais permet aussi une communication bidirectionnelle
- Les périphériques USB série prennent en charge le protocole SLIP (Serial Line Internet Protocol), qui a été exploité comme interface réseau
- Sous Linux (et certains macOS), un environnement réseau SLIP via tty virtuel a été mis en place avec
slattachetsocatpyocd gdb -S -O semihost_console_type=telnet -T $(PORT) $(PYOCDFLAGS) & socat PTY,link=$(TTY),raw,echo=0 TCP:localhost:$(PORT),nodelay & sudo slattach -L -p slip -s 115200 $(TTY) & sudo ip addr add 192.168.190.1 peer 192.168.190.2/24 dev sl0 sudo ip link set mtu 1500 up dev sl0 - La pile TCP/IP retenue est uIP, très légère, ne nécessitant pas de RTOS et facile à porter
- Parmi les exemples fournis avec uIP, l’auteur a utilisé le serveur HTTP et a porté le code SLIP au mode semihosting, réussissant ainsi à démarrer le serveur web
- L’architecture ARM posait un problème d’alignement 16 bits, ce qui a conduit à modifier le script de génération du filesystem et à effectuer une conversion en Perl
Optimisation des performances
- Au départ, le système affichait une réponse très lente : ping à 1,5 s, 50 % de perte de paquets, et plus de 20 secondes pour charger une page
- La cause venait du surcoût important des entrées/sorties au byte
- En exploitant activement les 3 Kio de RAM, un ring buffer a été ajouté afin de fournir les données par lots aux fonctions SLIP
- Les écritures ont elles aussi été regroupées pour le transfert, permettant un nettoyage rapide
- Après optimisation : ping à 20 ms, aucune perte, chargement des pages en 160 ms
- Utilisation totale de la RAM et de la flash :
- flash : 5 116 B sur 24 KB (20,82 %)
- RAM : 1 380 B sur 3 KB (44,92 %)
- La capacité est suffisante pour servir l’ensemble du contenu du blog sans difficulté, et il est même possible d’exécuter du code C côté serveur
Autres fonctions et conclusion
- Des endpoints API ont été implémentés directement pour renvoyer le nombre de requêtes sur la page principale ainsi que l’identifiant unique du microcontrôleur
- Il s’agit d’une expérimentation montrant qu’il est possible d’implémenter jusqu’à un serveur web dynamique et une API sur un matériel extrêmement limité avec un minimum de mémoire
Aucun commentaire pour le moment.