News CircuitPython und Linux aktualisiert, mbed-Plattform abgekündigt


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


Angehängte Dateien:

Lesenswert?

Die Embeddedwelt steht nie still: während Limor Frieds Truppen eine neue Version von CircuitPython ausliefern, finalisiert Linus Torvalds die Arbeiten an Linux 6.10. Arm plant derweil die Abkündigung von mbedOS, während ein klappenloser Pulsejet am Start steht – hier eine Liste von allem, was die Embedded-Welt auf Trab halten sollte.

Adafruit CircuitPython - Version 9.1.0 verfügbar.

Limor Friends Kohohrte plant zwar, langfristig den „Split“ zwischen MicroPython und der hauseigenen Variante zu beenden - da diese aber zu einem Ökosystem-Lockin führt, dürfte es sich dabei nach Ansicht des Autors um eine nicht wirklich ernst zu nehmende Intention handeln. Sei dem wie es sei, steht nun eine neue Version von CircuitPython zur Verfügung-die „wichtigsten“ Änderungen betreffen erstens die floppyio-Bibliothek und zweitens den Aufbau der diversen Konfigurationsdateien, wo das Einfassen der Konfiguration-Strings nun unbedingt erforderlich ist:

1
Incompatibility warnings
2
    API changes to floppyio.
3
    String values in settings.toml must be quoted.

Im Hintergrund führte man eine Aktualisierung der ESP_IDF-Variante durch. Dies ist insbesondere für auf den ESP32 zielende Python-Entwickler von hoher Relevanz, der Gutteil des in den folgenden Schritten vollständig abgedruckten Changelogs betrifft Verbesserungen für die ESP 32-Plattform:

1
Audio
2
    RP2040 I2SOut supports BLCK and LRCLK in either order.
3
    ESP32-S3 supports audiomp3.
4
    audiomp3 supports streaming from HTTP servers.
5
Bluetooth
6
    BLE GATT server support on Espressif.
7
    Pairing and bonding support on Espressif.
8
Built-in modules
9
    Enhance collections.deque functionality.
10
    Add keypad_demux.DemuxKeyMatrix: use multiplexer for one side of a keypad matrix.
11
    Add integration-based debouncing to keypad.
12
    supervisor.Runtime.serial_bytes_available now returns a count instead of a bool.
13
    Incompatible change: floppyio improvements, including API changes.
14
    Espressif: microcontroller.cpu.frequency is settable.
15
Graphics
16
    fourwire.FourWire: chip_select pin is now optional.
17
    picodvi now supports 640×240 and 800×240 resolutions.
18
    Enable _eve on Espressif boards with more than 4MB flash.
19
Internal
20
    Espressif: update to ESP-IDF v5.2.2.
21
    Espressif: Change task-switching quantum to 1 millisecond from 10 milliseconds.
22
Networking
23
    Implement ssl module for anything that provides socket.
24
    Add stream protocol support to SSLSocket.
25
Ports
26
    New port for renode hardware simulator.
27
Power
28
    Enable deep sleep on all supported Espressif chips.
29
Supervisor
30
    String values in settings.toml must be quoted.
31
USB
32
    max3421e USB host support.
33
    Allow user-specified names for usb_midi interfaces and jacks.

Wer eigene Experimente unternehmen möchte, kann dies mit der unter der URL https://blog.adafruit.com/2024/07/10/circuitpython-9-1-0-released/ stehenden Version tun. Zu beachten ist, dass Nutzer von NRF52-Boards in manchen Fällen eine Aktualisierung des am Board befindlichen Bootloaders durchführen müssen, weil ältere Varianten mit aktuellen Releases von CircuitPython nicht mehr zusammenarbeiten können.

ARM mBED OS - offizielles Ende naht

Dass man im Hause arm seit einiger Zeit an einem „Ökosystem Play“ arbeitet, um der Bedrohung durch RISC/V entgegenzutreten, dürfte für Leser von Mikrocontroller.net keine wirkliche Neuigkeit mehr darstellen. Ein wenig verwirrend ist in diesem Zusammenhang die Entscheidung ARMs, das insbesondere von Arduino „stark“ genutzte hauseigene Echtzeitbetriebssystem Embedded OS ohne jeglichen Nachfolger über den Jordan zu schicken.

Spezifischerweise findet sich unter unter URL https://os.mbed.com/blog/entry/Important-Update-on-Mbed/ bereitstehenden Ankündigung folgender Timeframe, der über die im Rahmen der Abkündigung zu erwartenden Ereignisse informiert:

1
    The Mbed platform and OS will reach end of life in July 2026, when the Mbed website will be archived and it will no longer be possible to build projects in our online tools
2
    The device software - Mbed OS - is open source and will remain publicly available, but is no longer actively maintained by Arm
3
    The Mbed TLS project is unaffected by this announcement and continues to be supported as part of the TrustedFirmware community project.

Interessant ist außerdem die ebenda angebotene Grafik, die der P. T. Entwicklerschaft “Alternativen“ offeriert. Im Interesse der Archivierung ist hier ein Screenshot affichiert.

Bildquelle: ARM

Während Nutzer der arm-Onlinedienste umsteigen müssen, könnten anbietet an Nutzer des Echtzeitbetriebssystems theoretisch“ weiter arbeiten“-der Quellcode von mbed OS ist Open Source, weshalb man theoretisch einen Fork durchführen könnte. Zu beachten ist allerdings, dass die „Pflege“ eines Echtzeit-Betriebssystems eine Aufgabe ist, die selbst größere Unternehmen nicht nebenbei bewältigen können.

Wave Engine J-1 – Ventilfreier Pulsejet wird ausgeliefert.

Spätestens seit der Fieseler Fi-103 gelten PALs-Jets als „preiswerte“ Alternative zu teuren und aufwändigen Turbinen. Problematisch waren ihnen bisher vor allem die Nutzung verschiedener Klappen, die sich als klassische Verschleißteile erwiesen und die Lebensdauer der Turbinen stark reduzierten. Seit einigen Jahren experimentieren diverse Forscher aus diesem Grund mit Valveless Pulsejets, die statt den klassischen Ventilen auf eine spezielle Geometrie der Schubführung setzen. Ein Beispiel dafür ist die von Wave Engine angebotene J-1, die in der Abbildung gezeigt ist.

Bildquelle: Wave Engine, via https://wave-engine.com/wp-content/uploads/2024/05/J_1_v3.pdf

Die Spezifikationen der nun ausgelieferten Turbine fasst das Unternehmen wie in der Abbildung zusammen.

Bildquelle: Wave Engine.

Wie im Fall vieler anderer US-Defense-Produkte gilt auch hier, dass die Preise „auf Anfrage“ zu erfragen sind. Günstig dürfte das Teil indes nicht ausfallen.

ARRL bestätigt Ransomware-Vorfall.

Das als „Steering Gremium“ für den amerikanischen Amateurfunk dienende ARRL erlitt vor einigen Wochen einen Ransomware-Angriff, in dem die Angreifer verschiedenste Informationen exfiltrieren konnten. Das auf Computersicherheit spezialisierte Forum Bleeping Computer berichtet unter https://www.bleepingcomputer.com/news/security/arrl-finally-confirms-ransomware-gang-stole-data-in-cyberattack/ nun nach folgendem Schema über den Vorfall:

1
The American Radio Relay League (ARRL) finally confirmed that some of its employees' data was stolen in a May ransomware attack initially described as a "serious incident."
2
3
ARRL, the National Association for Amateur Radio, said in data breach notifications recently sent to impacted individuals that it detected the "sophisticated ransomware incident" after the attackers breached and encrypted its computer systems on May 14.

Interessant ist, dass sich die „exfiltrierten Informationen“ laut dieser Ankündigung auf persönliche Daten von Angestellten der ARRL beschränken – in Praxis könnte allerdings damit zu rechnen sein, dass weitere Informationen entwendet wurden. Vorsicht vor „gezielten Phishing-Attacken“ dürfte im Amateurfunkbereich in den nächsten Wochen und Monaten die Mutter der berühmten-berüchtigten Porzellankiste darstellen.

Linux 6.10 verfügbar.

Maintainer von Embedded-Distributionen dürfen sich über eine neue Version des quelloffenen Betriebssystems freuen. Dabei handelt es sich - wie in der Abbildung gezeigt - vor allem um ein Maintenance Release.

Bildquelle: https://lkml.org/lkml/2024/7/14/250

Der auf Embedded-Systeme spezialisierte Branchennewsdienst CNX bietet unter der URL https://www.cnx-software.com/2024/07/15/linux-6-10-release-notable-changes-arm-risc-v-and-mips-architectures/ eine Liste aller Changes an, die ARM-und RISC-V-SOCs betreffen. Besonders interessant dürften die beiden folgenden Änderungen sein, die sich auf den Raspberry Pi beziehen:

1
Until now after a bcm2835 pin was freed its pinmux was set to GPIO_IN. So in case it was configured as GPIO_OUT before the configured output level also get lost. As long as GPIO sysfs was used this wasnt actually a problem because the pins and their possible output level were kept by sysfs.Since more and more Raspberry Pi users start using libgpiod they are confused about this behavior. So make the pin freeing behavior of GPIO_OUT configurable via module parameter.
2
3
. . .
4
5
6
    Added a pinctrl-based multiplexing description to allow the use of I2C0 pins to allow usage between the 40-pin Raspberry Pi header and the CSI and DSI connectors. Described the PCF85063 RTC device available on the CM4 I/O board making use of that pinctrl-based muxing.

Raspberry Pi AI Kit - Demonstration besonders interessanter Projekte

Dass die Produkte aus dem Hause der Raspberry Pi Foundation unter anderem aufgrund der breiten community und guten Dokumentation Aufmerksamkeit verdienen, dürfte Leser von mikrocontroller.net nicht wirklich überraschen. Mit dem Raspberry PI AI KIT - es handelt sich dabei nicht um die unter https://www.youtube.com/watch?v=tY--kw0tVd0 gezeigte Kamera - steht eine AI-Beschleunigerkarte zur Verfügung, die Prozessrechnern aus dem Hause Ebenezer Upton Rechenleistung zur Verfügung stellt. Unter der URL https://www.raspberrypi.com/news/what-youve-been-making-with-the-raspberry-pi-ai-kit/ findet sich nun eine „Tour der Force“ von Projekten, die die Uptoniten als besonders interessant empfinden.

Quelloffenes Design für Bubble Memory Reseed Board veröffentlicht.

Insbesondere ältere Messgeräte aus dem Hause HP verwenden oft Bubble Memory als Speicher - die einst von Intel entwickelte Magnetblasensspeichertechnik ist mittlerweile leider fast komplett in Vergessenheit geraten. Sei dem wie es sei, benötigt man im Rahmen der Wartung dieser älteren Geräte mitunter ein als sie Reseed Board bezeichnetes Spezialgerät, das heute so gut wie unerhältlich ist.

Bildquelle: https://hackaday.io/project/172227-bubble-memory-reseed-and-dummy-boards.

In der als Bildquelle angeführten URL finden sich nun Gerber- und sonstige Files für eine „quelloffene Nachbauvariante“, die einigen Benutzern der HP-Messtechnik-Eigentümergilde beste Dienste leistet. Wie immer gilt natürlich, dass der Newsautor jegliche Haftung ablehnt.

C++-Optimierungsmethoden analysiert.

Ein alter Kalauer warnt den P. T. Programmierer vor „ungezielter“ Optimierung. Das unter der URL https://github.com/0burak/imperial_hft bereitstehende GitHub-Repositorium mag zwar aus dem HFT-Handelsbereich kommen, listet aber-wie in der Abbildung gezeigt-verschiedenste Design Patterns zur Steigerung der Leistung von C++-Code auf.

Bildquelle: https://hackaday.com/2024/07/13/c-design-patterns-for-low-latency-applications/

In eigener Sache

Dank an dl8dtl für einen Hinweis!


: Bearbeitet durch NewsPoster
von Stefan (sstaub)


Lesenswert?

Zu Mbed, lieber ein Ende mit Schrecken als ein Schrecken ohne Ende. 
Alles was nach v2 kam war ein einziges Grausen, frei nach dem Motto 
"Wieso es einfach machen wenn es auch kompliziert geht". Das Gute an 
Mbed war der objektorientierte Ansatz, der leider Arduino immer noch 
fehlt (Wiring wollte das mal ändern). Arduino will aber sowieso auf 
Zephyr umsteigen. Dazu gibt es mit mbed-ce bereits einen Fork, siehe 
https://github.com/mbed-ce/mbed-os

von J. S. (jojos)


Lesenswert?

Arduino versinkt da so schon im Chaos der verschiedenen cores, 
jedenfalls was die Portabilität angeht. Mit den Mbed Cores für Arduino 
wurde auch ein eigener Fork aufgemacht und unkonventionell über Patches 
gehandhabt, anders als es jetzt Mbed-CE macht. Wie Arduino das jetzt 
noch auf Zephyr umstellen will bleibt spannend, das ist ja ein komplett 
anderes System und noch komplexer als andere. Die Arduino Leute fangen 
vieles an auf der Suche nach Dingen die trotz OpenSource noch irgendwie 
Geld bringen: Pro Hardware, FPGA, Cloud, Modulino... Aber nichts halbes 
und nichts ganzes, richtiger Support kostet Geld und der wird dann auf 
die Community abgeschoben.
ARM hat leider wenig dafür getan Mbed zu pushen, der Code ist schon 
komplex und vor allem die vielen inkompatiblen Änderungen sind ein 
Problem. Dadurch ist nicht nur das OS API betroffen, sondern natürlich 
auch alle Komponenten die ständig angepasst werden müssen.
Die Umstellung des Buildsystems in Mbed auf Cmake war ein guter Gedanke, 
aber leider von ARM schlecht umgesetzt. Mbed-CE macht das besser, aber 
Cmake ist auch eine harte Nummer und die Komponentenvielfalt wie bei 
Arduino fehlt. Eine einfache IDE zum mal eben installieren gibt es auch 
nicht, so ist das eben ein System geblieben für Leute die sich intensiv 
damit beschäftigen.
Immerhin kommt die Abkündigung 2 Jahre vor Schluss, wobei schon Anfang 
2022 wohl das Team aufgelöst wurde. Der Online Compiler lief lange und 
war nett zum starten und für die Ausbildungszwecke, praktischer ist aber 
schon eine lokale Installation und damit lebt es ja 4ever.

: Bearbeitet durch User
von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Das ständige umbasteln des mbed-Buildsystem war mehr als lästig. Da 
merkte man dass dem Team ein Erwachsener fehlte, der den Daumen drauf 
hält.

Wenn man Mitte 2021 (da gab es die ersten Umorganisationen) als den 
Zeitpunkt annimmt ab dem mbed an den Tropf gehangen wurde, dann hat es 
mbed gerade mal auf 8,5 Jahre mehr oder weniger aktive Entwicklung nach 
der ersten Veröffentlichung gebracht. Dafür aber auf vier Buildsysteme.

mbed war sicher auch kein wichtiges Projekt aus Sicht des 
Arm-Managements. Eher ein Showcase und ein paar Entwickler die man sich 
hielt um ein Me-To Projekt vorweisen zu können.

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

Mit Mbed 5 wurde etwa 2018 mit viel Schwung das OS vorangetrieben. Ziel 
war da eher IoT, dazu gab es ja auch eine Cloudlösung die aber scheinbar 
keiner wirklich haben wollte. Da wurde das System zu sehr aufgebläht, 
aber dann mit der Bare Metal Konfiguration um den RTOS Teil abgespeckt 
werden konnte, das ist schon genial.
Das Buildsystem in Python war nur komplex geworden und zu langsam, das 
lief auch im Backend vom Onlinecompiler und war da zu 
Ressourcenfressend, ansonsten war das schon sehr flexibel. Bei Cmake hat 
man nicht auf Jamie gehört, er hat das in Mbed-CE besser gelöst als ARM 
im (unvollendeten) CLI2.
Ein Problem ist sicher auch der ESP der leistungsfähig, günstig und sehr 
beliebt ist, und vor allem in der sauren Gurkenzeit von Corona lieferbar 
war. ESP ist kein Cortex-M und damit nicht im Fokus von ARM, kann aber 
mit Arduino bespaßt werden (auch wenn Espressif das nicht so mag) und 
das hat ARM auch verpennt.

von J. S. (jojos)


Lesenswert?

Hannes J. schrieb:
> mbed war sicher auch kein wichtiges Projekt aus Sicht des
> Arm-Managements. Eher ein Showcase und ein paar Entwickler die man sich
> hielt um ein Me-To Projekt vorweisen zu können.

Das war einfach der Zeit voraus, die Entwickler hatten ein System zur 
Ausbildung vor Augen das im Webbrowser läuft und so auf Schulrechnern, 
ohne das eine Software installiert werden musste. Und das hat auch 
funktioniert. Es brauchte allerdings einen relativ teuren µC, das 
Ur-mbed Board mit LPC1768 und das hatte über 70 € gekostet. Da haben 
sich die Leute hier noch in die Köppe gekriegt wenn es um das Thema 32 
Bitter als µC ging, braucht keiner hieß es in der Mehrheit. Naja, heute 
zeigt ein ESP was mit 32 Bit geht, und klugerweise gleich ein Funkmodul 
mit drin.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.