Rust und Benchmarks für RP2350, Python 3.13 und Lesestoff

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

Nach den großen Ankündigungen von ESP32-P4 und RP2350 stehen Neuerungen ante Portas. Google liefert sein PigWeed-SDK erstmals stabil aus, während die Rust-Entwicklerschaft über die „Probleme“ mit dem RP2350 berichtet. Der erste Release Candidate von Python 3.13 steht ante Portas, während Shenzhen Xunlong die Kühlung des OrangePi 5 verbessert.

Google PigWeed SDK – v1.0 startet mit RP2350

Das Pigweed-SDK wurde von Google per se schon im Jahre 2020 vorgestellt - die Auslieferung des Raspberry Pi Pico 2 nutzte man nun, wie unter https://opensource.googleblog.com/2024/08/introducing-pigweed-sdk.html vermeldet, als Stein des Anstoßes zur Auslieferung der Version 1.0 des Produkts. Im Prinzip handelt es sich dabei um eine „Sammlung von Middleware-Bibliotheken“, die Nutzern von 32 Bit-Mikrocontrollern eine mehr oder weniger standardisierte Entwicklungsoberfläche zur Verfügung stellen sollen. Unter der URL https://pigweed.dev/docs/showcases/sense/#showcase-sense bietet Google dabei einen „Walk Through“, der die diversen Aspekte des Produkts illustriert - so Interesse besteht, kann der Autor einen Folgeartikel mit einer detaillierten Analyse nachreichen.

Rust-Community – RP2350 wird mit Rust-Support ausgeliefert

Die Rust-Entwicklerschaft hat sich im Laufe der letzten Jahre mehr und mehr im Embedded-Bereich ausgebreitet. Der Rust-Entwickler JP vermeldet auf seiner Webseite nun nach folgendem Schema, dass der RP2350 wahrscheinlich der erste Mikrocontroller ist, der „direkt“ mit Rust-Unterstützung startet:

Today sees the announcement of the latest additions to Raspberry Pi's microcontroller line-up - the RP2350 family. I've had prototype units for a while, and you can run Rust code on it today. To my knowledge this is the first ever microcontroller launch with Rust support out-of-the-box.
--- via https://thejpster.org.uk/blog/blog-2024-08-08/

Der Artikel ist auch deshalb interessant, weil er eine umfangreiche Besprechung des „Start-Prozesses“ des Mikrocontrollers zur Verfügung stellt und dabei auch auf die Auswahl des zu aktivierenden Kern-Komplements eingeht. Für Rust-Nutzer interessant dürfte auch die in der Abbildung gezeigte Liste von Peripheriegeräten sein, die zum Zeitpunkt der Drucklegung noch nicht über die Rust-HAL ansprechbar ist.

Bildquelle: https://thejpster.org.uk/blog/blog-2024-08-08/

RP2350 - Analyse der durch die FPU verursachten Performancesteigerungen.

Dass der „neueste“ Raspberry Pi-Mikrocontroller dass FPU manche Aufgaben wesentlich schneller bewerkstelligen kann, dürfte bekannt sein (unter https://www.youtube.com/watch?v=pqecXDrHhpg findet sich ein Video mit einer Kurzfassung). Interessant ist ein von der Raspberry Pi Foundation durchgeführtes Experiment, das einen ML-basierten Rauschunterdrückungsalgorithmus zur Ausführung brachte. Die durch die FPU erreichte Performance-Steigerung ist dabei durchaus beeindruckend:

The denoising algorithm leveraged the Cortex-M33’s floating point unit (FPU) and ran 16.87x faster than the Cortex-M0+ on the original Pico board. 
--- via https://www.raspberrypi.com/news/real-time-ml-audio-noise-suppression-on-raspberry-pi-pico-2/

OrangePi 5 – jetzt mit Befestigungslöchern für Kühlkörper

Ein wirklich innovatives Feature des Raspberry Pi 5 war die Verfügbarkeit eines Kühlkörpers samt Ventilator, der sich „direkt“ auf der Platine befestigen ließ. Im Hause Shenzhen Xunlong zieht man nach - die neueste Variante des OrangePi 5 bringt ebenfalls zwei Befestigungslöcher mit, auf denen ein hauseigener Ventilator andockt.

Bildquelle: https://www.instagram.com/p/C-XLQmdRKyW/?igsh=MThoNGpuaXIxYTB2ag%3D%3D

Für „Kleinmengen-Abnehmer“ nachteilig ist, dass die Verteilung zwischen der alten und der neuen Variante zufällig erfolgt. Wer also beispielsweise bei AliExpress oder einem Distributor eine Bestellung tätigt, muss damit rechnen, neben der neuen auch noch alte Varianten ohne Befestigungslöcher zu erhalten.

Python 3.13 – Release Candidate erschienen

Im Hause Python gibt es ebenfalls Zuwachs - die Version 3.13 der Programmiersprache steht ab sofort als erster Release Candidate zur Verfügung. Die Abbildung zeigt, welche Änderungen von Seiten des Entwicklerteams als besonders relevant betrachtet werden.

Bildquelle: https://pythoninsider.blogspot.com/2024/08/python-3130-release-candidate-1-released.html

Geplant ist, dass die offiziellen Auslieferung der Version 3.13 im Oktober dieses Jahres erfolgt - wer sich im Python-Ökosystem aufhält und beispielsweise Bibliotheken anbietet, ist gut beraten, schon jetzt Kompatibilitätstests durchzuführen.

Ubuntu-Builds mit O3 – Performancevergleich zur Ermittlung des Performancevorteils

Über die Frage, ob man das Compiler-Flag O3 verwenden soll, lässt sich hervorragend diskutieren. Im Hause Canonical setzt man seit einiger Zeit probeweise auf Pakete, die mit O3 kompiliert werden. Der für seine Benchmarks bekannte Branchen-Newsdienst Phoronix nahm die Experimente zum Anlass, um einen groß angelegten Vergleich der verschiedenen Paketklassen durchzuführen. Die „allgemeinen“ in der Abbildung gezeigten Ergebnisse sind dabei allerdings zweideutig.

Bildquelle: https://www.phoronix.com/review/ubuntu-o3-experiment

Ursache dafür ist, dass der „Gutteil“ der Benchmarks nur minimale Steigerungen aufweist - im Fall mancher Applikationen wie beispielsweise einiger Server-Dienste sind die Leistungssteigerungen allerdings sowohl meß- als auch spürbar. Wer mehr Informationen zur Thematik möchte, ist deshalb gut beraten, die als Bildquelle angegebene URL zu besuchen und etwas Denkzeit mitzubringen.

Analog Devices AD8460 - AWG-Frontend auf einem Chip

Das Design eines Leistungsverstärkers für alle arbiträre Wellenformgeneratoren ist eine durchaus arbeitsintensive Aufgabe. Mit dem AD8460 schickt Analog Devices nun ein Produkt ins Rennen, das folgende Spezifikationen aufweist:

The AD8460 is a “bits in, power out” high voltage, high-power, high-
speed driver optimized for large output current (up to ±1 A) and high
slew rate (up to ±1800 V/μs) at high voltage (up to ±40 V) into
capacitive loads.

Wie in der folgenden Überblicks-Ansicht gezeigt gilt dabei, dass die „auszugebenden“ Informationen per SPI in das System wandern.

Bildquelle: https://www.analog.com/en/products/ad8460.html?

Für sehr einfache Wellenformen, die mit 16 Stützstellen auskommen, bietet der Chip auch einen direkten Modus - weitere Informationen zum Bauteil finden sich in der angegebenen URL. Zu beachten ist außerdem, dass das Produkt nicht unbedingt teuer ist - die Abbildung zeigt eine Preisanalyse.

Bildquelle: OEMSecrets.

Infineon PSOC™ Control – PSOC für Motorsteuerungen

Im Schatten der in der Einleitung genannten Ankündigungen ging unter, dass Infineon ebenfalls eine „Erweiterung“ der Produktpalette vornimmt. Spezifischerweise gibt es Zuwachs im Hause PSOC - mit dem Control steht eine Controller-Familie zur Verfügung, die - wie im folgenden beschrieben - vor allem für Motorsteuerungsanwendungen vorgesehen ist:

Key specifications of the new MCU family include clock speed of up to 180 MHz, high-performance analog-to-digital converters (ADCs), high-resolution (<100 ps) pulse-width-modulation (PWM) and an integrated CORDIC Accelerator to off-load real-time control tasks from the CPU. CORDIC’s true synchronous “idle” sampling of up to 16 analog signals from the single core ADC is up to 25 percent faster without sampling jitter. This powerful combination of power and performance yields system level bill-of-material (BOM) savings, while the <10 uA deep sleep and <1 uA hibernate modes deliver valuable energy savings for low-power and battery-driven applications.
--- via https://www.infineon.com/cms/en/about-infineon/press/market-news/2024/INFCSS202407-129.html

Zu beachten ist, dass die allgemeine Auslieferung dieser Kerne erst für das erste Quartal 2025 avisiert ist. Schon jetzt ist es allerdings möglich, sich - wie in der Abbildung gezeigt - als „Interessent“ anzumelden.

Bildquelle: https://www.infineon.com/cms/en/product/promopages/next-generation-industrial-mcu/?redirId=275061

Lesestoff, zur Ersten – Deniable Encryption für Wearables

Unter dem Schlagwort „Plausibly Deniable Encryption System“ finden sich allerlei Verschlüsselungssysteme, die den P. T. Benutzer vor „gewalttätiger Cryptoanalyse“ schützen sollen. Niusen Chen, Bo Chen und Weisong Shi haben mit “An application-layer plausibly deniable encryption system for wearable devices” nun eine Variante entwickelt, die für Smartwatches und ähnliche Minimalgeräte mit geringer Rechenleistung vorgesehen ist. Unter der URL https://link.springer.com/article/10.1007/s43926-024-00061-w? ist das Paper einsehbar.

Lesestoff, zur Zweiten - von der Hydrations-Effizienz verschiedenster Getränke.

Über die Frage Red Bull versus Club Mate streiten sich Ingenieure und Elektroniker seit vielen, vielen Jahren. Problematisch ist, dass es keine wirklich effizienten Benchmarks gibt, die die „Hydrations-Effizienz“ verschiedener Getränke auf eine vergleichbare Art und Weise abbilden. Das Paper Hydration Efficacy of a Milk Permeate-Based Oral Hydration Solution mag schon 2020 erschienen sein, ist aber nach wie vor lesenswert - mehr Informationen finden sich unter der URL https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7284605/ .

[Vanye R. (vanye_rijan)]

> Der Rust-Entwickler JP vermeldet auf seiner Webseite nun nach
> folgendem Schema, dass der RP2350 wahrscheinlich der erste
> Mikrocontroller ist, der „direkt“ mit Rust-Unterstützung startet

Irgendwie erinnert mich Rust ein wenig an Forth. Die Apologeten 
schreiben immer und auf jeden Fall fuer jede neue Hardware einen 
Compiler/Interpreter und sonst passiert nicht viel.

Vanye

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

Vanye R. schrieb:
>> Der Rust-Entwickler JP vermeldet auf seiner Webseite nun nach
>> folgendem Schema, dass der RP2350 wahrscheinlich der erste
>> Mikrocontroller ist, der „direkt“ mit Rust-Unterstützung startet
>
> Irgendwie erinnert mich Rust ein wenig an Forth. Die Apologeten
> schreiben immer und auf jeden Fall fuer jede neue Hardware einen
> Compiler/Interpreter und sonst passiert nicht viel.
>
> Vanye

Ohja. Es passiert noch was.

Manchmal findet man sie mit politsch ausdrucksstarkem Hintergrund auf 
ihren Stickern. Und wenn man sie bittet, ob man so einen Sticker 
fotographieren darf, ist man sofort ein Rassist.

Mir - als Syrer - auf einer EmbeddedWorld passiert.

[Vincent H. (vinci)]

Ja, ein 16.87x Speed-Up bei der Nutzung von Floating Point Berechnungen 
ist definitiv beeindruckend... und zwar beeindruckend wie schnell die 
Software Implementierung im M0+ vorher schon war.

[Norbert (der_norbert)]

Hinzu kommt der Wechsel von ›armv6-m thumb‹ zu ›armv8-m.main+dsp+fp‹ 
sowie die Takterhöhung 133MHz->150MHz.
Ohne es – mangels Hardware – getestet zu haben, allein dadurch und für 
Aufgaben ohne FP schätze ich mal 30% mehr Leistung. Sicherlich nicht die 
Welt, dafür aber gewissermaßen ohne Preiserhöhung…
Ich sehe den 'Neuen' durchaus positiv.

[Harald K. (kirnbichler)]

Für Anwendungen, bei denen ein Monitor angesteuert werden soll, ist das 
HSTX-Interface sehr interessant, und auch, daß dafür keine PIO-Einheiten 
mehr benötigt werden.

Und da es mehr RAM gibt, müsste man mit dem '235x auch Konverter basteln 
können, die z.B. ein Composite-Vidosignal digitalisieren, in einem Frame 
Buffer abbilden und den dann auf HDMI ausgeben. Damit lassen sich alte 
CNC-Maschinen, die immer noch an ausgeblichenen Röhrenmonitoren hängen, 
sinnvoll weiterbetreiben. Denn leider ist das, was die als Videosignal 
erzeugen, doch so anders als ein normgerechtes 576i-Signal, daß die 
üblichen billigen Composite-zu-HDMI-Konverter damit gar nichts anfangen 
können.

Die Retrobastler dürften sich freuen, weil man mit so etwas halt auch 
einen typischen 80er-Jahre-Homecomputer emulieren können müsste - 
inclusive Bildausgabe auf einen HDMI-Monitor.

Aber man kann damit sicher auch noch ganz andere Schweinigeleien 
veranstalten.

[Malte K. (maisflocke)]

Norbert schrieb:
> Hinzu kommt der Wechsel von ›armv6-m thumb‹ zu ›armv8-m.main+dsp+fp‹
> sowie die Takterhöhung 133MHz->150MHz.
> Ohne es – mangels Hardware – getestet zu haben, allein dadurch und für
> Aufgaben ohne FP schätze ich mal 30% mehr Leistung.

Wobei sich der RP2040 problemlos auf 400MHz übertakten lässt, der RP2350 
aber wohl "nur" auf 300MHz. Eventuell bleibt dann abseits von FP kaum 
noch Mehrleistung übrig, sofern Übertaktung im jeweiligen Anwendungsfall 
nicht ausgeschlossen ist.

Harald K. schrieb:
> Die Retrobastler dürften sich freuen, weil man mit so etwas halt auch
> einen typischen 80er-Jahre-Homecomputer emulieren können müsste -
> inclusive Bildausgabe auf einen HDMI-Monitor.

PicoDVI gab's ja auch schon für den RP2040, siehe z.B. das 
"Connomore64"-Projekt: https://github.com/c1570/Connomore64

Allerdings braucht der RP2040 zum TMDS-Encoding dann doch einige 
Prozessorzeit. Der RP2350 bringt einen Hardware-TMDS-Encoder mit, dürfte 
also für Filter o.ä. geeigneter sein.

Ganz cool ist auch, dass sich der RP2040 komplett auf dem PC emulieren 
lässt, siehe rp2040js.

[Harald K. (kirnbichler)]

Malte K. schrieb:
> PicoDVI gab's ja auch schon für den RP2040

Richtig, aber mehr RAM ist mehr RAM, und mehr PIO ist mehr PIO, 
insbesondere, wenn man die nicht für das Erzeugen des DVI-Signals 
verballern muss.

[Stefan K. (stk)]

Malte K. schrieb:
> Wobei sich der RP2040 problemlos auf 400MHz übertakten lässt, der RP2350
> aber wohl "nur" auf 300MHz.

Ganz problemlos sind 400 MHz auf dem RP2040 nicht, dafür muss das 
Programm aus dem RAM ausgeführt werden weil der SPI-Flashspeicher ab 
etwa 270 MHz nicht mehr mitspielt.
Zwei gerade angekommene Pico 2 mit aus dem Flash arbeitenden Micropython 
antworten bei 300 MHz noch. Bei Programmausführung aus dem RAM und etwas 
erhöhter Core-Spannung sollen auch beim RP2350 gut 400 MHz möglich sein:
https://forums.raspberrypi.com/viewtopic.php?t=375336

[Norbert (der_norbert)]

Stefan K. schrieb:
> Malte K. schrieb:
>> Wobei sich der RP2040 problemlos auf 400MHz übertakten lässt, der RP2350
>> aber wohl "nur" auf 300MHz.
>
> Ganz problemlos sind 400 MHz auf dem RP2040 nicht, dafür muss das
> Programm aus dem RAM ausgeführt werden weil der SPI-Flashspeicher ab
> etwa 270 MHz nicht mehr mitspielt.
> Zwei gerade angekommene Pico 2 mit aus dem Flash arbeitenden Micropython
> antworten bei 300 MHz noch. Bei Programmausführung aus dem RAM und etwas
> erhöhter Core-Spannung sollen auch beim RP2350 gut 400 MHz möglich sein:
> https://forums.raspberrypi.com/viewtopic.php?t=375336

Nun, das ist nicht ganz korrekt.
Ich habe mehrere, welche bis – Moment, muss nach schauen – ahhh, hier 
isses – 437MHz und eine andere Gruppe bis ~420MHz läuft. RAM UND FLASH.

Da muss man dann allerdings schon etwas für tun. Einfach nur Knöbbsche 
drücke reicht definitiv nicht.

[Mi N. (msx)]

Stefan K. schrieb:
> Ganz problemlos sind 400 MHz auf dem RP2040 nicht, dafür muss das
> Programm aus dem RAM ausgeführt werden weil der SPI-Flashspeicher ab
> etwa 270 MHz nicht mehr mitspielt.

Das wird man ja auch nur experimentel verwenden. Beim RP2040 stelle ich 
grundsätzlich die Wartezyklen etwas höher ein und die Core-Spannung auf 
Maximalwert.
Das Programm wird sowieso aus dem Cache ausgeführt und die leicht 
erhöhte Stromaufnahme ist mir egal. Bis 300 MHz ist noch genug Reserve 
nach oben vorhanden.

[Mi N. (msx)]

Mit etwas Trickserei bekommt man bei Ali ein Pico2-Board für verlockende 
ca. 1,50.
Allerdings ist jetzt auf eevblog über latch-up-Probleme aller GPIOs beim 
RP2350 zu lesen, was über den im Datenblatt beschriebenen Fehler E9 
hinausgeht und mich noch von einer derart kostspieligen Anschaffung 
abhält.
https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/msg5622547/#msg5622547
Mal sehen, wie das letztlich zu bewerten ist.