CircuitPython

Salut, c'est Alex de DEV STORIES DOT EU. CircuitPython, épisode 1 sur 7. Si tu viens du monde des systèmes embarqués traditionnels, configurer une toolchain prend généralement plus de temps que d'écrire le premier programme. Tu passes des heures à te battre avec des compilateurs, des drivers et des utilitaires de flash dédiés, juste pour tester une seule ligne de logique. Le drive CIRCUITPY t'épargne tout ça. Les développeurs embarqués cherchent souvent instinctivement un outil de flash, un compilateur ou un IDE spécifique quand ils démarrent un nouveau projet. Avec CircuitPython, tu n'en as pas besoin. Il n'y a pas d'étape de compile. C'est le file system de ton système d'exploitation qui gère le processus de deploy. Quand tu branches un microcontrôleur compatible CircuitPython à ton ordinateur avec un câble USB, la carte se présente à ton système d'exploitation comme un périphérique de stockage de masse USB standard. Ce drive amovible se monte automatiquement et s'appelle CIRCUITPY. Pour ton ordinateur, que tu utilises Windows, macOS ou Linux, ça ressemble exactement à une clé USB classique. Tu peux l'ouvrir dans ton explorateur de fichiers, voir son contenu et le modifier. À l'intérieur de ce drive, le fichier le plus important est un fichier texte généralement nommé code point py. Ce fichier sert de point d'entrée pour ton application. Tu peux l'ouvrir dans n'importe quel éditeur de texte standard. Ça ne demande pas d'application spécialisée, un éditeur de texte basique fait parfaitement l'affaire. Quand tu écris un programme simple, par exemple une boucle qui print du texte ou interagit avec la carte, et que tu fais sauvegarder, le cycle de deploy commence automatiquement. Voici le point clé. Tu n'as pas besoin de cliquer sur un bouton de build ou de lancer un utilitaire en ligne de commande pour push le code sur le hardware. Au moment où tu sauvegardes le fichier, le microcontrôleur détecte l'activité du file system via la connexion USB. Ce comportement est géré par un mécanisme appelé auto-reload. CircuitPython surveille activement l'état de la connexion de stockage de masse USB. Quand tu lances une sauvegarde dans ton éditeur de texte, l'ordinateur écrit des données sur le drive CIRCUITPY. CircuitPython attend que l'écriture sur le file system soit terminée. Une fois l'écriture du fichier terminée, le système d'auto-reload déclenche un soft reboot du microcontrôleur. Ce soft reboot est extrêmement rapide. Il interrompt ce que le microcontrôleur était en train de faire, détruit proprement l'état actuel et vide complètement la mémoire. Ensuite, il parse et exécute immédiatement le fichier code point py qui vient d'être sauvegardé, depuis le début. Le mécanisme d'auto-reload crée une boucle d'itération très courte. Tu édites le code, tu sauvegardes le fichier, et tu regardes le hardware réagir en moins d'une seconde. S'il y a une erreur de syntaxe dans ton code fraîchement sauvegardé, l'exécution s'arrête proprement. Tu peux voir l'output de l'erreur via une connexion série. Tu corriges la typo, tu sauvegardes à nouveau le fichier, et la carte fait un reboot instantané pour tester le code mis à jour. Le drive CIRCUITPY est aussi le mécanisme pour gérer les dépendances. Si ton projet a besoin de code externe pour un hardware spécifique, tu n'utilises pas de package manager en ligne de commande. Tu fais simplement un glisser-déposer des fichiers de la librairie directement dans un dossier prévu pour, nommé lib, sur le drive CIRCUITPY. Le système d'auto-reload suit aussi les changements dans ce répertoire. Avant de terminer, si tu aimes ces épisodes techniques et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. Le changement fondamental ici, c'est que le file system lui-même sert de pipeline de deploy, transformant n'importe quelle machine avec un éditeur de texte basique et un port USB en une véritable workstation de développement embarqué, sans installer un seul driver. C'est tout pour cet épisode. Merci de ton écoute, et continue de build !

Salut, ici Alex de DEV STORIES DOT EU. CircuitPython, épisode 2 sur 7. Tu écris un script pour allumer une lumière, tu enregistres le fichier, et la lumière clignote une fraction de seconde avant de s'éteindre instantanément. Ton code est parfaitement correct. Le problème, c'est que quand un script arrive à la fin et se termine, le système réinitialise automatiquement l'état du hardware. Pour qu'un appareil continue de tourner, tu dois empêcher le script de se terminer. C'est là qu'intervient le concept de Hardware as Code. En programmation traditionnelle, ton code manipule des données en mémoire. En programmation embarquée, ton code manipule des signaux électriques physiques. CircuitPython abstrait cette complexité en utilisant trois modules intégrés : board, digitalio, et time. Tu n'as pas besoin de les installer. Ils sont directement intégrés au firmware. Le module board agit comme une map hardware pour ton microcontrôleur spécifique. Il sait quel routage interne correspond aux pins physiques. Quand tu fais référence à board dot LED, tu récupères la bonne adresse hardware pour la lumière intégrée, peu importe le modèle de board physique que tu as vraiment entre les mains. Le module digitalio fournit les classes nécessaires pour contrôler le flux d'électricité. Il traduit les objets Python en signaux numériques. Enfin, le module time gère le rythme. Les microcontrôleurs exécutent des millions d'instructions par seconde. Sans le module time pour mettre l'exécution en pause, une lumière clignotante basculerait si vite qu'elle paraîtrait juste continuellement faible pour l'œil humain. Voici comment ces trois modules fonctionnent ensemble pour faire clignoter une LED intégrée. D'abord, tu importes board, digitalio, et time. Ensuite, tu configures le hardware. Tu crées un nouvel objet en utilisant la classe DigitalInOut du module digitalio, et tu lui passes la pin board dot LED. Maintenant, tu as un objet Python qui représente cette connexion physique spécifique. Les pins peuvent soit écouter l'électricité qui entre, soit envoyer de l'électricité en sortie. Tu dois dire explicitement à CircuitPython ce que cette pin est censée faire. Tu définis la propriété direction de ton nouvel objet pin sur output. Ça dit au microcontrôleur de pousser la tension vers la LED. Voici le point clé. Une fois que la pin est configurée comme un output, contrôler le signal électrique physique est exactement comme assigner une variable. Pour allumer la LED, tu définis la propriété value de ton objet pin sur True. Sous le capot, CircuitPython traduit cette simple assignation booléenne en un signal de haute tension, poussant l'électricité à travers le circuit et illuminant la LED. Pour l'éteindre, tu définis la propriété value sur False, ce qui fait tomber la tension à zéro. Maintenant, revenons au problème avec lequel on a commencé. Si tu définis juste la value sur True, puis sur False, le script se termine. CircuitPython fait le ménage en réinitialisant toutes les pins, et ta board s'éteint. Pour faire clignoter la LED en continu, tu dois bloquer la séquence d'exécution. Tu enveloppes tes commandes dans une boucle while True infinie. À l'intérieur de cette boucle, tu définis la value de la pin sur True. Ensuite, tu utilises time dot sleep pour mettre le script en pause pendant une demi-seconde. Tu définis la value de la pin sur False. Tu mets en pause pour une autre demi-seconde. Comme c'est une boucle infinie, le script n'arrive jamais à la fin, le hardware ne se réinitialise jamais, et la LED continue de clignoter tant que la board est alimentée. Quand tu écris du hardware as code, tu ne fais pas juste déplacer des octets. Tu ouvres et fermes physiquement des portes électriques en assignant True et False à des objets Python. Merci d'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. CircuitPython, épisode 3 sur 7. La plupart du temps, le débogage embarqué consiste à modifier une ligne de code, attendre une recompilation, flasher la carte et espérer que ton output log attrape le bug. Mais et si tu pouvais mettre l'exécution en pause et commander le hardware en direct ? C'est exactement ce que la Serial Console et le REPL te permettent de faire. Quand tu connectes une carte CircuitPython à ton ordinateur, elle établit une connexion série bidirectionnelle via USB. Tu peux y accéder en utilisant un programme de terminal comme PuTTY sur Windows, ou la commande screen sur macOS et Linux. Beaucoup de connexions série te demandent de configurer un baud rate spécifique, généralement 115200. En fait, CircuitPython ignore ce paramètre via USB, mais c'est une pratique courante de configurer ton terminal à cette vitesse quand même. La Serial Console est ta fenêtre textuelle principale vers la carte. Chaque fois que ton script exécute un print statement, l'output apparaît ici. Plus important encore, si ton code rencontre une erreur fatale et crashe, le traceback Python est affiché dans cette console. Sans une connexion série ouverte, une carte qui a crashé ne te donne aucune information de diagnostic. Elle s'arrête tout simplement de fonctionner. La Serial Console est aussi ta passerelle vers le REPL. REPL signifie Read, Evaluate, Print, Loop. C'est un prompt Python interactif qui tourne directement sur la puce du microcontrôleur elle-même. Le développement de firmware traditionnel nécessite d'écrire le code sur une machine hôte, de le compiler et de transférer le binaire. Le REPL change complètement cette dynamique. Tu tapes une commande, la carte la lit, évalue la logique, print le résultat, et boucle pour attendre ta prochaine commande. Prenons un scénario pratique. Tu as un script qui tourne sur ta carte, mais tu dois trouver quelle pin hardware contrôle la LED intégrée. Tu ouvres ton terminal série et tu appuies sur Contrôle C. Ça interrompt instantanément le script en cours d'exécution. On te demande d'appuyer sur n'importe quelle touche, ce qui te fait basculer dans le REPL. Tu sais que tu es au bon endroit quand tu vois le prompt Python standard, qui est composé de trois chevrons. Maintenant, tu tapes import board. Pour découvrir quel hardware est disponible, tu passes le module board dans la fonction built-in dir. Le REPL print une liste de chaque nom de pin active pour ton hardware spécifique. Tu vois la pin de la LED dans la liste. Directement là, au niveau du prompt, tu importes le module digital IO. Tu crées un objet pin pour la LED, tu règles sa direction sur output, et tu définis sa valeur sur true. La LED physique sur ton bureau s'allume instantanément. Tu viens de commander le hardware manuellement, une ligne à la fois. Voici le point clé. Le code tapé dans le REPL est éphémère. Il n'existe que dans la mémoire active de cette session en cours. Si tu débranches la carte ou que tu la redémarres, tout ce que tu as tapé disparaît. Le REPL est un outil d'exploration. C'est une sandbox où tu peux tester les limites du hardware, vérifier les noms des pins, ou checker la syntaxe à la volée. Une fois que tu as trouvé la séquence exacte de commandes qui atteint ton but, tu dois recréer manuellement cette logique dans ton fichier code point py sur le lecteur USB pour la rendre permanente. Quand tu as fini de tester, tu quittes le REPL et tu redémarres ton code sauvegardé en appuyant sur Contrôle D. Ça déclenche un soft reboot, ce qui recharge ton fichier code point py depuis le début. Le REPL fait passer le développement hardware d'un cycle lent de devinettes à une exploration instantanée et interactive. Merci d'avoir écouté, bon code à tous !

Salut, c'est Alex de DEV STORIES DOT EU. CircuitPython, épisode 4 sur 7. Les microcontrôleurs ont une RAM extrêmement limitée, ce qui veut dire qu'un script relativement court peut soudainement faire complètement crasher ta board par manque de mémoire avant même d'exécuter une seule commande. Le coupable, c'est souvent la façon dont la board traite le code externe que tu importes, et résoudre ce bottleneck de mémoire, c'est exactement le but de l'écosystème de libraries. CircuitPython est livré avec des core modules intégrés au firmware, mais pour du hardware spécifique comme des capteurs de température ou des écrans LED, tu as besoin de libraries externes. Contrairement à un environnement Python desktop classique, il n'y a pas de package manager. Tu ne lances pas de commande pour récupérer automatiquement un driver. Ici, la gestion des dépendances est manuelle by design. Quand tu branches ton microcontrôleur en USB, il apparaît comme un flash drive. À la racine de ce drive, il y a un directory simplement nommé lib. Ce dossier est l'emplacement dédié pour toutes tes dépendances externes. Pour le remplir, tu télécharges le Adafruit Library Bundle, une énorme archive ZIP qui contient des centaines de drivers officiels et de helper modules. Voici le point clé. Quand tu vas télécharger ce bundle, tu verras plusieurs versions disponibles. Une erreur fréquente, c'est de télécharger simplement le bundle le plus récent sur la page. Si ta board tourne sous CircuitPython version huit, mais que tu télécharges le bundle de la version neuf, ton code va fail. La version majeure du bundle doit correspondre exactement à la version majeure du firmware CircuitPython installé sur ta board. Si elles ne correspondent pas, le système renvoie des erreurs de bytecode incompatible et refuse de s'exécuter. Dans ce bundle correspondant, tu trouveras les libraries proposées dans deux formats de fichiers distincts : les fichiers standard point py et les fichiers point mpy. Les fichiers point py sont du code source Python brut, lisible par un humain. Même si ta board peut les exécuter, le microcontrôleur doit charger tout ce texte brut dans son tout petit espace RAM et le compiler en bytecode à la volée. Cet overhead de compilation bouffe la mémoire incroyablement vite. Les fichiers point mpy résolvent ce problème. C'est du bytecode précompilé. L'étape lourde de traduction a déjà été faite sur un ordinateur avant même que tu télécharges le fichier zip. Quand le microcontrôleur charge un fichier point mpy, il exécute les instructions directement, en contournant complètement la phase de parsing du texte. Disons que tu connectes un bandeau LED NeoPixel à ta board. Tu écris ton script de contrôle, mais le système a besoin du driver hardware pour savoir comment communiquer avec ces LED spécifiques. Tu ouvres ton library bundle dans la bonne version, tu localises le fichier nommé neopixel point mpy, et tu le glisses directement dans le directory lib sur la board. Si tu avais glissé le fichier brut neopixel point py à la place, ton microcontrôleur aurait facilement pu se retrouver à court de mémoire juste en essayant d'interpréter le code du driver. En utilisant le fichier point mpy précompilé, la board économise de la RAM critique pour la logique de ton application et allume les pixels immédiatement. Gérer les dépendances manuellement t'oblige à être très intentionnel sur le code qui vit sur ton device. S'appuyer sur du bytecode précompilé est le seul moyen d'abstraire des opérations hardware complexes sans épuiser instantanément la toute petite empreinte mémoire d'un microcontrôleur. C'est tout pour cet épisode. Merci pour ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. CircuitPython, épisode 5 sur 7. Parfois, supprimer une library de ton microcontrôleur fait que ton projet tourne mieux. Tu supprimes une grosse dependency de ton drive, tu redémarres la board, et ton code marche toujours comme par magie. Ça arrive grâce à une feature qu'on appelle les Frozen Libraries. Les microcontrôleurs, surtout les plus petits comme le Circuit Playground Express, tournent avec des limitations hardware extrêmes. Chaque fichier de library standard dans ton dossier lib prend de l'espace de stockage physique sur le tout petit flash drive. Plus important encore, quand ton code s'exécute, l'appareil doit charger tout ce fichier dans sa RAM. Si tu charges trop de fichiers, ou des fichiers trop lourds, tu te retrouves à court de mémoire et le programme crashe. Les développeurs de firmware règlent ça en freezant les core libraries directement dans le build de CircuitPython. Au lieu d'exister comme un fichier indépendant sur ton USB drive visible, le code de la library est précompilé et packagé directement dans le fichier de firmware de base que tu charges au départ sur la board. Ça donne un avantage énorme. Les Frozen Libraries prennent zéro espace sur ton filesystem visible. Comme elles font partie de l'image système de base, le microcontrôleur exécute le code directement depuis la mémoire flash. Il zappe complètement le processus de copie de la library dans la RAM. Ça mène à un piège classique. Beaucoup de développeurs téléchargent un énorme bundle de libraries, copient tout ce dont ils pensent avoir besoin dans leur dossier lib, et dupliquent accidentellement des libraries qui sont déjà frozen dans leur firmware. Ça gaspille de l'espace précieux sur le filesystem. Si tu supprimes une library de ton dossier lib et que ton projet continue de tourner parfaitement, c'est que cette library était frozen. Voici le truc à retenir. Pour comprendre comment éviter ce doublon, tu dois comprendre l'ordre de priorité d'import contrôlé par le system path. Quand ton code importe un module, CircuitPython ne prend pas juste le premier match qu'il trouve. Il cherche les emplacements dans une séquence stricte. D'abord, il vérifie le root directory de ton drive. Deuxièmement, il vérifie le dossier lib. Troisièmement, et seulement s'il ne trouve pas la library dans les deux premiers emplacements, il vérifie les Frozen Libraries cachées dans le firmware. Cet ordre de priorité signifie que n'importe quel fichier que tu mets sur ton drive override la version frozen. Si tu places une version obsolète ou custom d'une library dans ton dossier lib, CircuitPython exécute ce fichier. Il ignore complètement la version frozen, optimisée et économe en mémoire, qui est dans le firmware. Tu paies le coût en mémoire pour un fichier que tu n'avais pas besoin de fournir. À l'intérieur de ces répertoires, les extensions de fichiers suivent aussi une règle de priorité stricte. Un fichier source en plain text gagne toujours sur un fichier compilé. Si tu as à la fois un fichier texte standard et une version compilée de la même library dans le même répertoire, CircuitPython charge le fichier texte non compilé. Si tu veux savoir exactement ce qui est intégré dans ta board spécifique, tu peux ouvrir le prompt interactif et taper le mot help, en passant le mot modules entre parenthèses. Ça affiche une liste complète de chaque Frozen Library disponible out of the box. La façon la plus intelligente de gérer la mémoire sur un device limité, c'est de laisser le firmware faire le gros du travail. Savoir exactement ce qui est déjà frozen évite les fichiers en double, empêche les overrides accidentels, et garde ta mémoire disponible pour la logique de ton application. Merci d'avoir écouté. Prenez soin de vous, tout le monde.

Salut, c'est Alex de DEV STORIES DOT EU. CircuitPython, épisode 6 sur 7. Tu regardes un projet hardware et tu vois que les développeurs ont délibérément supprimé des features avancées comme les hardware interrupts du langage de base. Tu pourrais penser que ça a bridé la plateforme, mais en fait, ça l'a rendue incroyablement plus populaire. C'est la divergence architecturale entre CircuitPython et MicroPython. Les développeurs pensent souvent que ces deux plateformes sont identiques. Les deux font tourner Python sur des microcontrôleurs, et CircuitPython a commencé à l'origine comme un fork de MicroPython. Pourtant, elles répondent à des philosophies complètement différentes. MicroPython est conçu pour exposer la puissance brute et les features spécifiques du microcontrôleur sous-jacent. CircuitPython est conçu pour imposer un standard strict et unifié sur tout le hardware. La première différence que tu vas remarquer, c'est la standard library. MicroPython utilise une convention de nommage qui préfixe les modules standards avec la lettre u pour indiquer une version micro. Tu importes uos ou utime. CircuitPython abandonne complètement ça. Il impose le nommage standard du CPython desktop. Tu importes simplement os ou time. Si tu es un développeur qui fait le porting d'un script MicroPython vers CircuitPython, tu devras renommer ces imports. En échange de ce petit ajustement, ton code devient hautement portable. Cette portabilité, c'est la core feature de CircuitPython. MicroPython expose des hardware registers spécifiques et des numéros de pin propres à la puce. CircuitPython abstrait complètement le hardware en utilisant une API unifiée centrée autour d'un module appelé board. Au lieu d'écrire du code qui toggle la pin GPIO 15 sur un ESP32, tu dis à CircuitPython de toggle board dot D4. Si tu déplaces ce script exact sur une architecture de microcontrôleur complètement différente, comme une puce ARM Cortex standard, le code hardware tourne sans aucune modification. Pour maintenir cette cohérence, CircuitPython impose certains choix architecturaux que MicroPython laisse optionnels. Par exemple, MicroPython te permet de compiler un firmware sans le support des nombres à virgule flottante pour économiser de la mémoire. CircuitPython impose le support de la virgule flottante sur chaque build. Les opérations mathématiques se comportent exactement de la même manière, peu importe à quel point le hardware est limité. CircuitPython standardise aussi les messages d'erreur, en fournissant un texte verbeux et localisé au lieu de memory faults bare-metal laconiques. Voici l'idée clé. La différence la plus polarisante, c'est la façon dont les deux gèrent la concurrency. MicroPython supporte totalement les hardware interrupts. Un interrupt permet à un changement physique sur une pin de mettre immédiatement en pause le programme principal, d'exécuter une fonction spécifique, puis de reprendre. Ça offre un timing haute performance, mais ça introduit aussi des race conditions complexes et des états de mémoire imprévisibles qui sont incroyablement difficiles à débugger. CircuitPython supprime délibérément le support des hardware interrupts. Tu ne peux pas trigger du code Python directement depuis une pin de hardware interrupt. À la place, il impose un multitasking coopératif. Tu gères la concurrency en utilisant les features standards d'asyncio ou en vérifiant les états séquentiellement dans ta main loop. En abandonnant les interrupts, CircuitPython garantit que le flux d'exécution reste entièrement prévisible et élimine une catégorie massive de silent crashes. MicroPython te donne les clés du bare metal, en privilégiant les performances brutes et le contrôle du hardware. CircuitPython échange ce contrôle contre un environnement où ton code est complètement portable, prévisible, et se comporte exactement comme le Python standard que tu fais tourner sur un desktop. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. CircuitPython, épisode 7 sur 7. Tu passes des jours à écrire et tester du code d'interaction hardware pour un capteur sur un minuscule microcontrôleur à cinq dollars. Plus tard, les besoins du projet changent, et tu as soudainement besoin de la puissance de calcul d'un ordinateur Linux complet pour logger ces données dans une base de données cloud distante. Normalement, passer d'un microcontrôleur bare-metal à un système d'exploitation complet implique de réécrire intégralement ton code hardware. Ta plateforme cible possède désormais un kernel d'OS qui gère l'accès au hardware, ce qui nécessite des drivers et des libraries complètement différents. Mais et si exactement le même script Python pouvait tourner sans modification sur les deux plateformes ? C'est exactement ce que te permet de faire Adafruit Blinka. Avant d'expliquer comment ça marche, dissipons une idée reçue courante. Blinka ne remplace pas l'OS Linux de ton Raspberry Pi, BeagleBone ou autre single-board computer. Tu ne flashes pas un fichier de firmware CircuitPython sur une carte SD comme tu le ferais avec un microcontrôleur. Au lieu de ça, Blinka est simplement un package Python. Tu l'installes en utilisant le pip standard. Il agit comme une couche de compatibilité qui tourne au sein du CPython desktop standard. Son seul job est de traduire les appels d'API CircuitPython en appels système Linux standards nécessaires pour contrôler le hardware. Quand tu écris du code hardware sur un microcontrôleur, CircuitPython gère l'accès direct au hardware. Sur un système Linux, le kernel de l'OS contrôle le hardware, et les programmes utilisateurs doivent demander l'accès. Blinka fait le pont entre les deux. Quand ton code importe le module board ou utilise le module digitalio pour toggle une pin, Blinka intercepte ces commandes. Il mappe les noms des pins CircuitPython au layout hardware spécifique de ton single-board computer, en routant la requête à travers les sous-systèmes Linux nécessaires. Imagine à quoi ça ressemble en pratique avec notre capteur de température. Sur le minuscule microcontrôleur, ton code importe board, configure un bus I2C, et lit en continu les valeurs de température. Pour scaler cette opération sur un Raspberry Pi 5, tu connectes physiquement le capteur aux header pins du Pi. Ensuite, dans ton terminal Linux, tu utilises pip pour installer Adafruit Blinka et le driver Python spécifique pour ton capteur de température. Tu copies ton script Python d'origine, sans modifier une seule ligne. Quand tu exécutes le script en utilisant du Python 3 standard, le module board détecte dynamiquement qu'il tourne sur un Raspberry Pi 5. Il fournit automatiquement les bonnes définitions de pins pour cette board spécifique. Le module busio traduit de façon transparente tes requêtes de lecture I2C en appels de device I2C Linux standards. Ton script lit les données du capteur exactement comme avant. C'est là que ça devient intéressant. Parce que tu fais maintenant tourner du CPython standard sur une machine Linux complète, tu n'es plus contraint par les limites de mémoire d'un microcontrôleur. Ton script peut lire le capteur hardware en utilisant la couche de traduction Blinka, puis passer immédiatement ces données à de lourdes libraries desktop. Tu peux utiliser des requêtes réseau standards pour pusher les métriques vers une base de données cloud, traiter la télémétrie avec des outils de data science, ou même les servir via un framework web local. Voici le point clé. Le code d'interaction hardware reste identique à travers des architectures informatiques complètement différentes. En découplant la logique du capteur de l'OS sous-jacent, Blinka te permet de prototyper pour pas cher sur du bare-metal et de scaler vers des environnements Linux complets avec zéro réécriture de code hardware. Ça conclut notre série sur CircuitPython. Je t'encourage à lire la documentation officielle, à essayer de configurer un capteur avec Blinka par toi-même, ou à visiter devstories dot eu pour suggérer des sujets pour de futures séries. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue à builder !