- Der RP2040 hatte seine Stärken bei PIO, DMA und Overclocking, doch wegen Core-Leistung, RAM, GPIO, PIO-Ressourcen und fehlendem QSPI-PSRAM musste man bei manchen Projekten auf den STM32H7 ausweichen; der RP2350 schließt diese Lücken weitgehend
- Der RP2350 bietet Dual Cortex-M33F, Floating-Point-Unterstützung, Custom Instructions zur Beschleunigung von Double-Precision-Mathematik, doppelt so viel RAM und optionale RISC-V-Cores; in mehreren Projekten lief er stabil mit 300 MHz
- PIO kann FIFOs wie Speicher für beliebiges Lesen und Schreiben nutzen; dank 3 PIOs, Interrupts zwischen PIOs und verbessertem DMA wurden sogar Implementierungen eines Sony-Memory-Stick-Slaves und eines SDIO-Slaves möglich
- QSPI-PSRAM funktioniert für Lesen, Schreiben und Cache; Speichertests, die auf dem STM32H7 hängen blieben oder crashten, liefen auf dem RP2350 weiter, und auch das Anbinden von 16 MB RAM an eine manuell gefertigte 2-Layer-Platine wurde einfacher
- Das erste öffentliche RP2350-Projekt, das DEFCON 32 Badge, zeigte einen Game-Boy-Emulator und PalmOS; RP2354A/RP2354B bieten 2 MB In-Package-Flash, dasselbe Pinout und eine 80-Pin-Variante mit mehr GPIO
Was beim RP2040 fehlte und welche Verbesserungen gewünscht waren
- Der RP2040 war ein Mikrocontroller, der in vielen Projekten eingesetzt wurde; seine Stärken lagen besonders bei PIO, gut gestaltetem DMA und hohem Overclocking-Potenzial
- Die Kombination aus PIO und DMA wurde für folgende Implementierungen genutzt
- fortgeschrittene Display-Treiber
- Boards, die sich wie ein vollständiger Systembus mit RAM und ROM verhalten
- Konfigurationen, die an einen MC68328-Prozessor angebunden sind
- Die Schwächen des RP2040 konzentrierten sich auf Peripherie-Ressourcen und Speichererweiterbarkeit
- ein Forever-Transfer-Modus, der keinen weiteren DMA-Kanal verschwendet
- mehr DMA-Kanäle
- mehr Register zum Speichern temporärer Variablen in PIO-State-Machines
- mehr PIO-Einheiten
- mehr als 32 Instruction-Slots pro PIO
- mehr GPIO
- Der hohe Takt half vor allem dabei, die Schwächen der Cortex-M0+-Cores zu kaschieren; ein besserer Core wie ein Cortex-M4F wäre für Floating-Point- oder leichte SIMD-Workloads vorteilhaft gewesen
- Unterstützung für QSPI-PSRAM und mehr RAM waren ebenfalls wichtige Wünsche
Erfahrungen mit STM32H7-QSPI-RAM und Vergleich
- In einigen Anwendungsfällen musste statt des RP2040 ein STM32H7 eingesetzt werden, doch die Bugs des STM32H7 und der Umgang von STMicro mit Errata hinterließen starkes Misstrauen
- Bei der QSPI-RAM-Unterstützung des STM32H7 traten folgende Probleme auf
- ohne Cache gingen Writes verloren
- mit aktiviertem Cache wurden um manche 1-Byte-Writes herum beliebige Garbage-Daten geschrieben
- beim Ausführen von Code aus PSRAM blieb nach Milliarden von Zugriffen der gesamte Chip stehen, und selbst der Debugger konnte sich nicht mehr verbinden
- Die Probleme wurden gemeldet und eine Demo bereitgestellt, doch die Reaktion von STMicro war nicht ausreichend
- Es wurden Workarounds gefunden, sie kosteten jedoch 7–10 % Performance und verringerten damit den Nutzen des Chips
Verbesserungen, die der RP2350 erfüllt
- Im vergangenen Jahr wurden mit Unterstützung von Raspberry Pi RP2350-Samples genutzt, Bugs gemeldet und Vorschläge gemacht; dabei zeigte sich, wie sich RP2040-Anwendungsfälle verbessern lassen
- Core- und Rechenleistung wurden deutlich verbessert
- zwei Cortex-M33F-Cores
- Floating-Point-Unterstützung
- Custom Instructions, die über die übliche Single-Precision des Cortex-M33F hinaus Double-Precision-Mathematik beschleunigen
- Double-Precision-Operationen sind nicht single-cycle, liegen aber bei etwa 2–3 Zyklen pro Operation
- RISC-V-Cores sind ebenfalls nutzbar, in realen Projekten wurden jedoch Cortex-M33 verwendet
- In mehreren Projekten lief der RP2350 problemlos mit 300 MHz
- Die RAM-Größe wurde gegenüber dem RP2040 verdoppelt
Änderungen bei PIO und DMA
- Das PIO des RP2350 kann FIFOs wie Speicher verwenden und ermöglicht beliebiges Lesen und Schreiben; PIO-Konfigurationen, die zuvor wegen zu weniger temporärer Variablen schwierig waren, werden dadurch einfacher
- Die Zahl der PIOs im Chip wurde auf 3 erhöht
- Interrupt-Übertragung zwischen PIOs ist möglich, wodurch Cross-PIO-Synchronisation und komplexere Konfigurationen erstellt werden können
- Die Kombination aus verbessertem PIO und DMA wurde in realen Projekten für folgende Implementierungen genutzt
- Sony-Memory-Stick-Protocol-Slave: Geräte erkennen ihn als echten Memory Stick
- SDIO-Slave-Device: getestete Geräte erkennen ihn als SDIO-Gerät
- Auch DMA wurde bei Transfer-Kontinuität und Adresssteuerung erweitert
- unendliche Transfers sind möglich, ohne einen weiteren Kanal zu verwenden
- es gibt mehr Möglichkeiten, die Speicheradresse bei jedem Zugriff anzupassen
- zusätzlich zu „gleiche Adresse“ oder „um Zugriffsgröße erhöhen“ beim RP2040 wurden Dekrementieren und Optionen zum Erhöhen um andere Größen ergänzt
QSPI-PSRAM-Unterstützung
- Der RP2350 unterstützt QSPI-PSRAM, und Lesen wie Schreiben funktionieren
- Cache wird ebenfalls bereitgestellt und funktioniert korrekt
- Speichertests, die auf dem STM32H7 hängen blieben oder crashten, liefen auf dem RP2350 weiter; es gab weder Datenverlust noch ein Chip-Hang
- Mögliche Kombinationen sind
- 1 Flash + 1 PSRAM
- 2 Flashs
- 1 Boot-Flash + 2 Laufzeit-PSRAMs
- Auch eine Konfiguration, bei der VTOR, SP und PC alle im PSRAM liegen, viele LDM/STM-Instruktionen auf PSRAM-Ziele ausgeführt werden und Interrupts eintreffen, funktioniert problemlos
- Die Konfiguration benötigt nur 3 Zeilen C-Code, und auch das Hinzufügen von 16 MB RAM zu einer manuell bestückten 2-Layer-Platine wird einfacher
- Das frühe RP2350-Sample-Board Pi Pico 2 hatte keinen PSRAM-Footprint, daher wurde PSRAM per Dead-Bug-Methode angebracht; selbst so lief es mit voller Geschwindigkeit
Beibehaltene Stärken und Entwicklungserfahrung
- Beim Wechsel vom RP2040 zum RP2350 blieb die Qualität von Peripherie-Design und Dokumentation erhalten
- Die Peripherie verhält sich wie versprochen
- Das SDK ist klar und schlank, ohne dass große Cube/HAL-artige Tools heruntergeladen werden müssen
- Der Code ist keine Macro Hell und funktioniert gut
- Das RP2350-Entwicklungsboard von Raspberry Pi ist rPiPico-kompatibel, und mehrere Projekte ließen sich problemlos auf den PiPico 2 bringen
Erstes öffentliches RP2350-Projekt: DEFCON 32 Badge
- Eines der öffentlichen RP2350-Projekte ist das DEFCON 32 Badge
- Die Hardware wurde von Entropic Engineering entwickelt, die Firmware ist ein Port des kleinen Game-Boy-Emulators uGB
- Die beiden Cores werden mit getrennten Rollen genutzt
- ein Core verwendet die SIMD-Instruktionen des Cortex-M33, um den Game-Boy-Bildschirm um den Faktor 1,5 hochzuskalieren
- der andere Core übernimmt Emulation, UI und die übrigen Aufgaben
- Gültige Game-Boy-Spiele laufen bis zu 2 MB; mit einem größeren Flash-Chip sind auch größere Spiele möglich
- Das vorinstallierte Game-Boy-Spiel wurde von DEFCON geschrieben
- Auf diesem Badge wird der Chip konservativ mit 125 MHz getaktet
- es gab nicht viel Testzeit, die Produktion stieg ohne Zwischenschritt von 10 auf 28.000 Stück, und es gab keinen Plan B
- der maximale Display-Takt lag bei 62,5 MHz, und da eine PIO-State-Machine ihn liefert, musste der Display-Takt ein ganzzahliger Teiler des Systemtakts sein
PalmOS-Ausführung und Firmware
- Dieselbe DEFCON-32-Badge-Hardware kann über das rePalm project auch eine full version von PalmOS ausführen
- Auf dem Standard-Badge ist kein PSRAM bestückt, PalmOS läuft aber trotzdem
- der Speicher ist knapp, aber infrared beaming, SD card, einfache Spiele, memo pad, audio usw. funktionieren
- Wenn ein AP-Memory-64-Mbit-PSRAM-Chip bestückt wird, kann ein zweites Image verwendet werden; mit mehr Speicher sind das Laden von Spielen oder MP4-Echtzeitwiedergabe über TCPMP möglich
- Firmware-Images befinden sich in der Dokumentation; man legt sie unter dem Namen
FIRMWARE.BINauf eine SD-Karte und wählt im Menü derFN-Tastefirmware update, um sie zu laden - Die Wiederherstellung der Stock Firmware ist über USB und das UF2 protocol von jedem Computer aus möglich; das Stock Image ist ebenfalls in derselben Dokumentation erhältlich
RP2354 und mehr GPIO
- Die Schlussfolgerung war, dass STM32H7-Projekte wieder mit dem RP2350 geplant werden können
- Auf den Hinweis, dass der RP2350 externes SPI-Flash benötigt, gibt es die Built-in-Flash-Varianten RP2354A und RP2354B
- RP2354A/RP2354B enthalten 2 MB Flash im Package
- Das Pinout ist identisch mit RP2350A/B
- Es gibt auch eine Variante im 80-Pin-Package mit mehr GPIO
Hinweis zu Interessenkonflikten
- Für diesen Text gab es keine finanzielle Vergütung oder Gegenleistung
- Es gab keine Aufforderung, ihn zu schreiben, und keine Freigabe
- Der Early Access zum RP2350 war nicht daran geknüpft, öffentlich positiv darüber zu sprechen oder bestimmte Aussagen zu machen
1 Kommentare
Hacker-News-Kommentare
Ich habe in den letzten Jahren einen bürstenlosen Motortreiber auf RP2040-Basis entwickelt, und diese Ankündigung macht mich wirklich gespannt.
Das Treibermodul kann bis zu 53 V, 30 A Dauerstrom und 50 A Spitze verarbeiten. Vor Kurzem habe ich den Treiber als separates Modul ausgegliedert; das ist für Farmroboter nützlich und auch wichtig, um Treiber während der Designverbesserungen zu testen. Diese Revision wirkt ziemlich stabil, sodass ich vielleicht bald einen günstigen, integrierten Ein-Motor-Treiber auf einer einzelnen Platine mit dem RP2350 bauen kann. Beim RP2040 lag die Loop-Geschwindigkeit bei 8 kHz, was für Antriebsmotoren großer Farmroboter ausreicht; einige Hochleistungstreiber mit Floating Point erreichen aber auch Loop-Geschwindigkeiten von 50 kHz.
Das Board läuft mit SimpleFOC, und im Forum gab es Gespräche darüber, ein Flaggschiff-Design zu bauen. Da jedoch sensorlose Regelung und Floating-Point-Unterstützung nötig sind, könnte man mit der neuen größeren Pinout-Variante des RP2350 mit 8 ADC-Pins drei Stromsignale und drei Brückenspannungen messen und damit einen brauchbaren sensorlosen Treiber bauen. Bis das Design fertig ist, wird es ein paar Monate dauern; die neuesten Updates gibt es aber im Git-Repository oder im Twitter-Profil.
https://github.com/tlalexander/rp2040-motor-controller
https://twitter.com/TLAlexander
Mir gefällt wirklich sehr, dass für Füße und Räder Fahrradteile verwendet werden.
Es gibt bereits spezialisierte MCUs mit dedizierten Peripherieblöcken, Application Notes und Codebeispielen für sensorbasierte/sensorlose BLDC-Steuerung; ich finde nicht, dass der RP2040 für diese Aufgabe besonders passend ausgestattet ist.
Das erinnert mich an die Zeit, als ich als Kind Spielzeugautos zerlegt und die Motoren herausgenommen habe und dabei das Gefühl hatte, etwas geschafft zu haben.
Ich konnte mir schwer vorstellen, den RP2040 in einem echten Produkt einzusetzen, aber der RP2350 behebt viele meiner Kritikpunkte und macht mich so neugierig, dass ich ihn ausprobieren möchte.
Auch der RP2040 hatte viele Stärken. TBMAN ist ein cooles Konzept, und er lässt sich enorm gut übertakten. PIO ist wirklich innovativ und für viele Unternehmen wertvoll, die 8051-artige Bausteine durch Arm-Cores auf Daughterboards ersetzen wollen.
Aber zu jedem coolen Punkt gab es auch einen Haken. Er hat eine DSP-artige Taktrate, aber weder FPU noch Hardware-Integer-Division. Dass ein USB-DFU-Feature im Boot-ROM eines MCU ohne Speicherschutz steckt, ist ebenfalls nicht wünschenswert. In Third-Party-SDKs wie Zephyr ist die PIO-Unterstützung extrem eingeschränkt, wodurch der Nutzen in großen Projekten sinkt.
Der RP2350 beseitigt fast all diese Kritikpunkte, daher bin ich sehr gespannt. Wenn man jedoch gängige Peripherie wie CAN oder SDMMC per PIO implementieren muss, ist man sofort im Nachteil. Die Flexibilität ist großartig, aber wenn man ein Produkt schnell zum Laufen bringen muss, möchte man nicht an einer zweckgebundenen Assemblersprache herumfummeln. Wenn es letztlich fertige Soft-Peripherie-Bibliotheken für übliche Funktionen wie SD/MMC, MII oder Bluetooth HCI gäbe, würde das die Integration mit Zephyr und Ähnlichem erleichtern und den Einsatzbereich des Chips deutlich erweitern.
Sie könnten noch ausgereifter sein, kommen aber schon ziemlich nah an „fertig nutzbar“ heran.
PIO ist ein großer Vorteil, und ich freue mich, dass die neue Version diese Richtung weiter stärkt. Leute entwickeln bereits PIO-Treiber für verschiedene Peripheriegeräte wie CAN und WS2812; das kommt dem, was ich mir erhofft hatte, ziemlich nahe.
Autonomer Peripheriebetrieb, Operationsverstärker, Komparatoren und Capture/Compare-Timer sind ähnlich. Zephyr versucht, wie ein Desktop-Betriebssystem gemeinsame Interfaces bereitzustellen, aber im Embedded-Bereich passt das nicht gut. Auf dem Desktop reicht der kleinste gemeinsame Nenner oft aus; im Embedded-Bereich wählt man eine Plattform aber häufig gerade wegen dieser nicht gemeinsamen Funktionen.
Zu den Gründen für die Wahl des RP2040 gehörte auch die Designphilosophie, aber nach der Chipknappheit war auch die leichte Beschaffbarkeit ein wichtiger Faktor.
Tatsächlich gibt es „Beispiele“, und es wäre noch besser, wenn solche Dinge als erstklassig unterstützte Komponenten angeboten würden.
Die Spezifikationen sind hier zu finden: https://www.digikey.ca/en/product-highlight/r/raspberry-pi/r...
Basierend auf dem von Raspberry Pi in Großbritannien entwickelten RP2350, Dual Arm M33 mit FPU bei 150 MHz, 520 KiB SRAM, Sicherheitsfunktionen wie signiertes Booten, OTP, SHA-256, TRNG, Glitch-Detektor und Arm TrustZone for Cortex-M, optionaler Dual RISC-V Hazard3-CPU mit 150 MHz, Low-Power-Betrieb, drei PIO v2 mit 12 State Machines zur Unterstützung eigener Peripherie, PSRAM-Unterstützung, schnelleres externes XIP-QSPI-Flash-Interface, 4 MB Onboard-QSPI-Flash, 5-V-tolerante GPIO, Unterstützung für Open-Source-C/C++-SDK und MicroPython, Softwarekompatibilität mit Pico 1/RP2040, Drag-and-drop-Programmierung per USB-Massenspeichergerät, castellated Modul zum direkten Auflöten auf Carrier Boards, gleicher Footprint und Pin-kompatibel zu Pico 1, 26 multifunktionale GPIO inklusive 3 analoger Eingänge, Betriebstemperatur -20 °C bis +85 °C, Eingangsspannung 1,8 VDC bis 5,5 VDC
Später sah ich, dass in Abschnitt 14.8.2.1 zwei Arten digitaler Pins auftauchen, „Standard Digital“ und „Fault Tolerant Digital“, und es sieht so aus, als seien die FT-Digital-Pins 5-V-tolerant
Ein großer Tag für das Pigweed-Team
Einige Arbeiten wurden auch in der eigentlichen Ankündigung des RP2350/Pico 2 erwähnt [1], aber wir haben in den letzten Monaten an einem neuen End-to-End-SDK [2] auf Basis von Bazel [3] gearbeitet, das sowohl RP2040 als auch RP2350 unterstützt. Dazu gehört auch die Arbeit, Bazel-Unterstützung in das Pico SDK upstream einzubringen. Die neue „Tour of Pigweed“ [4] zeigt, wie mehrere Pigweed-Funktionen wie hermetische Builds, Unit-Tests auf dem Gerät, RPC-zentrierte Kommunikation und Factory-Tests auf dem Schreibtisch in einer einzigen Codebasis zusammenspielen. Fragen nehmen wir auf Discord [5] entgegen
[1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...
[2] https://opensource.googleblog.com/2024/08/introducing-pigwee...
[3] https://blog.bazel.build/2024/08/08/bazel-for-embedded.html
[4] https://pigweed.dev/docs/showcases/sense/
[5] https://discord.gg/M9NSeTA
Es macht einen großen Unterschied, wenn man sieht, dass alles hermetisch integriert ist und der Workflow auf einen einzigen Bazel-Befehl reduziert wird
Überraschend, dass die Pigweed-Ankündigung dazu gar nichts enthält
Ich wünschte, man würde Java aus dem Mikrocontroller-Ökosystem heraushalten
Dass man auf demselben Die zwischen Arm-Kernen und RISC-V-Kernen wählen kann, ist ein Design, das ich zum ersten Mal sehe
Ich frage mich, ob das Auswirkungen auf Preis und Stromverbrauch hat. Die Hazard3-Kerne sind optional; beim Booten kann man auswählen, ob das enthaltene Paar Arm-Cortex-M33-Kerne oder das Paar Hazard3-Kerne mit 150 MHz laufen soll. Noch gewagter: Man kann auch einen RV und einen Arm gleichzeitig laufen lassen
Hazard3 ist ein Open-Source-Design, und die Unterlagen sind öffentlich. Es ist eine leichte, dreistufige, in-order RV32IMACZb*-Maschine, die neben der 32-Bit-Basis-ISA von RISC-V Hardware-Multiplikation und -Division, atomare Instruktionen, Bitmanipulationen und mehr unterstützt
Eben Upton erklärte: „Das ist beim Booten wählbar. Jeder Port in die Bus-Fabric kann über einen Mux entweder mit einem M33 oder einem Hazard3 verbunden werden. Wenn man nerdig sein will, kann man auch je einen davon laufen lassen“
Quelle: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
Die tatsächlichen Instruktionskerne nehmen normalerweise im Vergleich zu Peripherie oder internem Speicher recht wenig Fläche ein
So kann man sowohl die technische Validierung als auch die Marktakzeptanz mit deutlich geringeren Kosten prüfen, als wenn man einen separaten Chip neu tape-outet
Sehr cool, dass man auf Wunsch ein vollständig Open-Source-RISC-V wählen kann. Ich vermute, der RV-Kern wird bei der Leistung pro Takt langsamer sein als der M33, und die Benchmark-Werte des M33 dürften besser ausfallen. Das liegt daran, dass Hazard3 eine dreistufige Pipeline hat, wobei der M33 allerdings ebenfalls dreistufig ist. Ich freue mich auf Benchmarks
Offizieller News-Beitrag: https://news.ycombinator.com/item?id=41192341
Offizielle Produktseite: https://news.ycombinator.com/item?id=41192269
Doom wurde auf den RP2040 portiert: https://kilograham.github.io/rp2040-doom/
Auf dem RP2350 scheint sogar Quake ausführbar zu sein. Einige Änderungen wirken fast so, als wären sie genau für diesen Zweck entworfen worden. Es gibt eine FPU, Dual-Core mit 150 MHz, die Möglichkeit zum Übertakten auf über 300 MHz und Unterstützung für bis zu 16 MB PSRAM mit Hardware-Read/Write-Paging
Dass das Entwicklungsboard micro-USB nutzt, ist nicht so toll. Selbst 2024 noch
Ansonsten ist es hervorragend und genau das Produkt, das es braucht, um mit den etablierten großen Anbietern zu konkurrieren
Es ist gut, dass moderne Produkte alle USB-C haben, aber es liegen auch noch viele micro-USB-Kabel herum, daher ist es kein großes Problem, dass der offizielle Pico und Pico 2 micro-USB haben. Gut ist, dass man je nach Projekt den gewünschten Port auswählen kann
Auch der Interface-Chip muss komplexer sein und dürfte deshalb teurer sein. Auf AliExpress gibt es immer noch viele günstige Geräte mit micro-USB, und Nachfrage dürfte es ebenfalls geben. Je nach Kundengruppe kann man aus dem Entwicklungsboard selbst ein Consumer-Produkt machen
Es ist etwas überraschend, dass das zweite Mikrocontroller-Produkt eines jungen Unternehmens, das verbraucherorientiert wirkt, so viel Security enthält
Anfangs hatte ich wegen mangelnder Erfahrung das Gefühl, der Sicherheit nicht vertrauen zu können. Aber auch Security-Mikrocontroller von „erfahrenen“ Anbietern haben viele bekannte Sicherheitsbugs, und wichtiger noch: Es gab Fälle, in denen sichtbar wurde, dass solche Probleme lieber vertuscht werden sollten. Zwei Audits der Sicherheitsarchitektur, ein Bug Bounty von 10.000 Dollar und der Entwurf eines Boards für Glitching wie beim DEF-CON-Badge zeigen ein ziemlich starkes Engagement für Sicherheit. Mich interessiert auch, wie der Redundancy Coprocessor funktioniert. Trotzdem wäre es nicht überraschend, wenn jemand zumindest Teile davon knacken könnte
Mit verbraucherorientiert ist hier eher die Wahrnehmung gemeint; bei Umsatz und Lieferketten scheint man industrielle Anwender priorisiert zu haben
Offizielle Ankündigung oder Datenblatt habe ich noch nicht gefunden, aber laut diesem Artikel sieht es nach einem großen Sprung gegenüber dem RP2040 aus
Offenbar enthalten sind 2× Cortex-M33F, verbessertes DMA, mehr und verbesserte PIO, Unterstützung für externes PSRAM, 2 MB interner Flash und eine 80-Pin-Variante, verdoppelter RAM auf 512 KiB sowie einige RISC-V-Kerne. Vielleicht für Low-Power gedacht