CircuitPython

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 1 von 7. Wenn du aus der Welt der traditionellen Embedded-Systeme kommst, dauert das Einrichten einer Toolchain meist länger als das Schreiben des ersten Programms. Du verbringst Stunden damit, dich mit Compilern, Device-Treibern und speziellen Flash-Tools herumzuschlagen, nur um eine einzige Zeile Logik zu testen. Das CIRCUITPY Drive umgeht all das komplett. Embedded-Entwickler suchen beim Start eines neuen Projekts oft instinktiv nach einem Flash-Tool, einem Compiler oder einer bestimmten Integrated Development Environment. Mit CircuitPython brauchst du das alles nicht. Es gibt keinen Compile-Schritt. Das File-System des Betriebssystems übernimmt den Deployment-Prozess. Wenn du einen CircuitPython-kompatiblen Mikrocontroller über ein USB-Kabel an deinen Computer anschließt, meldet sich das Board bei deinem Betriebssystem als Standard-USB-Massenspeicher. Dieses Wechsel-Laufwerk wird automatisch gemountet und heißt CIRCUITPY. Für deinen Computer sieht es genau wie ein ganz normaler USB-Stick aus, egal ob du Windows, macOS oder Linux nutzt. Du kannst es in deinem File-Explorer öffnen, dir den Inhalt ansehen und ihn bearbeiten. Auf diesem Drive ist die wichtigste Datei eine Textdatei, die normalerweise code dot py heißt. Diese Datei ist der Entry-Point für deine Application. Du kannst sie in jedem Standard-Texteditor öffnen. Du brauchst dafür keine spezielle Anwendung; ein einfacher Texteditor funktioniert perfekt. Wenn du ein einfaches Programm schreibst – vielleicht eine Loop, die Text ausgibt oder mit dem Board interagiert – und auf Speichern drückst, beginnt der Deployment-Cycle automatisch. Hier ist der entscheidende Punkt: Du musst keinen Build-Button klicken oder ein Command-Line-Utility ausführen, um den Code auf die Hardware zu pushen. In dem Moment, in dem du die Datei speicherst, erkennt der Mikrocontroller die File-System-Aktivität über die USB-Verbindung. Dieses Verhalten wird von einem Mechanismus namens Auto-Reload gesteuert. CircuitPython überwacht aktiv den Status der USB-Massenspeicher-Verbindung. Wenn du in deinem Texteditor einen Speichervorgang anstößt, schreibt der Computer Daten auf das CIRCUITPY Drive. CircuitPython wartet, bis der File-System-Schreibvorgang abgeschlossen ist. Sobald das Schreiben der Datei beendet ist, triggert das Auto-Reload-System einen Soft-Reboot des Mikrocontrollers. Dieser Soft-Reboot ist extrem schnell. Er unterbricht alles, was der Mikrocontroller gerade gemacht hat, baut den aktuellen State sicher ab und leert den Memory komplett. Danach parst und führt er die neu gespeicherte code dot py Datei sofort von Anfang an aus. Der Auto-Reload-Mechanismus erzeugt eine sehr enge Iteration-Loop. Du editierst den Code, speicherst die Datei und siehst in weniger als einer Sekunde, wie die Hardware reagiert. Wenn es einen Syntax-Error in deinem neu gespeicherten Code gibt, stoppt die Execution sicher. Du kannst dir den Error-Output über eine serielle Verbindung ansehen. Du fixt den Typo, speicherst die Datei nochmal, und das Board macht sofort einen Reboot, um den geupdateten Code auszuprobieren. Das CIRCUITPY Drive ist auch der Mechanismus, um Dependencies zu managen. Wenn dein Projekt externen Helper-Code für bestimmte Hardware braucht, benutzt du keinen Command-Line Package-Manager. Du ziehst die nötigen Library-Files einfach per Drag-and-Drop direkt in einen dafür vorgesehenen Ordner namens lib auf dem CIRCUITPY Drive. Das Auto-Reload-System trackt auch Änderungen in diesem Directory. Bevor wir zum Ende kommen: Wenn dir diese technischen Episoden gefallen und du die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Der fundamentale Shift hier ist, dass das File-System selbst als Deployment-Pipeline fungiert. Das verwandelt jede Maschine mit einem einfachen Texteditor und einem USB-Port in eine vollwertige Embedded-Development-Workstation, ohne einen einzigen Treiber zu installieren. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 2 von 7. Du schreibst ein Script, um ein Licht einzuschalten, speicherst das File, und das Licht blinkt für den Bruchteil einer Sekunde, bevor es sofort wieder dunkel wird. Dein Code ist völlig in Ordnung. Das Problem ist, dass das System den Hardware-State automatisch zurücksetzt, wenn ein Script das Ende erreicht und beendet wird. Um ein Device am Laufen zu halten, musst du verhindern, dass das Script beendet wird. Hier kommt das Konzept von Hardware as Code ins Spiel. In der traditionellen Programmierung manipuliert dein Code Daten im Memory. In der Embedded-Programmierung manipuliert dein Code physische elektrische Signale. CircuitPython abstrahiert diese Komplexität mit drei Built-in-Modulen: board, digitalio und time. Du musst diese nicht installieren. Sie sind direkt in die Firmware eingebacken. Das board-Modul fungiert als Hardware-Map für deinen spezifischen Microcontroller. Es weiß, welches interne Routing den physischen Pins entspricht. Wenn du board dot LED referenzierst, greifst du auf die korrekte Hardware-Adresse für das eingebaute Licht zu, unabhängig davon, welches physische Board-Modell du eigentlich in den Händen hältst. Das digitalio-Modul stellt die Klassen bereit, die du brauchst, um den Stromfluss zu steuern. Es übersetzt Python-Objekte in digitale Signale. Und schließlich kümmert sich das time-Modul um das Pacing. Microcontroller führen Millionen von Instructions pro Sekunde aus. Ohne das time-Modul, um die Execution zu pausieren, würde ein blinkendes Licht so schnell umschalten, dass es für das menschliche Auge einfach nur durchgehend gedimmt aussehen würde. Hier ist, wie diese drei Module zusammenarbeiten, um eine Onboard-LED blinken zu lassen. Zuerst importierst du board, digitalio und time. Als Nächstes richtest du die Hardware ein. Du erstellst ein neues Objekt mit der DigitalInOut-Klasse aus dem digitalio-Modul und übergibst ihm den board dot LED Pin. Jetzt hast du ein Python-Objekt, das diese spezifische physische Verbindung repräsentiert. Pins können entweder auf eingehenden Strom lauschen oder Strom ausgeben. Du musst CircuitPython explizit sagen, was dieser Pin tun soll. Du setzt die direction-Property deines neuen Pin-Objekts auf output. Das sagt dem Microcontroller, dass er Spannung an die LED rausdrücken soll. Hier ist die entscheidende Erkenntnis. Sobald der Pin als output konfiguriert ist, ist das Steuern des physischen elektrischen Signals genau wie das Zuweisen einer Variable. Um die LED einzuschalten, setzt du die value-Property deines Pin-Objekts auf True. Unter der Haube übersetzt CircuitPython dieses simple Boolean-Assignment in ein High-Voltage-Signal, drückt Strom durch den Schaltkreis und bringt die LED zum Leuchten. Um sie auszuschalten, setzt du die value-Property auf False, was die Spannung auf null fallen lässt. Nun zurück zu dem Problem, mit dem wir angefangen haben. Wenn du die value einfach auf True und dann auf False setzt, ist das Script beendet. CircuitPython räumt auf, indem es alle Pins zurücksetzt, und dein Board geht aus. Um die LED kontinuierlich blinken zu lassen, musst du die Execution-Sequence abfangen. Du packst deine Commands in eine unendliche while True Loop. Innerhalb dieser Loop setzt du die Pin-value auf True. Dann nutzt du time dot sleep, um das Script für eine halbe Sekunde zu pausieren. Du setzt die Pin-value auf False. Du pausierst für eine weitere halbe Sekunde. Weil es eine unendliche Loop ist, erreicht das Script nie das Ende, die Hardware wird nie zurückgesetzt, und die LED blinkt so lange weiter, wie das Board Strom hat. Wenn du Hardware as Code schreibst, verschiebst du nicht einfach nur Bytes. Du öffnest und schließt physisch elektrische Gates, indem du Python-Objekten True und False zuweist. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 3 von 7. Beim Embedded Debugging geht es meist darum, eine Codezeile anzupassen, auf einen Recompile zu warten, das Board zu flashen und zu hoffen, dass dein Output Log den Bug erwischt. Was aber, wenn du die Ausführung pausieren und die Hardware live steuern könntest? Genau das ermöglichen dir die Serial Console und die REPL. Wenn du ein CircuitPython-Board an deinen Computer anschließt, stellt es eine bidirektionale serielle Verbindung über USB her. Du kannst darauf mit einem Terminalprogramm wie PuTTY unter Windows oder dem screen-Befehl unter macOS und Linux zugreifen. Viele serielle Verbindungen erfordern, dass du eine bestimmte Baudrate einstellst, typischerweise 115200. CircuitPython ignoriert diese Einstellung über USB eigentlich, aber es ist Standardpraxis, dein Terminal trotzdem auf diese Geschwindigkeit zu konfigurieren. Die Serial Console ist dein primäres textbasiertes Fenster zum Board. Immer wenn dein Skript ein print-Statement ausführt, erscheint der Output hier. Noch wichtiger: Wenn dein Code auf einen fatalen Fehler stößt und crasht, wird der Python Traceback in dieser Konsole ausgegeben. Ohne eine offene serielle Verbindung gibt dir ein gecrashtes Board keine Diagnoseinformationen. Es hört einfach auf zu funktionieren. Die Serial Console ist auch dein Gateway zur REPL. REPL steht für Read, Evaluate, Print, Loop. Es ist ein interaktiver Python Prompt, der direkt auf dem Mikrocontroller-Chip selbst läuft. Traditionelle Firmware-Entwicklung erfordert, dass du Code auf einer Host-Maschine schreibst, ihn kompilierst und das Binary überträgst. Die REPL ändert diese Dynamik komplett. Du tippst einen Befehl ein, das Board liest ihn, evaluiert die Logik, printet das Ergebnis und springt in der Loop zurück, um auf deinen nächsten Befehl zu warten. Stell dir ein praktisches Szenario vor. Du hast ein Skript, das auf deinem Board läuft, aber du musst herausfinden, welcher Hardware-Pin die eingebaute LED steuert. Du öffnest dein Serial Terminal und drückst Steuerung C. Das unterbricht das laufende Skript sofort. Du wirst aufgefordert, eine beliebige Taste zu drücken, was dich in die REPL bringt. Du weißt, dass du am richtigen Ort bist, wenn du den Standard Python Prompt siehst, also drei spitze Klammern. Jetzt tippst du import board. Um herauszufinden, welche Hardware verfügbar ist, übergibst du das board-Modul an die eingebaute dir-Funktion. Die REPL printet eine Liste jedes aktiven Pin-Namens für deine spezifische Hardware. Du siehst den LED-Pin in der Liste. Direkt dort am Prompt importierst du das digital IO Modul. Du erstellst ein Pin-Objekt für die LED, setzt seine Direction auf Output und seinen Value auf True. Die physische LED auf deinem Schreibtisch geht sofort an. Du hast die Hardware gerade manuell gesteuert, Zeile für Zeile. Hier ist die wichtigste Erkenntnis. Code, den du in der REPL eintippst, ist flüchtig. Er existiert nur im aktiven Speicher dieser aktuellen Session. Wenn du das Board absteckst oder neu startest, verschwindet alles, was du getippt hast. Die REPL ist ein exploratives Tool. Sie ist eine Sandbox, in der du Hardware-Limits testen, Pin-Namen verifizieren oder Syntax on the fly checken kannst. Sobald du die exakte Sequenz von Befehlen gefunden hast, die dein Ziel erreicht, musst du diese Logik manuell in deiner code dot py Datei auf dem USB-Laufwerk nachbauen, um sie permanent zu machen. Wenn du mit dem Testen fertig bist, verlässt du die REPL und startest deinen gespeicherten Code neu, indem du Steuerung D drückst. Das löst einen Soft Reboot aus und lädt deine code dot py Datei komplett neu. Die REPL verschiebt die Hardware-Entwicklung von einem langsamen Zyklus des Ratens hin zu sofortiger, interaktiver Exploration. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 4 von 7. Mikrocontroller haben unglaublich wenig RAM. Das bedeutet, dass ein relativ kurzes Script dein Board plötzlich mit einem Out-of-Memory-Crash komplett zum Absturz bringen kann, noch bevor ein einziger Befehl ausgeführt wurde. Die Ursache ist oft, wie das Board den externen Code verarbeitet, den du einbindest, und genau darum geht es in The Library Ecosystem: diesen Memory-Bottleneck zu lösen. CircuitPython bringt Core-Module mit, die direkt in die Firmware eingebaut sind, aber für spezielle Hardware wie Temperatursensoren oder LED-Displays brauchst du externe Libraries. Anders als in einer normalen Desktop-Python-Umgebung gibt es hier keinen Package Manager. Du führst keinen Befehl aus, um automatisch einen Driver herunterzuladen. Das Dependency Management ist hier by design manuell. Wenn du deinen Mikrocontroller per USB anschließt, taucht er als Flash Drive auf. Im Root-Directory dieses Laufwerks gibt es ein Directory, das einfach lib heißt. Dieser Ordner ist der feste Platz für all deine externen Dependencies. Um ihn zu füllen, lädst du das Adafruit Library Bundle herunter, ein riesiges ZIP-Archiv mit Hunderten von offiziellen Drivern und Helper-Modulen. Hier ist der entscheidende Punkt. Wenn du dieses Bundle herunterladen willst, wirst du sehen, dass mehrere Versionen verfügbar sind. Ein häufiger Fehler ist es, einfach das neueste Bundle auf der Seite herunterzuladen. Wenn auf deinem Board CircuitPython Version acht läuft, du aber das Version-neun-Bundle herunterlädst, wird dein Code fehlschlagen. Die Major Version des Bundles muss exakt mit der Major Version der CircuitPython-Firmware übereinstimmen, die auf deinem Board installiert ist. Wenn sie nicht übereinstimmen, wirft das System Incompatible-Bytecode-Errors und verweigert die Ausführung. In diesem passenden Bundle findest du die Libraries in zwei verschiedenen Dateiformaten: Standard dot py Dateien und dot mpy Dateien. dot py Dateien sind roher, menschenlesbarer Python Source Text. Dein Board kann sie zwar ausführen, aber der Mikrocontroller muss den ganzen rohen Text in seinen winzigen RAM laden und ihn on the fly in Bytecode kompilieren. Dieser Compilation-Overhead frisst den Speicher unglaublich schnell auf. dot mpy Dateien lösen dieses Problem. Sie sind pre-compiled Bytecode. Der aufwendige Übersetzungsschritt wurde bereits auf einem Computer erledigt, noch bevor du die ZIP-Datei überhaupt heruntergeladen hast. Wenn der Mikrocontroller eine dot mpy Datei lädt, führt er die Instructions direkt aus und überspringt die Text-Parsing-Phase komplett. Angenommen, du schließt einen NeoPixel-LED-Strip an dein Board an. Du schreibst dein Control-Script, aber das System braucht den Hardware-Driver, um zu wissen, wie es mit diesen speziellen LEDs kommunizieren soll. Du öffnest dein korrekt versioniertes Library-Bundle, suchst die Datei namens neopixel dot mpy und ziehst sie direkt in das lib-Directory auf dem Board. Hättest du stattdessen die rohe neopixel dot py Datei rübergezogen, könnte deinem Mikrocontroller leicht der Speicher ausgehen, nur beim Versuch, den Driver-Code zu interpretieren. Durch die Nutzung der pre-compiled dot mpy Datei spart das Board kritischen RAM für deine eigentliche Application-Logic und lässt die Pixel sofort aufleuchten. Dependencies manuell zu managen zwingt dich dazu, sehr bewusst zu entscheiden, welcher Code auf deinem Device lebt. Sich auf pre-compiled Bytecode zu verlassen, ist der einzige Weg, komplexe Hardware-Operations zu abstrahieren, ohne den winzigen Memory-Footprint eines Mikrocontrollers sofort auszureizen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 5 von 7. Manchmal sorgt das Löschen einer Library von deinem Mikrocontroller tatsächlich dafür, dass dein Projekt besser läuft. Du entfernst eine große Dependency von deinem Drive, startest das Board neu, und dein Code funktioniert wie von Zauberhand immer noch. Das liegt an einem Feature namens Frozen Libraries. Mikrocontroller, besonders kleinere wie der Circuit Playground Express, arbeiten unter extremen Hardware-Limits. Jede Standard-Library-Datei in deinem lib-Folder belegt physischen Speicherplatz auf dem winzigen Flash-Drive. Noch wichtiger ist: Wenn dein Code läuft, muss das Gerät diese komplette Datei in seinen RAM laden. Wenn du zu viele oder zu große Dateien lädst, geht dir der Memory aus und das Programm stürzt ab. Firmware-Entwickler lösen dieses Problem, indem sie Core-Libraries direkt in den CircuitPython-Build freezen. Anstatt als eigenständige Datei auf deinem sichtbaren USB-Drive zu liegen, wird der Library-Code vorkompiliert und direkt in das Base-Firmware-File gepackt, das du anfangs auf das Board lädst. Das bietet einen massiven Vorteil. Frozen Libraries belegen null Speicherplatz auf deinem sichtbaren Filesystem. Weil sie Teil des Core-System-Images sind, führt der Mikrocontroller den Code direkt aus dem Flash-Memory aus. Er überspringt den Prozess, die Library in den RAM zu kopieren, komplett. Das führt zu einer häufigen Falle. Viele Entwickler laden ein riesiges Library-Bundle herunter, kopieren alles, was sie zu brauchen glauben, in ihren lib-Folder und duplizieren dabei versehentlich Libraries, die bereits in ihrer Firmware frozen sind. Das verschwendet wertvollen Filesystem-Space. Wenn du eine Library aus deinem lib-Folder löschst und dein Projekt weiterhin einwandfrei läuft, war diese Library frozen. Hier ist der entscheidende Punkt. Um zu verstehen, wie du diesen Overlap vermeidest, musst du die Import-Priority-Order verstehen, die vom System-Path gesteuert wird. Wenn dein Code ein Module importiert, schnappt sich CircuitPython nicht einfach den ersten Treffer, den es sieht. Es durchsucht Locations in einer strikten Reihenfolge. Erstens checkt es das Root-Directory von deinem Drive. Zweitens checkt es den lib-Folder. Drittens, und nur wenn es die Library an den ersten beiden Locations nicht findet, checkt es die Frozen Libraries, die in der Firmware versteckt sind. Diese Priority-Order bedeutet, dass jede Datei, die du auf dein Drive packst, die frozen Version überschreibt. Wenn du eine veraltete oder eine Custom-Version einer Library in deinen lib-Folder legst, führt CircuitPython diese Datei aus. Es ignoriert die optimierte, memory-effiziente frozen Version in der Firmware komplett. Du zahlst die Memory-Kosten für eine Datei, die du gar nicht hättest bereitstellen müssen. Innerhalb dieser Directories folgen auch File-Extensions einer strikten Priority-Rule. Ein Plain-Text-Source-File gewinnt immer gegen ein kompiliertes File. Wenn du sowohl ein Standard-Text-File als auch eine kompilierte Version derselben Library im exakt selben Directory liegen hast, lädt CircuitPython das unkompilierte Text-File. Wenn du genau wissen willst, was in dein spezifisches Board eingebacken ist, kannst du den interactive Prompt öffnen und das Wort help eintippen, wobei du das Wort modules in den Klammern übergibst. Das printet eine komplette Liste aller Frozen Libraries, die dir out of the box zur Verfügung stehen. Der smarteste Weg, Memory auf einem Constrained Device zu managen, ist, die Firmware das Heavy Lifting machen zu lassen. Genau zu wissen, was bereits frozen ist, verhindert Duplicate Files, stoppt versehentliche Overrides und hält deinen verfügbaren Memory für deine eigentliche Application-Logic frei. Danke fürs Zuhören. Macht's gut zusammen.

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 6 von 7. Du schaust dir ein Hardware-Projekt an und siehst, dass die Entwickler bewusst auf fortgeschrittene Features wie Hardware-Interrupts in der Core-Language verzichtet haben. Du denkst vielleicht, das hätte die Plattform eingeschränkt, aber tatsächlich hat es sie extrem erfolgreich gemacht. Das ist der architektonische Unterschied zwischen CircuitPython und MicroPython. Entwickler gehen oft davon aus, dass diese beiden Plattformen identisch sind. Beide führen Python auf Mikrocontrollern aus, und CircuitPython entstand ursprünglich als Fork von MicroPython. Sie verfolgen jedoch völlig unterschiedliche Philosophien. MicroPython ist darauf ausgelegt, die rohe Power und die spezifischen Features des zugrundeliegenden Mikrocontrollers zugänglich zu machen. CircuitPython ist darauf ausgelegt, einen strengen, einheitlichen Standard über alle Hardware hinweg durchzusetzen. Der erste Unterschied, der dir auffallen wird, ist die Standard Library. MicroPython nutzt eine Naming Convention, bei der Standard-Module ein u als Prefix bekommen, um eine Micro-Version zu kennzeichnen. Du importierst uos oder utime. CircuitPython verzichtet vollständig darauf. Es erzwingt das Standard-Naming von Desktop-CPython. Du importierst einfach os oder time. Wenn du als Entwickler ein MicroPython-Script nach CircuitPython portierst, musst du diese Imports umbenennen. Im Gegenzug für diese kleine Anpassung wird dein Code hochgradig portabel. Diese Portabilität ist das Core-Feature von CircuitPython. MicroPython gibt dir Zugriff auf spezifische Hardware-Register und chip-spezifische Pin-Nummern. CircuitPython abstrahiert die Hardware komplett über eine einheitliche API, die um ein Modul namens board zentriert ist. Anstatt Code zu schreiben, der den GPIO-Pin 15 auf einem ESP32 toggelt, sagst du CircuitPython, es soll board dot D4 toggeln. Wenn du genau dieses Script auf eine völlig andere Mikrocontroller-Architektur verschiebst, wie einen Standard-ARM-Cortex-Chip, läuft der Hardware-Code komplett unverändert. Um diese Konsistenz zu gewährleisten, erzwingt CircuitPython bestimmte Architekturentscheidungen, die MicroPython optional lässt. MicroPython erlaubt es dir zum Beispiel, Firmware ohne Floating-Point-Support zu kompilieren, um Memory zu sparen. CircuitPython schreibt Floating-Point-Support in jedem einzelnen Build vor. Mathematische Operationen verhalten sich exakt gleich, egal wie eingeschränkt die Hardware ist. CircuitPython standardisiert außerdem Error Messages und liefert ausführlichen, lokalisierten Text anstelle von knappen Bare-Metal-Memory-Faults. Hier ist die wichtigste Erkenntnis. Der polarisierendste Unterschied ist, wie die beiden mit Concurrency umgehen. MicroPython unterstützt Hardware-Interrupts vollständig. Ein Interrupt erlaubt es, dass eine physische Pin-Änderung das Main-Programm sofort pausiert, eine spezifische Funktion ausführt und dann fortsetzt. Das sorgt für High-Performance-Timing, führt aber auch zu komplexen Race Conditions und unvorhersehbaren Memory States, die extrem schwer zu debuggen sind. CircuitPython entfernt bewusst den Support für Hardware-Interrupts. Du kannst Python-Code nicht direkt über einen Hardware-Interrupt-Pin triggern. Stattdessen erzwingt es kooperatives Multitasking. Du managst Concurrency mit Standard-asyncio-Features oder indem du States sequenziell in deinem Main-Loop checkst. Durch den Verzicht auf Interrupts stellt CircuitPython sicher, dass der Execution Flow komplett vorhersehbar bleibt, und eliminiert eine riesige Kategorie von Silent Crashes. MicroPython gibt dir die Schlüssel zum Bare Metal und priorisiert rohe Performance und Hardware-Control. CircuitPython tauscht diese Kontrolle gegen eine Umgebung ein, in der dein Code komplett portabel und vorhersehbar ist und sich exakt wie das Standard-Python verhält, das du auf einem Desktop ausführst. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. CircuitPython, Folge 7 von 7. Du verbringst Tage damit, Code für die Hardware-Interaktion eines Sensors auf einem winzigen Fünf-Dollar-Microcontroller zu schreiben und zu testen. Später ändern sich die Projektanforderungen, und plötzlich brauchst du die Rechenleistung eines vollwertigen Linux-Rechners, um diese Daten in einer Remote-Cloud-Datenbank zu loggen. Normalerweise bedeutet der Wechsel von einem Bare-Metal-Microcontroller zu einem vollwertigen Betriebssystem, dass du deinen Hardware-Code komplett neu schreiben musst. Deine Zielplattform hat jetzt einen OS-Kernel, der den Hardware-Zugriff verwaltet und völlig andere Treiber und Libraries erfordert. Aber was wäre, wenn genau dasselbe Python-Script unverändert auf beiden Plattformen laufen könnte? Genau das ermöglicht dir Adafruit Blinka. Bevor wir erklären, wie das funktioniert, lass uns mit einem häufigen Missverständnis aufräumen. Blinka ersetzt nicht das Linux-Betriebssystem auf deinem Raspberry Pi, BeagleBone oder einem anderen Single-Board-Computer. Du flashst keine CircuitPython-Firmware-Datei auf eine SD-Karte, wie du es bei einem Microcontroller tust. Stattdessen ist Blinka einfach ein Python-Package. Du installierst es über Standard-pip. Es fungiert als Compatibility-Layer, der innerhalb von Standard-Desktop-CPython läuft. Seine einzige Aufgabe ist es, CircuitPython-API-Calls in die Standard-Linux-System-Calls zu übersetzen, die zur Hardware-Steuerung erforderlich sind. Wenn du Hardware-Code auf einem Microcontroller schreibst, übernimmt CircuitPython den direkten Hardware-Zugriff. Auf einem Linux-System steuert der OS-Kernel die Hardware, und User-Programme müssen den Zugriff anfordern. Blinka schließt diese Lücke. Wenn dein Code das board-Modul importiert oder das digitalio-Modul verwendet, um einen Pin zu toggeln, fängt Blinka diese Befehle ab. Es mappt die CircuitPython-Pin-Namen auf das spezifische Hardware-Layout deines Single-Board-Computers und routet die Request durch die notwendigen Linux-Subsysteme. Stell dir vor, wie das in der Praxis mit unserem Temperatursensor aussieht. Auf dem winzigen Microcontroller importiert dein Code board, konfiguriert einen I2C-Bus und liest kontinuierlich Temperaturwerte. Um diese Operation auf einen Raspberry Pi 5 zu skalieren, verbindest du den Sensor physisch mit den Header-Pins am Pi. Dann installierst du in deinem Linux-Terminal über pip Adafruit Blinka und den spezifischen Python-Treiber für deinen Temperatursensor. Du kopierst dein ursprüngliches Python-Script rüber, ohne eine einzige Zeile zu ändern. Wenn du das Script mit Standard-Python 3 ausführst, erkennt das board-Modul dynamisch, dass es auf einem Raspberry Pi 5 läuft. Es stellt automatisch die korrekten Pin-Definitions für dieses spezifische Board bereit. Das busio-Modul übersetzt deine I2C-Read-Requests nahtlos in Standard-Linux-I2C-Device-Calls. Dein Script liest die Sensordaten genau so, wie es das vorher getan hat. Hier wird es interessant. Da du jetzt Standard-CPython auf einer vollwertigen Linux-Machine ausführst, bist du nicht mehr durch die Memory-Limits eines Microcontrollers eingeschränkt. Dein Script kann den Hardware-Sensor über den Blinka-Translation-Layer auslesen und diese Daten dann sofort an umfangreiche Desktop-Libraries weitergeben. Du kannst Standard-Network-Requests nutzen, um die Metrics in eine Cloud-Datenbank zu pushen, die Telemetry mit Data-Science-Tools zu verarbeiten oder sie sogar über ein lokales Web-Framework auszuliefern. Hier ist die entscheidende Erkenntnis. Der Hardware-Interaktions-Code bleibt über völlig unterschiedliche Computing-Architekturen hinweg identisch. Indem die Sensor-Logik vom zugrundeliegenden Betriebssystem entkoppelt wird, lässt Blinka dich günstig auf Bare-Metal prototypen und auf vollständige Linux-Environments skalieren, mit null Hardware-Code-Rewrites. Damit schließen wir unsere Serie über CircuitPython ab. Ich ermutige dich, dir die offizielle Documentation durchzulesen, hands-on zu versuchen, einen Sensor mit Blinka einzurichten, oder devstories dot eu zu besuchen, um Themen für zukünftige Serien vorzuschlagen. Das war's für diese Folge. Danke fürs Zuhören, und keep building!