Python im Embeddedbereich – News von CircuitPython

[Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)]

Freunde der Hochsprachen im Embeddedbereich bekommen Neuerungen: sowohl MicroPython als auch CircuitPython werden permanent weiterentwickelt; ein HackChat verriet Informationen über die Unterschiede und Motivationen der beiden Produkte. Außerdem wurden einige interessante Designentscheidungen des CircuitPython-Teams diskutiert.

CircuitPython: 8.2.2 verfügbar

Das Anfang Juli ausgelieferte CircuitPython 8.2.0 erweiterte die unter https://docs.circuitpython.org/en/latest/shared-bindings/synthio/index.html bereitstehende synthio-API, die die Nutzung von CircuitPython-Boards im Audiobereich erleichtert. Nun steht mit 8.2.2 ein Fix zur Verfügung:

Notable changes to 8.2.2 since 8.2.1
    • Replace expired Adafruit IO SSL certificate. 
Notable changes to 8.2.2 since 8.1.0
    • Continued enhancement of synthio. 
    • RP2040 alarm.sleep_memory.

Problematisch ist, dass insbesondere am ESP32-S3 nach wie vor mit verschiedenen Problemen zu rechnen ist:

ESP32-S3 has significant issues with I2C devices that sleep or use clock stretching. Retry operations on these devices as necessary, or use ESP32-S2 boards. 
Espressif boards have ESP-IDF storage leaks and occasionally crash after extended WiFi use.

Für Version 9.0 – der Change Log steht unter https://github.com/adafruit/circuitpython/milestones/9.0.0 bereit – sind ebenfalls verschiedene Fehlerbehebungen geplant.

Bildquelle: GitHub

CircuitPython: iMX RT, neue ESP32-Varianten und mehr

Im unter https://www.youtube.com/watch?v=8VhdFH7UEEQ&t=299s bereitstehenden Video sprach das Team um Limor Fried über Neuerungen in CircuitPython. Die Zusammenarbeit zwischen Espressif und Adafruit bleibt excellent, Fried erwähnte mehrfach, dass alle neuen ESP32-Varianten so schnell wie möglich unterstützt werden. Am iMX RT wird ebenfalls aktiv gearbeitet.

Mehr USB-Hostunterstützung, beispielsweise für Tastaturen

Ein derzeit in aktiver Entwicklung befindlicher Teil des Produkts betrifft die USB-Hostunterstützung: angeschlossene Tastaturen sollen dem Pythoncode fortan einen seriellen Datenstrom zur Aberntung der Eingaben zur Verfügung stellen. Für “andere” USB-Geräte plant man ebenfalls eine API, die dem Entwickler die Kommunikation ermöglicht.

Wieso erfolgte der CircuitPython-Fork, und wie geht es weiter?

Ursache für den Fork war ursprünglich das Einpflegen von Unterstützung für den SAMD; der Konflikt im Bereich der Hardware-Abstraktions-API finalisierte den Bruch. Ziel der Adafruit-Entwickler war dabei das Anbieten einer “universellen” Programmierschnittstelle, die auf allen Boardvarianten gleichermaßen funktionieren sollte. Problem Nummero zwei waren Bibliotheken: MicroPython und CPython sind nicht zu 100% kompatibel. Das MicroPython-Team bestand darauf, seine Bibliotheken eigenmächtig weiterzuentwickeln, während Frieds Team die “direkte Ableitung” von CPython im Interesse der Aufwandsreduktion wichtig war. Fried sprach spezifisch davon, dass jeder unter CircuitPython laufender Code auch in CPython laufen muss. Interessanterweise spendet Adafruit jedes Jahr Geld an MicroPython; im Gespräch erwähnten Adafruit-Entwickler die kooperative Gesprächsbasis mit dem ursprünglichen System.

Bildquelle: YouTube

Langfristig ist man einem “Re-Merge” nicht unbedingt abgeneigt – die philosophischen Unterschiede sind derzeit indes noch unüberwindbar (Stichwort auch Workflows, also wie der Code deployt wird).

MicroPython – Abkündigung des hauseigenen Bibliothekspräfixes

Als ob es abgestimmt wäre, findet sich unter https://github.com/orgs/micropython/discussions/12078 eine Anpassung der Namenstruktur von MicroPython. Ziel der Modifikation ist bessere Kommunalität mit CPython:

So in v1.21 (which will be released soon), all built-in modules have been renamed to match their CPython name -- os, sys, json, etc. The only exception is uctypes which is completely different to CPython's ctypes so it will keep its uctypes name. Additionally uasyncio and urequests have been renamed to asyncio and requests.
There is a lot of existing code out there that use the u-prefix, e.g. import uos or import urequests so this will continue to work (for both C and Python modules) [2]. But please prefer to use just the non-u-prefixed name from now on. [3]

ESP-Bluetooth und CircuitPython

Auf die Frage, inwiefern ESP32-Boards Bluetoothunterstützung bekommen sollen, wurde eher negativ beschieden: Espressif nutzt einen komplett anderen Stack, der mit den in den präferierten nRF-Boards nicht kompatibel ist.

STRG-C und Statuserhalt

CircuitPython “verliert” beim Senden eines Interrupts per STRG+C den “kompletten” Zustand, während MicroPython den Zustand erhält. Dies ist Absicht der Entwickler, und wird nicht verändert. Entwickler können – in der Theorie – aber Anpassungen am Code vornehmen, um eine hauseigene Version zu generieren.

Unterstützung für weitere Protokolle

Langfristig sind Erweiterungen im Bereich des MicroUSB-Supports geplant: insbesondere im Zusammenspiel mit USB und Desktopbetriebssystemen sind hier noch Probleme zu lösen. Zigbee-Unterstützung ist von Seiten Adafruits nicht geplant, das gilt auch für ESP-NOW und Co. Von der Community gestellte Erweiterungen nimmt man allerdings entgegen.

Ist Adafruit als “Marketingwerkzeug” vorgesehen, bzw sollen Nicht-Adafruit-Boards unterstützt werden?

Fried betonte, dass jedes Board, das eine einzigartige VID / PID aufweist, von CircuitPython unterstützt werden kann – wer auch immer will, kann für sein Board Unterstützung implementieren. In Zusammenarbeit mit GitHub bietet man umfangreiche CI-Tests an: bringt eine Änderung an CircuitPython Probleme für ein Board, so meldet das Repositorium automatisch.

Ersatz für BusPirate

Die BusPirate-Platine ermöglicht die einfache Ansteuerung von Peripheriegeräten vom Rechner aus – leider sind die verwendeten Chips derzeit nicht verfügbar. AdaFruit planen mit dem ProtocolDroid seit einiger Zeit einen “Nachbau”.

Bildquelle: AdaFruit, via YouTube

Bildquelle: https://blog.adafruit.com/2023/05/08/yaaarrr-a-circuit-pyrate-is-ready-to-be-your-best-mate-on-the-hacking-seas/

Im Rahmen des Vortrags sprach Fried von den Problemen, eine auch 5V-kompatible MCU zu finden. Die neue Version auf Basis des RP2040 ist in Arbeit – Fried sprach davon, “bald” eine neue Variante anbieten zu wollen.

[Vincent H. (vinci)]

Sind die I2C Probleme am S3 Soft- oder Hardware?

[Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)]

Hallo,
denke, es ist SW. Auf HW-Seite habe ich bisher nichts gehört, hatte mit 
dem S3 aber auch nicht zu tun bisher.

Meine Kunden nutzen entweder GD, oder die aelteren bzw den S2.