MicroPython (Claus Kühnel)

Claus Das ist ein Punkt, der mir an einigen Stellen bei MicroPython-Beschreibungen gefehlt hat. Deshalb ist das aufgenommen. Ich halte das für wichtig, vor allen Dingen, wenn man die ersten Grundlagen verinnerlicht hat, dann will man natürlich solche Features nutzen, weil, die sind einfach zu implementieren und bieten ungeheuer viel, gerade bei solchen nebenläufigen Prozessen, dass nicht ein Prozess den anderen blockiert und man sich wundert, dass hier sich nichts weiter dreht.

Ali Klüger als gestern mit Rheinwerk. Hallo und herzlich willkommen zu Klüger als gestern, einem Podcast des Rheinwerk Verlags. Mein Name ist Ali Hackalife und heute sprechen wir über MicroPython, ein Buch erschienen von Claus Kühnel über die Programmiersprache und über MicroPython als Konzept. Das Ganze ist erschienen als MicroPython, das Handbuch für Maker und IoT-Development. Und heute ist er mir zugeschaltet. Hallo Claus.

Claus Hallo Ali.

Ali Bevor man so ein Buch schreibt, wirst du vermutlich auch viel Zeit als Hobbyist mit Mikrocontrollern verbracht haben?

Claus Ja, aber nicht nur als Hobbyist. Mikrocontroller haben mich eigentlich fast mein ganzes Berufsleben begleitet. Das ging los mit dem legendären Z80 und hat sich dann weiter fortgesetzt über, Mikrocontroller von Atmel. Das ist ein ganz wesentlicher Punkt gewesen, diese AVR-Mikrocontroller, die heute immer noch die Basis sind für die Arduino-Familie. Anfangs habe ich dann in Basic programmiert. Es gab da einen interessanten Basic-Compiler. Später kam dann C hinzu, C-Programmierumgebung. Damit habe ich sehr viel gemacht. Auch beruflich habe ich damit gearbeitet. Wir haben in meinem Job Mikrocontroller eingesetzt zur Steuerung von Laborautomaten. Das heißt also, im Wesentlichen sind das Dinge gewesen, die in einem Laborautomaten Bewegungen gesteuert haben, Sensorik ausgelesen haben etc. Und bei dieser Arbeit, die sehr stark interdisziplinär geprägt war, bin ich mit Biologen zusammengekommen, mit Chemikern, die praktisch den Prozesshintergrund für das Ganze geliefert haben und natürlich mit Ingenieuren, Softwareentwicklern, Hardwareentwicklern, die das Ganze dann in Mechatroniksysteme umgesetzt haben.

Ali Das kommt mir sehr vertraut vor. Ich habe genau das auch schon mal gemacht für eine Frau, die ihre Bio-Doktorarbeit entwickelt hat. Sie hat ein Experiment gehabt und ich habe dann bei der Programmierung geholfen, dass entsprechend ein Konditionierungsversuch gemacht werden konnte. Das ist mir ein sehr vertrauter Bereich, dass jemand eine Idee hat, aber nicht das Technik-Know-how und dann die Frage an die Techniker, Macher, Bastler, Elektroingenieure kommt, wie setze ich das jetzt um?

Claus Richtig, genau das ist eigentlich der Punkt. Ich bin also mit einer breiten Wissensbasis dort konfrontiert worden. Wir haben manchmal Prototypen von Biologen oder Biochemikern gesehen, wo wir gesagt haben, ja, über die Umsetzung haben wir ehrlich gesagt manchmal geschmunzelt. Aber die Idee war gut und wir haben dann in der Regel diese ganze Idee industrialisiert. Das wäre aber uns ohne dieses biologische Hintergrundwissen nie möglich gewesen. Also das heißt, für mich war wichtig, diese breite Basis. Und damit schließt sich eigentlich ein Stück zu dem, was mich beruflich immer wieder begleitet hat, das ist diese Maker-Szene. Aus diesem anfänglichen manchmal Schmunzeln ist eigentlich eher eine gewisse Bewunderung entstanden, dass man sich mit nicht immer den geeigneten Mitteln an eine solche Sache herangetraut hat, die dann vorangetrieben hat und dann mithilfe anderer. Wie es in der Community üblich ist, mithilfe anderer in wirklich ernstzunehmende Produkte umgesetzt hat. Diese Breite, also diese Maker-Bewegung in dem Sinne, die hat mich eigentlich die ganze Zeit begleitet. Und das ist auch ein Stück, was für dieses MicroPython-Buch den Hintergrund geliefert hat. Die C-Programmierung, die natürlich heute immer noch für die Mikrocontroller oder überhaupt für industrielle Anwendungen im Vordergrund steht, weitgehend im Vordergrund steht, immer noch ziemlich unangefochten, wird ergänzt durch MicroPython beispielsweise. Was schon stellenweise in der Ausbildung gelehrt wird. Und meine Enkeltochter studiert Biologie an der Universität Zürich. Die hatte eine Python-Vorlesung. Also das heißt, selbst elektronikferne Leute lernen heute Programmieren in einer Hochsprache. Und das ist eben heute in der Regel Python. Die ist am verbreitetsten, setzt auf einer riesigen Menge von Bibliotheken auf. Und das ist mit MicroPython zugänglich gemacht worden, eben auch für Mikrocontroller. Und das hat mich gereizt, diese Mikrocontroller-Ebene in dem eben gezeigten Kontext so zu verbreitern, dass auch andere Nicht-Elektroniker, Nicht-Softwerker, mit diesen Controllern arbeiten können und ihre Ideen umsetzen können.

Ali Das, was du vorhin erwähnt hast mit der Community, das ist ja bei MicroPython schon in der Grund-DNA. Das ist aus einer Kickstarter-Kampagne heraus entstanden, weil Leute gesehen haben, es gibt da diesen Bedarf. Und auch das, was du sagst, ich habe MicroPython kennengelernt als Hobbybastler. Ich war genau in dem Alter, als man als Teenager mit Elektronik rumfrickelt und ich war, als es Kickstarter war, gerade 14. Dementsprechend hat mich das eigentlich immer begleitet, wenn ich an IoT gedacht habe und an so Breadboard- und Microcontroller-Programmierung. Aber dann zu sehen, wie aus die Maker-Szene und Hobby-Bastler hin zu jetzt echten Industrieanwendungen, wie sich das so nach und nach daraus professionalisiert hat und jetzt eben die Schnittstelle ist aus einer sehr zugänglichen Programmiersprache mit einer Syntax, die Python weitestgehend ähnlich ist und eben der Community, die für quasi alles mittlerweile Libraries gebaut hat. Das ist schon wirklich sehr besonders und das macht diese Sprache auch aus.

Claus Beziehungsweise ich habe dann mehr mit CircuitPython gemacht.

Ali Das ist ja eine auf MicroPython basierende Erweiterung der Sprache, die sich konkret auf den ganzen Kosmos der Adafruit-Controller konzentriert. Aber wir können vielleicht mal größer einsteigen und sagen, was sind denn Mikrocontroller?

Claus Ja, Mikrocontroller sind kleine Chips, die einen Rechnerkern tragen und dieser Rechnerkern wird ergänzt durch heute recht umfangreiche Peripherie. Das heißt, ich habe digitale und analoge Ein-/Ausgänge, sodass ich direkt in einen, Prozess hinein lauschen oder steuern kann. Ich habe umfangreiche Timer, um zeitbasierte Anwendungen zu bringen. Ich habe ein Interrupt-System, um auf Echtzeitereignisse reagieren zu können. Ich habe Speicher, den Programmspeicher und RAM, also Speicher für Variablen etc., direkt auf dem Chip. Und sodass ich eigentlich sagen kann, ich habe einen kompletten Computer mit peripheren Einrichtungen auf einem Chip. Das unterscheidet einen Mikrocontroller von einem Mikroprozessor, der nur den Kern eigentlich beinhaltet und das andere durch zusätzliche Schaltungsteile ergänzen muss. Und bei einem Mikrocontroller ist das alles auf einem Chip vereint, weil die Zielrichtung, ist, diesen Mikrocontroller in ein Gerät einzubetten, wo er im Grunde genommen eigentlich nicht mehr sichtbar ist, wo er verschwindet. Deshalb auch der Begriff Embedded Systems. Wir sehen den Mikrocontroller im Kühlschrank nicht, wir sehen den in der Waschmaschine nicht. Im Auto sehen wir ihn eigentlich nur durch das GUI, also durch das Bedienteil. Dann können wir erahnen, dass dahinter Mikrocontroller stehen. Aber es ist ja auch vom Auto nicht nur einer, sondern es ist im Grunde genommen ein Netzwerk von Kontrollern, was sich dort befindet. Alles das erahnen wir nicht. Deshalb der Begriff des Embedded Systems, des eingebauten, verborgenen Systems. Ja.

Ali Und das macht es für die Hobby-Szene bei den Mikrocontrollern so interessant, dass wenn man jetzt zum Beispiel mit einem ESP32 sich selbst ein smartes Gerät bauen möchte, ein IoT, ein Internet-of-Things-Gerät und sei es sowas wie, ich möchte eine Lampe an- oder ausmachen oder ein Freund hatte mir letztens gezeigt, er hat ein altes Tastentelefon mit Hörer und so weiter umgebaut, sodass, wenn er jetzt die verschiedenen Tasten drückt, er die Lichter in seinem Wohnzimmer heller und dunkler steuern kann. Und da hat er dann den Mikrocontroller in dem Telefon versteckt, das optisch erstmal aussieht wie einfache Deko und steht rum, aber damit kann er dann die Lampen heller und dunkler machen oder bestimmte Szenarios auswählen. Und da reden wir ja mittlerweile auch von Technik, so ein ESP32, der kostet so viel wie ein Coffee to go am Bahnhof zu trinken. Also die sind wirklich erschwinglich geworden und haben mit sich gebracht, dass viele Leute dem mal einen Versuch geben und mit MicroPython da dann auch eine Anlaufstelle haben, die sehr viel einfacher ist, als es zum Beispiel C oder andere hardwarenahe Programmiersprachen früher gewesen wären. Und da ist auch, würde ich sagen, eine der wichtigsten technischen Unterscheidungen mit MicroPython, nämlich wie es funktioniert, dass es Bytecode ist, der in seiner eigenen virtuellen Maschine läuft und extrem darauf optimiert ist, wenig Speicher zu verbrauchen und deswegen auf diesen sehr kleinen, wenig Energie verbrauchenden Controllern auch gut funktioniert. Also natürlich alles jetzt idealisiert. Es gibt auch Mikrocontroller, die sind extrem teuer, weil sie sehr spezifisch sind. Es gibt Mikrocontroller mit deutlich mehr Speicher für die Anwendung, aber das Gros der Mikrocontroller sind relativ preiswerte kleine Chipsätze.

Claus Ja, das wird natürlich auch dadurch möglich, dass diese Mikrocontroller in Geräten, wie ich es gerade erläutert habe, verschwinden und damit in riesigen Stückzahlen produziert werden. Und diese riesigen Stückzahlen lassen es natürlich zu, dass die Preise reduziert werden. Und davon kann unsere Community profitieren, dass die Controller in so großen Stückzahlen da sind, preiswert sind und mit dieser großen Stückzahl sich auch eine entsprechend große Community dann ausbildet. Also das ist so ein Kreislauf, der sich eigentlich, ich sage mal, ein Stück weit selbst befruchtet.

Ali Und dann hast du in deinem Buch, das ich in der Vorbereitung gelesen habe, sehr detailreich erklärt, was so Sachen wie Best Practice sind, wie man optimiert, denn Natur der Sache ist, wenn ich mit wenig Speicher operiere, dann muss ich darüber nachdenken, wie ich Ressourcen verwende. Das war früher noch ein größeres Problem als heute, wenn man sich anschaut, was Leute an komplexer Software in Disketten reingepresst bekommen haben. Und wenn ich mir anschaue, wie oft es mir noch passiert, dass ich eine Library im Projekt habe, die ich gar nicht mehr benutze, weil das noch irgendwo aus der Testphase drin liegt, was halt früher undenkbar gewesen wäre und heute mit verfügbarem RAM und verfügbarem Speicher etwas ist, wo man nicht so groß drüber nachdenkt. Bei Mikrocontrollern ist das wieder anders. Da geht es dann wieder mehr um Optimierung und da gibt es dann ja bei MicroPython auch so Sachen wie die .mpy, die Module in MicroPython, die schon bereits vorkompilierter Bytecode sind, die man einbinden kann, damit sie speichereffizienter sind.

Claus Ja, das ist ein ganz wesentlicher Punkt. Ich hätte ja grundsätzlich die Möglichkeit, mit MicroPython das noch alles selbst zu installieren. Bloß das geht dann sehr stark ins Eingemachte. Diesen Weg will man eigentlich nicht gehen und man möchte vorgefertigte Komponenten verwenden, die diesen Anspruch bereits haben, den du genannt hast, die optimiert sind hinsichtlich eines Embedded Systems, also einer Anwendung in einem kleinen System. Ich kann also Funktionen, die relativ komplex sind, in Libraries auslagern, entweder vorkompiliert oder als .py, also, als reines Python-Skript, kann diese ins System einbinden und kann es so ähnlich wie es bei C ist, wo ich bestimmte Libraries verwenden kann, kann ich, mein ganzes Projekt auf einer sicheren Schiene aufsetzen, die schon praktisch voroptimiert ist. Ich sollte dann einfach darauf achten, dass ich in meinem eigenen Stück Code, der in der Regel dann das Ganze organisieren soll, orchestrieren soll, dass ich dann nicht diese Vorteile wieder zunichte mache, indem ich das. Unmöglich programmiere. Aber auch dazu sind Dinge im Buch angegeben, wie ich dort vorgehen kann, eben in diesem von dir eben genannten Kapitel Best Practice. Das ist übrigens ein Punkt, der mich dazu geführt hat, dieses Buch zu schreiben. Ich habe eine ganze Reihe von MicroPython-Büchern gesehen, gelesen, überflogen und die sind oftmals an Anfänger für Anwender gedacht, aber dort, wo es interessant wird, hört das oftmals auf. Und das hat mich bewogen, mich dort eingehender damit zu befassen. Wir haben heute Mikrocontroller, die mehrere Kerne haben. Die versprechen natürlich dann, Sachen zu implementieren, die auf unterschiedlichen Kernen laufen. Wenn man dann die konkreten Implementierungen anschaut, merkt man, dass es auf einmal doch gar nicht so ohne weiteres möglich ist oder nur unter bestimmten Bedingungen. Auf solche Dinge gehe ich ein. Oder auf Multitasking und Interrupts, die für meine Begriffe gerade im Embedded-Bereich sehr wichtig sind. Dann hatten wir gesagt, dass wir versuchen wollen, für einen kleinen Controller möglichst optimierten Code zu schreiben. Dafür gibt es Tools, wo ich meinen Code, bevor er überhaupt auf den Controller kommt, kontrollieren kann. Also ich zeige, wie man mit Ruff einen sehr einfach anzuwendenden Tool Code optimieren kann. Oder Code erstmal lesbar gestalten kann, syntaktisch so auslegen kann, dass es ein pflegbarer Code ist. Denn man muss ja bedenken, es wird in der Regel eine bestimmte Version erzeugt, die erfüllt mehr oder weniger, ich hoffe mehr, die Anforderungen, die gestellt worden sind. Und dabei bleibt es aber in der Regel nicht. Man kommt zu neuen Erkenntnissen, man möchte Funktionen erweitern, also der Code wird weiterentwickelt, er muss gepflegt werden, er wird weiterentwickelt etc. Und dazu dienen solche Tools, die verwendet werden, um den Code eben in einer lesbaren und weiterverarbeitbaren Form zu halten. Auf solche Dinge gehe ich ein und nicht zuletzt sind ein großer Anteil, ich glaube etwa 100 Seiten, Anwendungen gewidmet, wo dem IoT-Gedanken sehr stark Rechnung getragen wird. Für mich ist heute, ich komme noch mal auf den Kühlschrank oder die Waschmaschine, das sind heute in der Regel noch isolierte Geräte. Also der Kühlschrank könnte zwar theoretisch, solche Beispiele hat es gegeben, Internetverbindungen haben und dann bevor die Milch alle wird, wird Neues bestellt, aber das ist ja in der Regel Wunschdenken geblieben bis heute. Vielleicht gibt es einige Exemplare, ich weiß das nicht genau, aber viel interessanter für Embedded Systems ist ja der Kontakt zum Internet. Dort habe ich versucht, Beispiele zu zeigen, wie einfach es sein kann, dass man mit, geeigneten Tools, also in dem Fall ist es der MicroDot-Webserver, den ich dort eingesetzt habe, wie ich dort. Mit wenig Aufwand eine ansprechende Oberfläche, zum Beispiel auf dem Smartphone, erzeugen kann, um einen Embedded System zu steuern. Ich habe das dort anhand von einer Raumüberwachung gemacht, wo Daten ausgegeben wurden und so ein Klimaindex ausgegeben wird, rot, grün, gelb. Der die Luftqualität kennzeichnet oder einen Schlafmonitor, der die Bedingungen im Schlafraum überwacht, die dann ausgewertet werden und bewertet werden. Ich habe dort Anwendungen hineingebracht, wo die künstliche Intelligenz eine Rolle spielt. Ich frage also einen KI-Agenten über eine API-Schnittstelle ab, wie die Wetterbedingungen sind, ob Regen zu erwarten ist, zum Beispiel durch so ein Forecast oder besser gesagt ein Now-Cast. Das musste ich erst lernen, dass es sowas auch gibt. Also ein Kurzzeit-Forecast wird als Now-Cast bezeichnet. Und diese Daten sind im Internet abrufbar, eben über so eine KI-Schnittstelle abrufbar und können dann zeigen, ob ich in der nächsten halben Stunde mit einem Starkregen zu rechnen habe oder nicht. In so Gewitterumgebungen ist das mitunter eine ganz interessante Mitteilung.

Ali Generell, Wetter ist ja für das optimierte Smart Home eine Sache, da habe ich letztens noch mit einem Freund drüber nachgedacht, weil wir für sein Smart Home was programmiert haben. Er hat eine Solaranlage auf dem Dach und jetzt, wo es im Moment ja immer mal wieder sehr heiße Wochen hat,

Claus Möchte er das optimal nutzen.

Ali Dass wenn die Solaranlage sagt, es ist gerade so und so hell, dass sich die Blenden vor seinen Fenstern einfach zuziehen, damit es in der Wohnung nicht so sehr aufheizt und das miteinander zu verbinden. Also die im Prinzip Now-Cast aktuelle Messung von wie hell ist es gerade auf dem Dach zu verwenden, um zu sagen, jetzt mach die Blenden mal zu, damit das Haus nicht so sehr aufheizt und dann kontrolliere mit dem Sensor innen, ob es was gebracht hat. Das sind so kleine Spielereien, für die macht es einfach auch Spaß, sich die Umgebung intelligenter und vernetzter zu machen und dann vor allem das Ganze mit Tools, die man selbst gekauft und selbst gebaut hat, sodass man nicht abhängig ist von irgendeinem Aboservice oder irgendeinem Drittanbieter aus China oder den USA. Also halt die Autonomie über das eigene Smart Home zu gewinnen, dafür ist diese ganze IoT-Entwicklung großartig.

Claus Absolut. Solche Beispiele habe ich also auch verwendet. Und ich hatte mir jetzt gerade selbst das Stichwort KI gegeben. Das ist auch so ein Punkt, den man beim Programmieren heute mit berücksichtigen sollte. Die Programmerstellung könnte ich ja theoretisch komplett der KI überlassen. Ich schreibe mir ein Programm und dann gibt es eine Liste von Anforderungen, die ich abgebe und dann spuckt die KI irgendetwas aus. Im Falle von MicroPython, sind diese Ergebnisse recht interessant. Der Hintergrund ist, zu den Trainingsdaten, die für die KI verwendet wurden, sind unendlich viele MicroPython-Programme mitverwendet worden. Demzufolge ist auch das Ergebnis stellenweise interessant, aber man sollte mit einem klugen Blick dieses Ergebnis bewerten. Es gilt also nicht nur, Bilder auf Fakes hin zu untersuchen, ob jemand fünf Finger hat oder solche Dinge, die wir alle schon gesehen haben, sondern man sollte sich auch den Code genau anschauen. Und den Code, den die KI liefert, den sollte man verstehen. Und wenn man den nicht versteht, dann sollte man daran zweifeln, dass er richtig ist.

Ali Also auch das ist ja eben bei MicroPython für so einfache Sachen wie, ich möchte diesen Sensor auslesen und in diese Variable schreiben. Da habe ich gar keine Bedenken, dass die KI das 100 Prozent oder 99,9 Prozent akkurat machen wird. Aber wenn ich dann ein größeres Projekt habe, wo ich mehrere Dinge auch nebenläufig zueinander habe, da bin ich dann doch oft da reingelaufen, dass dem, was das LLM im Moment produziert, wie gesagt, wir nehmen 2026 auf, wenn das hier jemand in zehn Jahren hört und nicht versteht, wovon wir reden. Im Moment ist es so, dass bei größeren Projekten so Sachen wie Speicheroptimierung sehr mittelmäßig sind. Das liegt halt daran, dass es gelernt hat aus allen verfügbaren Projekten und die sind halt im Schnitt mittelmäßig. Und ich merke dann aber auch wieder, dass wenn man in die Debugging-Phase und ins Evaluieren des Code kommt, also du hast ja auch REPL als Methode in deinem Buch erwähnt, also dass ich read, evaluate, print, was war das L? Loop, genau. Genau, also dass ich in die Schleife komme, dass ich alles, was ich mache, debugge, indem ich es lese, evaluiere, ausgebe und das dann wieder von vorne. Und bei solchen Bewertungen von eben diesem REPL, da finde ich es KI dann auch wieder sehr gut, um mir zu helfen, zu verstehen, was ich vor mir habe. Aber dafür muss ich halt auch schon was mitbringen, um überhaupt einsteigen zu können in das, was da rausgekommen ist.

Claus Richtig. Deshalb kommt man nicht umhin, auch diesen, einführenden Abschnitt zu lesen und zu verstehen, wo ich eben über Listen, Tuples und Variablen und so weiter, also über die Grundlagen spreche. Das ist wichtig, dass ich den KI-Vorschlag, so möchte ich es mal nennen, den KI-Vorschlag bewerten kann. Wenn ich ihn verstanden habe, kann ich ihn ausprobieren. Und dann wird es oft Fehlerausschriften geben und die kann ich wieder der KI zurückschicken, kann sagen, das ist das Resultat und es kann eine Verbesserung geben. Ich habe es aber auch erlebt, dass die KI sich dann im Kreis dreht. Also das heißt, sie halluziniert und baut das nächste Ergebnis auf dem vorher falschen auf und damit kommt sie nie zum Schluss. Also es hat Dinge gegeben, wo ich dann abends geschlossen habe und meine letzte Meldung an die KI war, ich gehe jetzt ins Bett. Also es gibt Punkte, dort versagt es komplett. Eben, es befindet sich dann in so einem Endlos-Loop. Deshalb sollte man für meine Begriffe KI nutzen, unbedingt, aber kritisch nutzen.

Ali KI sehe ich da auch hilfreich im Bereich des allgemeinen Rapid Prototyping und das ist ja, wo Mikrocontroller ihre große Stärke haben, dass ich von der Idee etwas zu machen hin zu, ich stecke mal ein paar Sensoren auf das Breadboard und ich habe, also immer wenn ich mit Jumperkabeln arbeite, fühle ich mich, als würde ich gerade etwas wirklich Hochtechnisches bauen. Dabei sind das ja mittlerweile alles sehr genormte Steckverbindungen. Leute, die davon keine Ahnung haben, haben dann auch immer großen Respekt, wenn man auf dem Tisch vor sich jede Menge Kabel von hier nach da gesteckt hat und so weiter. Und das ist ja der Weg, dass man, also jetzt wieder meine Referenz aus den Biologie-Projekten, man entwirft einmal so ein Board mit Sensoren und schreibt den Code dafür. Und wenn das dann funktioniert, dann kann man es nochmal in schön machen, dass man das Board dann entsprechend auch ätzen lässt und die Sensoren fest verlötet und nicht steckt, sodass es dann in der Anwendung auch sehr viel robuster ist, wenn es irgendwo montiert wird oder überhaupt kleiner. Und um diese Prototypen herzustellen, bevor man dann die fertigen Systeme, die fertigen elektrischen Scan-Einheiten und so weiter gebaut hat, dafür sind Mikrocontroller einfach mittlerweile nicht wegzudenken. Und dieses Rapid Prototyping ist jetzt um ein weiteres Tool, Provisorium, durch KI erweitert worden. Und wir alle wissen, es gilt die alte Weisheit, nichts hält so lange wie das Provisorium, aber man sollte schon auch am Ende des Tages wissen, wie es richtig geht.

Claus Ja, das ist richtig. Ich nutze, um diese Provisorien ein bisschen zu umgehen, versuche ich oft Komponenten zu nutzen, die schon ein Gehäuse haben, die standardisierte Stecker haben. Ich habe also im Buch da auch einiges erwähnt, die vielleicht ein Display haben. Das Display steht bei solchen Embedded Systems nicht immer ganz im Vordergrund, aber es gibt eben Dinge, wo ich eine gewisse Bedienfunktion habe und wo ich es gerne vor Ort habe. Zum Beispiel ein Außensensor, der im Grunde genommen in einem Netzwerk arbeitet, dort bräuchte ich kein Display. Aber diese kleinen OLEDs, die heute an vielen Stellen eingesetzt werden und, von der Software-Seite her keinen Aufwand bedeuten, wenn man das noch anschließt und ansteuert, die sind im Grunde genommen hilfreich, wenn ich dann mal, im Außenbereich meinen Sensor anschaue und er zeigt mir vernünftige Daten an diesem Display an, dann kann ich davon ausgehen, dass auch die drahtlose Funkstrecke dann funktioniert und meine Daten ankommen. Also das heißt, die Vor-Ort-Batterie ist noch entsprechend geladen und das Ding arbeitet zuverlässig. In solchen Fällen kann ein Display wirklich hilfreich sein.

Ali Ich kann dir aus eigener Erfahrung sagen, es gibt nichts Ärgerlicheres, als wenn deine Status-LED einen Kurzschluss hat und du dich die ganze Zeit fragst, was in diesem Board kaputt gegangen ist, bis du rausfindest, ah, die LED, die ich benutze, um den Status zu überprüfen, die hat den Hau. Also ja, das ist etwas, man möchte mehr als einen Weg haben, um zu sehen, was gerade in diesem Sensor passiert. Aber da sind wir auch wieder bei etwas, dass MicroPython bzw. Diese Entwicklung mit Mikrocontrollern sehr eigen ist, dass sie sehr darauf optimiert sind, sie live zu debuggen, sie angeschlossen zu haben und direkt Werte auszulesen, die da rein und raus gehen. Also dass ich sehr viel, ich möchte jetzt nicht sagen am offenen Herzen, das klingt so drastisch, aber ich kann sehr viel in meiner Entwicklung live nachvollziehen und mein Code kompiliert live vor mir, während ich hingegen bei Hochsprachen wie C, wenn ich da hardwarenah entwickle, da brauche ich viel mehr als das, was schon bei MicroPython mitgebracht wird, um nachvollziehen zu können, was die Maschine vor mir macht.

Claus Das ist absolut richtig. Ich muss beim C-Programm dafür sorgen, dass an der Konsole das ausgegeben wird, was ich als Debug-Mitteilung sehen möchte. Und im Grunde genommen bringt MicroPython mit einem einfachen Ausgabebefehl das bereits mit. Also das ist für die Fehlersuche ganz essentiell. Das kann man ja anfangs über die Serialschnittstelle gut machen, so wie es ursprünglich auch gedacht ist. Aber die meisten, du hattest vorhin ESP32 erwähnt, die meisten Controller bringen auch Bluetooth mit, sodass ich am Anfang das drahtgebunden machen kann und später über Bluetooth, also vor allen Dingen über BLE, Bluetooth Low Energy, dann Mitteilungen ausgeben kann. Und dann praktisch über das Handy die Debug-Mitteilungen sehe. Also solche Dinge habe ich hier im Buch auch betrachtet. Unter anderem ein ganzes BLE-Netzwerk. Ich habe verschiedene Temperatursensoren, im Internet zusammengekauft. Dort muss man bloß schauen, nicht alle haben offengelegte Protokolle. Gerade in China gibt es interessante Sensoren, aber dort wird im Grunde genommen das Protokoll verschlüsselt. Damit habe ich danach keinen Zugang. Aber es gibt Sensoren, die das sehr gut ermöglichen, wo die Protokolle offengelegt sind. Und dort zeige ich, wie ich solche Sensoren in dem Netzwerk zusammenfügen kann. Und das könnte ich natürlich auch für einen Einzelsensor nutzen über so eine BLE-Kontaktkommunikationsstrecke.

Ali Und auch das BLE, also Bluetooth Low Energy, als Standard bringt schon sehr, sehr viele vorkonfigurierte Sachen mit, auch so Sachen wie mögliche Gesundheitsdaten dann geschickt werden können und so weiter. Das ist wirklich hochkomplex und dass ich das als Library in MicroPython einbinden kann, Bluetooth Low Energy, das ist wirklich beeindruckend. Und da gibt es die modifizierten Versionen, wie zum Beispiel, wir hatten ja jetzt hier schon mehrfach Nebenläufigkeit und Multitasking, so Sachen wie uasyncio. Das war mir vertraut, aber dein Buch hat da doch nochmal einen ziemlichen Grundlagen tiefen Einstieg gegeben, dass ich jetzt deutlich mehr verstanden habe von dem, was man da macht, weil man es sonst einfach nur aus Repositories übernommen hat, ohne wirklich mal durchzusteigen. Warum setze ich das so und so an? Denn wir befinden uns ja immer noch in Umgebungen, wo Speicher ein limitierender Faktor sein kann. Und besonders dann, wenn ich mehrere Dinge parallel habe, wie das Display ansteuern, eine GUI ausgeben, einen Sensor auslesen und so weiter, dann sind so Sachen wie Zeiten und das asynchrone Zeitmanagement halt wirklich relevant.

Claus Das ist ein Punkt, der mir an einigen Stellen bei MicroPython-Beschreibungen gefehlt hat. Deshalb ist das aufgenommen. Ich halte das für wichtig, vor allen Dingen, wenn man die ersten Grundlagen verinnerlicht hat, dann will man natürlich solche Features nutzen. Weil die sind einfach zu implementieren, wenn man mal das Grundprinzip verstanden hat und bieten ungeheuer viel, gerade bei solchen nebenläufigen Prozessen, dass nicht ein Prozess den anderen blockiert und man sich wundert, dass hier sich nichts weiter dreht. Gerade bei IoT-Sachen, wo ich nach außen eine Anfrage stelle, die Antwort kann kommen, die wird in der Regel kommen, aber sie muss nicht kommen. Und wenn dann mein ganzes Programm blockiert, dann ist das wenig wert.

Ali Und da kommen wir dann auch bei so Sachen wie Abtastraten an den Punkt. Eigentlich für die meisten Sensoren, die man so im Alltag verwendet, ist MicroPython schnell genug. Aber dann gibt es ja auch den Bereich, der sich jetzt mehr und mehr entwickelt. Also als ich mit MicroPython selbst angefangen habe, würde ich sagen, war IoT generell und Sensoren in Netzwerke hängen das, was das Aushängeschild war. Mittlerweile erlebe ich, dass es sich mehr und mehr zum Edge-Computing entwickelt, also dass ich bereits Sensoren und Sensorik mit an Bord habe, die selbstständig Prozesse durchlaufen kann, sodass das, was dann der Mikrocontroller verarbeitet, für ihn einfacher zu interpretieren ist und nicht mehr große Ressourcen im Mikrocontroller geblockt werden, weil ein Sensor gerade sehr hochfrequent misst. Und das sind dann so Sachen, da hat sich mittlerweile einfach die Community hin entwickelt, da hat sich die ganze Szenen entwickelt und das zeigt ja auch die Professionalisierung, dass es jetzt immer besser auch Richtung Industrieanwendung funktioniert.

Claus Absolut, absolut. Mir fällt gerade noch ein, weil du das mit dem Edge Computing sagst. Ich habe ja parallel dazu viel im Arduino-Umfeld gearbeitet. Beim Arduino ist jetzt durch die Übernahme von Qualcomm, Es sind ja Hochleistungs-Linux-Devices hinzugekommen. Also der Arduino Uno Q ist ein Device mit einem Mikrocontroller und einem, ich kann es gar nicht aus dem Stegreif sagen, irgendeine Nummer, kann ich nicht sagen.

Ali Und so ein mobilen Handychip, der da mit drauf ist.

Claus Ja, ja. Und die beiden bilden praktisch ein Duo. Der Mikrocontroller ist für die Sachen zuständig, die wir gerade besprochen haben. Wird dort ganz normal in C++ im Arduino-Umfeld programmiert. Und die andere Seite, die Linux-Seite, die wird in Standard-Python programmiert. Also dort ist wieder so genau der Punkt mit dem Edge Computing zu sehen. Der eine Teil macht die Echtzeitverarbeitung, also eben das Sampling von irgendwelchen Sensoren. Es gibt eine Bridge, die zwischen beiden Systemen liegt, die für die Datenübergabe zuständig ist. Und dann habe ich ein Linux-System, wie gesagt, in Python programmierbar oder, generell programmierbar in jeder Hochsprache, aber dort wird hauptsächlich Python eingesetzt. Das kann die ganze Verbindung dann ins Netz machen und aber auch bereits die Vorverarbeitung im Edge für leistungsstärkere. Programme, also die entsprechende Ressourcen anfordern. Das ist ein Punkt, der sich dann weiter erschließt. Es ist also die eine Schiene MicroPython auf kleinen Controllern selbst, oder aber die Verbindung von Controller bis hin zum Linux-Device, wo ich mit Python 3 dann konkret auf dem Linux-Device arbeiten kann. Dieser letzte Punkt ist im Buch nicht ausgeführt, es geht ja hier um MicroPython, aber, ich will nur sagen, wenn man sich mit MicroPython auf dem kleinen Controller, in einer abgegrenzten Umgebung erstmal auskennt, die Wege, hin zum umfangreicheren System, die bleiben natürlich offen.

Ali Und das sind dann so Sachen, da könnte man zum Beispiel lokale Bildauswertung von Kameras über den entsprechend leistungsstärkeren Prozessor machen und so.

Claus Ich habe ja hier im Buch auch Kamerabeispiele mit einem. OpenMV und mit einem RISC-Prozessor noch mit dem MaixPy. Also zwei relativ ähnliche Systeme. Die können schon eine ganze Menge. Aber dort bin ich natürlich wirklich an der Grenze dieser recht leistungsfähigen Controller, die dort eingesetzt werden. Dort würde sich das, was du gerade genannt hast, anbieten, dann die Bildverarbeitung, komplexere Bildverarbeitung in so ein Linux-System hinaus auszulagern. Aber viele Dinge kann ich heute schon mit leistungsfähigen Controllern machen. Da ist ein STM32 dahinter, hinter den OpenMV-Controllern und die ermöglichen schon eine ganze Menge. Ich habe dort ein ganz einfaches Beispiel gemacht. Ich habe eine Wetterkamera, die das Umgebungsbild aufnimmt und zusätzlich werden dort Messwerte eingeblendet ins Bild. Also das ist sowas relativ Einfaches, da bedarf es keiner großartigen Bildverarbeitung, da bedarf es nur dem Einblenden der Messdaten in den Bildspeicher. Das ist recht einfach zu lösen. Aber sobald es eben anspruchsvoll wird, Kantendetektionen oder Gesichtserkennung, dann bin ich dort natürlich auch relativ schnell am Ende.

Ali Ja, jetzt hattest du vorhin zu Beginn unseres Gesprächs schon mal gesagt, dass du Wert darauf gelegt hast, aus anderen Büchern hier Dinge zusammenzutragen, die dir zu kurz gekommen sind oder die du nicht so in dem Umfang gefunden hast. Das ist eine der Sachen, die bei dir sehr im Detail beschrieben wird, wo ich erst gedacht habe, das weiß ich doch und dann nochmal wirklich ein paar Aha-Momente hatte. Das war zum ganzen Thema der Kontrollstrukturen. Also vor allem bei Break, Continue und Pass. Ich habe natürlich mit try und Go to Fail und so weiter schon rumgespielt. Also try und except ist das ja bei MicroPython. Aber das war so etwas, wo ich, also das hat man halt reingeschrieben, damit es sich nicht endlos an einem Prozess auffängt. Aber dass man auch das so sehr benutzen kann, um bewusst Prozesse zu optimieren und effizienter zu machen, das habe ich, sind wir ehrlich, das habe ich bisher schmerzlich vernachlässigt, weil es nie so kritisch war. Und da gibt dein Buch wirklich nochmal einen tiefen Einblick, warum das so relevant ist. Kannst du das in wenigen Worten für die Leute zusammenfassen, was das an Effizienzgewinn bringt?

Claus Ja, der normale Weg ist ja der, dass ich Ausnahmen benenne in diesem Konstrukt und auf diese dann reagiere. Also das Standardbeispiel ist immer die Division durch Null. Dass mir die nicht passiert, das fange ich mit so einem Konzept ab. Ich kann aber andersherum das auch nutzen, indem ich sage, ich schreibe einen Konstrukt, gerade bei solchen Brute-Force-Attacken ist das ja so, dann, erzwinge ich eine Ausnahme. Also das heißt, im Umkehrschluss, ich ziele darauf, dass ein Fehler geworfen wird. Und den kann ich dann separat auswerten. Das ist eigentlich, ich sage mal, der umgekehrte Prozess. Und wenn ich diesen gehe, kann ich Dinge abfangen, die nicht einfach vordefiniert sind, sondern, wie soll ich das sagen, die nicht definiert sind. Das klingt blöd, aber ich habe praktisch eine zusätzliche Ebene, um nicht Fehler abzufangen, sondern um bestimmte Situationen abzufangen, die im Programm entstehen können.

Ali Beim Katastrophenschutz spricht man von den Known-Unknowns, also dass ich weiß, dass hier etwas kommen kann, von dem ich nicht weiß, wie es aussieht und dass ich das dann mit in meine Entwicklung einbeziehe.

Claus Das habe ich jetzt umständlich mit ‚nicht nicht‘ gemacht. Dein Begriff gefällt mir besser.

Ali Es gibt auch die Unknowns, aber da wissen wir noch nicht genau, was sie sind.

Claus Ja, ja, ja.

Ali Auf jeden Fall, genau dafür möchte ich meinen Code ja optimieren, dass ich einerseits keine Attacken habe und andererseits keine Fehler, die passieren, wenn zum Beispiel ein Sensor keinen Wert mehr liefert, aber ich mich auf den Sensor verlassen habe, dass ich dann eine sichere Konstruktion habe, die sagt, das Programm muss jetzt hier einen Fehler werfen und kann nicht die ganze Zeit einen Sensor messen, der nicht mehr antwortet.

Claus Richtig, richtig. Ich könnte ja dann einen Ausweichzweig definieren, der entweder den Sensor als Out-of-Order kennzeichnet oder aber wahrscheinliche Werte annimmt. Das könnte man ja jetzt wieder aus der Vergangenheit dann sagen, mein Sensor ist defekt, aber ein gültiger Wert wäre der und der, sodass praktisch mein Algorithmus weiterläuft. Aber ich könnte das Ergebnis als unsicher markieren.

Ali Und ich merke, dass generell, wenn ich mich mit Mikroelektronik befasse... Das mache ich jetzt als größeren Bogen raus, weg von den Kontrollkonstrukten. Es verändert meine Art, über Probleme nachzudenken, wenn ich Sensorik kenne. Und da finde ich sehr gut, dass du in deinem Buch auch viele Sensoren aufzählst. Ich brauche dann meistens auch noch eine praktische Anwendung, aber dann fängt man an darin zu denken, wie kann ich diesem Problem mit den Sensoren begegnen. Und um nochmal zum Anfang von unserem Gespräch zu kommen, ich hatte mit einer Biologin eine Unterhaltung darüber, dass sie einen Lernversuch haben, wo Fische auf einen Reiz reagieren sollen, also ein Lichtsignal reagieren sollen. Und wenn der Fisch sich falsch verhält, dann soll es einen Negativreiz geben. Also wir reden jetzt nicht davon, dass der Fisch gequält wird, sondern der Professor hatte damals vorgeschlagen, ja dann klopfen sie doch einfach mit einem Lineal von außen ans Aquarium, dass es halt einen Reiz gibt, auf den der Fisch reagiert. Und da meinte sie, aber da muss ich ja für jedes Training und der Fisch sollte viermal täglich trainieren, viermal täglich in die Uni kommen. Dann hat sie mir das ganz traurig erzählt und ich meinte, ja, wir können ja mal gucken, einfach einen Vibrationsmotor, der dann leicht gegen die Scheibe klopft, ob es das auch tut und stellt sich raus, ja, mit einer Kamera kann man sehen, wie sich der Fisch verhält und man kann das jetzt aus der Ferne machen. Aber genau das sind halt so Szenarien. Der Professor, der denkt in, wie entwickeln sich diese neuronalen Zellen in dem Fisch. Der denkt jetzt nicht konkret darüber nach. Und wie baue ich das Experiment dafür? Sagt ihr, ja, also zu meiner Zeit, da sind wir noch viermal am Tag in die Uni gekommen, um unseren Versuch zu betreuen. Ab dem Moment, wo man über die Möglichkeiten von Sensoren weiß, fängt man an, anders zu denken, wie man sich einem Problem nähern kann. Dementsprechend mag ich solche Beispielkataloge, wie du sie auch gemacht hast in deinem Buch immer sehr.

Claus Ja, das ist absolut richtig. Ich kenne das aus meiner eigenen Ausbildung. Ich habe also auch nicht-lineare Gleichung mit einem Tischrechner vor 100 Jahren gemacht und der brauchte für die Berechnung des Gleichungssystems anderthalb Stunden. Und da, ich bin dann alle anderthalb Stunden nach Hause gefahren, habe das Ergebnis notiert, den nächsten Job angestoßen und bin wieder weg. Also ich kenne das sehr gut.

Ali Ja, und wie gesagt, da gibt Technik einem einfach Möglichkeiten, Dinge anders zu denken und Dinge auch weiterzudenken. Und vielleicht das mal als Schlussakkord. Du hast jetzt dieses Buch geschrieben darüber, was es für die Maker-Szene und IoT-Development bedeutet. Welche Trends zeichnen sich gerade ab? Du hast schon erwähnt, dass du einen KI-Request über die API machst. Das würde ich sagen, ist gerade das große Thema, das ganz viel im Bereich Mikrocontroller dominiert. Aber siehst du etwas, wo gerade der Trend hingeht oder was dich neu interessiert?

Claus Was mich neu interessiert, sind vernetzte Systeme, also so Mesh-Netzwerke. Das Stichwort ist dazu Meshtastic. Ich weiß nicht, ob du das kennst.

Ali Kurz erklärt, das ist ein Funknetzwerk, das dadurch, dass man mit vielen Sendern und Empfängern verbunden ist, zum Beispiel Nachrichtenübermittlung ermöglicht. Und Leute bauen sich so kleine Walkie-Talkie-artige Geräte, um Nachrichten in SMS-Größe über dieses Netzwerk zu verschicken. Aber halt nicht über GSM, nicht über WLAN, sondern eben über diesen Funkstandard.

Claus Ja, das ist absolut richtig. Der Funkstandard ist LoRa. Es braucht keine Infrastruktur. Die Nachrichten springen praktisch von Knoten zu Knoten. Und das Netzwerk ist ein Mesh-Netzwerk. Das heißt, wenn ein Knoten ausfällt, heilt sich das selber. Es gibt andere Kommunikationswege. Eine Nachricht wird nicht nur über einen Weg verschickt, sodass es also ein redundantes System ist. Gerade. Für den Katastrophenschutz ist es sehr interessant, weil es dort leicht passieren kann, dass die kommerziellen Systeme ausfallen. Das heißt, ein reiner Stromausfall reicht schon zu, dann ist alles andere vorbei. Und dieses System arbeitet im Wesentlichen mit batteriegestützten Knoten, gepuffert durch Solar und solche Dinge. Das kann ich mir vorstellen. Das ist in der Anfangsphase noch, das wird sich entwickeln. Es gibt also nicht nur das Meshtastic, es gibt MeshCore, es gibt einige Systeme, die da parallel entstehen. Was sich dann durchsetzen wird oder ob alles so bleiben wird, das steht noch aus. Das ist eine Sache. Bei der Sensorik wird es natürlich auch Entwicklungen geben, die batteriebetrieben sein können. Also es gibt teilweise Sensorik heute, die kann ich nicht mit der Batterie betreiben, weil sie selber noch zu viel Strom verbrauchen. Also dort wird es auch Änderungen geben. Bei der Aktorik, also du hattest das mit dem Vibrationsmotor genannt, gibt es schon solche Entwicklungen, die vor allen Dingen durch die Wearables, also durch Uhren und so weiter getragen werden. Dieser Mikromotor ist ja so ein Beispiel. Wir haben alle einen Vibrationsalarm, in der Armbanduhr, wenn man so eine Smartwatch hat. Und dort wird es also Dinge hingeben, die in Richtung Verkleinerung sind. Bei Mikrofonen, die MEMS-Entwicklung. Elektromechanische Systeme auf dem Chip, das sind Dinge. Und wo ich denke, wo wir jetzt noch am Anfang stehen, das ist, der Punkt dieser kombinierten Rechner, was ich vorhin mit dem Uno Q genannt hatte, das wird auch zunehmen. Es ist von Qualcomm oder von Arduino ist schon der nächste angekündigt, der, ich denke mal, eher in die professionelle Ecke schielt, weil der Linux-Teil sehr komplex ist und sehr leistungsfähig ist. Das wird wahrscheinlich so das Arduino-Umfeld nur noch bedingt tangieren, aber das wird die Zeit zeigen. Und natürlich Mikrocontroller, auch dort wird es Änderungen geben. Der Raspberry Pi Pico ist auch schon so ein Beispiel, habe ich im Buch auch beschrieben. Der hat erstens mal zwei Kerne. Das ist der einzige Controller, wo ich wirklich den zweiten Kern für Parallel, also für Nebenläufigkeit nutzen kann. Und er hat zusätzlich noch State-Machines, State-Machine-Ausgänge, die separat programmiert werden können, die dann Kommunikation zum Beispiel. Über ein serielles Interface zu einem Sensor übernehmen können, wo ich wirklich taktgenau, oder mikrosekundengenau die Takte programmieren kann und so für bestimmte, proprietäre Interfaces gut vorbereitet bin. Aber, Es werden auch für die Standard-Interfaces bereits Libraries oder Code-Segmente, bereitgestellt, wo ich das also ohne tiefes Eindringen dann diese State-Machines nutzen kann. Also eine komplexer werdende Mikrocontroller-Struktur, du hattest das vorhin mal genannt, wo durch die intelligente Peripherie der Core selbst entlastet wird. Also ich könnte zum Beispiel dieses ganze Bitbanging oder sowas, was ich stellenweise für ein SPI-less Interface brauche, lagere ich aus in so eine State-Machine und die CPU ist komplett frei davon.

Ali Das ist, was auch so meine Beobachtung ist. Wie gesagt, ich habe das als Teenager im Hobby-Bastel-Bereich entdeckt, wie Mikrocontroller aufgekommen sind. Und wir erleben, dass sie einerseits so günstig sind wie noch nie, so zugänglich wie noch nie. Es gibt jetzt mit deinem Buch noch ein Buch mehr. Also es gibt viel Wissen darüber, wie man mit auch wirklich Grundlagen einsteigen kann. Und es wird immer professioneller. Also das ist weit weg von dem verrückten Bastelprojekt, mit dem man nur die eigene Modelleisenbahn steuert, hin zu, du lernst da Dinge, die dann auch an echten Industrieanlagen oder, also bei LoRa muss ich immer daran denken, ich kenne das ganz viel aus Uniprojekten zum Thema Umweltmessung, wo man dann Wetterstationen in der Natur verteilt, die mittlerweile auch, also wenn ich mich daran erinnere, als ich angefangen habe, hatte ich, so 2014 wird es gewesen sein, mal einen Gasspektrometer gesehen. Das stand auf dem Tisch, das war fast so groß wie ein Schuhkarton und es war einfach sehr, sehr teuer. Und mittlerweile gibt es vergleichbare Messgeräte, die passen zusammen mit dem Mikrocontroller und der Antenne in eine leere Cola-Dose und können im Wald platziert werden. Also da ist einfach wirklich viel passiert.

Claus Ja, ich habe so eine Wetterstation seit mehreren Jahren autonom laufen. Die wird solar gepuffert, also mit Batterie betrieben, mit einem Solarschirm dran. Und das zeigt jetzt schon zuverlässig seit, vier oder fünf Jahren bei mir über LoRa die Wetterdaten an. Also ganz genau das, was du gerade gesagt hast.

Ali Und das ist eigentlich ein sehr schönes Einsteigerprojekt, dem du dich ja auch in deinem Buch unter anderem widmest. Ich glaube, wir haben relativ gut besprochen, warum man in dieses Buch reinschauen sollte und warum man MicroPython für die eigenen Bastelprojekte, aber auch für die professionellen Projekte in Angriff nehmen sollte. Danke, Claus, für deine Zeit. Claus Kühnels Buch heißt MicroPython und ist bei Rheinwerk erschienen. Danke und bis bald.