Pourquoi quitter le Raspberry Pi
À l'usage quotidien, le Raspberry Pi a ses limites. Il est cher, il consomme beaucoup, il démarre lentement, et il fait tourner un système d'exploitation complet pour ce qui reste, au fond, un lecteur audio piloté par NFC. C'est trop, pour ce que ça fait.
Après quelques recherches et de précieux conseils, j'ai fini de me convaincre de mettre la version Raspberry Pi en pause pour me focaliser sur le développement de la version ESP32. Plus simple, beaucoup moins cher, consommation très basse, et surtout, un contrôle total sur ce qui tourne. Pas d'OS, pas de mises à jour qui cassent des pilotes, pas de couches d'abstraction inutiles. Juste l'application, directement sur le micro-contrôleur.
Ce n'était pas un choix facile. Je travaillais depuis un bon moment sur la version Python et j'étais occupé à fixer les bugs, seulement cette partie commençait à s'éterniser, alors qu'en parallèle je me rendais compte que l'ESP32 était plus intéressant pour la suite. Je voulais trouver le juste milieu entre finir ce que j'avais commencé et abandonner un projet en cours.
Le choix s'est imposé tout seul.
Réécrire toute la codebase
Le problème, c'est qu'on ne porte pas du Python sur un ESP32. Il a fallu tout reprendre en C++. Et je ne connaissais pas le langage.
print("Hello, World!")#include <iostream>
int main() {
std::cout << "Hello, World!\n";
return 0;
}C'était un défi énorme. Le C++ n'a rien à voir avec ce que je faisais jusque-là : gestion manuelle de la mémoire, compilation, contraintes de ressources, pas de garbage collector. Une autre façon de penser.
Comme pour le proof of concept initial, les IA génératives m'ont beaucoup aidé. Pour démarrer, comprendre les patterns, identifier ce que je faisais mal. Mais cette fois, le saut conceptuel était plus grand : il a fallu apprendre vraiment, pas juste transposer mes réflexes de développeur iOS.
Mais après quelques mois d'acharnement, j'ai quelque chose de fonctionnel. Le système fonctionne, lit les cartes, joue la musique, gère les playlists. Le squelette tient debout, et il tient sur un micro-contrôleur à quelques euros.
Trouver la bonne carte
J'ai commencé sur un Arduino Nano ESP32-S3. Petite carte propre, parfaite pour démarrer. Mais il manquait tout le reste : lecteur NFC, sortie audio, lecteur SD, gestion d'alimentation. À chaque composant, un module externe, des fils. Pratique pour commencer, mais pas utilisable en l'état pour mes enfants.
En cherchant un peu, je suis tombé sur une carte qui rassemble des composants de base pour démarrer le projet : le NFC Reader de HermitX, dans sa version N8R8. ESP32-S3, lecteur NFC intégré, sortie audio, lecteur SD, mais pas de gestion de batterie. Une carte pensée pour ce type d'usage, qui m'évite de tout recâbler à chaque itération.
C'est sur cette carte que tourne le prototype actuel.
Le boîtier, en plus simple
Pendant que je réécrivais le firmware, j'ai aussi repris la modélisation du boîtier. Le v3 avait une structure cubique, pensée comme l'ossature d'un cube imprimé en 3D avec des plaques en MDF découpées au laser pour les faces. Beau sur le rendu, mais lourd à imprimer, et chaque échec coûtait des heures de print.
J'ai donc tout simplifié. Plus de structure complexe, plus de panneaux à aligner au dixième de millimètre. Une boîte simple, plus compacte, plus facile à imprimer, qui héberge la carte, le haut-parleur, la batterie, et c'est tout.
Moins de pièces, moins de calibration, moins d'occasions de se planter.
Ce qui reste à régler
Le grand chantier non résolu, c'est toujours la gestion de batterie. Je suis encore sur le même LiPo Rider que sur le v3, et il a le même défaut : quand on débranche l'USB, la bascule sur batterie provoque une micro-coupure qui fait redémarrer la carte.
La bonne nouvelle, c'est que l'ESP32 démarre en dix secondes. Contre une à deux minutes sur le Raspberry Pi. Ce n'est pas parfait, mais c'est sans commune mesure. À l'usage, ça change tout : on débranche, ça redémarre, et c'est presque transparent.
Ce que j'en tire
Repartir d'une page blanche fait peur sur le moment. On laisse derrière soi du code qui marchait, un boîtier qui tournait tous les jours à la maison, des mois de bricolage. Mais c'était la bonne décision.
Le projet est plus aligné avec ce qu'il devrait être : un objet simple, économe, qui fait une chose et la fait bien. Et la contrainte forte du micro-contrôleur, paradoxalement, m'oblige à écrire du code plus propre que ce que je faisais sur le Raspberry Pi. Et le point le plus positif : on peut enfin se balader avec, parce que c'est beaucoup plus léger et que ça tient plus de cinq heures sur batterie.
La suite, c'est de stabiliser le firmware, de régler la question de l'alimentation, et de penser sérieusement à ce qui transformera ce prototype en quelque chose que d'autres personnes peuvent fabriquer. J'en reparlerai dans le prochain article.