Warum ich den RP2040 bevorzuge
(dgroshev.com)- Der RP2040 von Raspberry Pi ist ein Mikrocontroller für den Einsatz in Consumer-Elektronik; er ist günstig und in großen Stückzahlen leicht verfügbar, was die Entscheidung zu Beginn der Entwicklung erleichtert
- Statt vieler Varianten konzentriert sich Raspberry Pi auf ein einziges Bauteil: Das reduziert zwar die feingranulare Optimierung der Spezifikationen, sorgt aber dafür, dass Fragen, Beispiele, Libraries und Tools an einem Ort zusammenkommen
- Der Preis von etwa 70 Cent kann bei der Optimierung der Stückkosten in der Massenproduktion nachteilig sein, doch bei Projekten wie Late Mate kann die Einsparung bei den Entwicklungskosten der größere Vorteil sein
- Die Ausstattung mit zwei Kernen, 30 GPIOs, USB, UART/SPI/I2C/PWM, mehr internem RAM und keinem integrierten Flash kommt einem ausreichenden und flexiblen Kompromiss nahe
- PIO, ein schreibgeschützter Bootloader und ein Design, das übertriebene Firmware-Schutzmaßnahmen vermeidet, lassen den RP2040 als praktisches Bauteil für bestimmte Einsatzzwecke erscheinen
Ein Ökosystem durch die Ein-Bauteil-Strategie
- Der RP2040 ist ein von Raspberry Pi entwickelter Mikrocontroller und anders als die bekannteren Raspberry-Pi-Boards für den Einbau in Consumer-Elektronik gedacht
- Bei Mouser sind Zehntausende Stück sofort lieferbar, der Preis liegt bei etwa 70 Cent
- Typische Mikrocontroller-Hersteller bieten viele ähnliche, aber leicht unterschiedliche Produkte an
- Physische Produkte verursachen Herstellungskosten, daher wirkt sich in der Massenproduktion schon eine Einsparung von 1 Cent pro Bauteil auf die Marge aus
- Dadurch entsteht ein Anreiz zum Right-Sizing, also zur Auswahl eines Mikrocontrollers mit genau der zum Produkt passenden Leistung
- Raspberry Pi konzentriert sich beim RP2040 faktisch auf ein einziges Bauteil
- Die Auswahl und der Spielraum für feine Spezifikationsanpassungen werden kleiner
- Dafür sammeln sich StackExchange-Fragen, Blogbeiträge, Erfahrungen, GitHub-Issues, Libraries und Tools rund um dasselbe Bauteil
- Projekte wie Late Mate können bei den Entwicklungskosten mehr einsparen als bei den Bauteilkosten, sodass die Ein-Bauteil-Strategie ein guter Kompromiss sein kann
- Die Rust-Unterstützung ist gut, etwa mit den Embassy-Beispielen, außerdem gibt es Firmware-Beispiele für Tastaturen, Drohnen und Fußballroboter
Ausreichende Hardware und die Flexibilität von PIO
- Das Design des RP2040 ist weniger auf „Maximalausstattung“ ausgelegt, sondern eher ein universeller Kompromiss mit ausreichender und flexibler Ausstattung
- Er bietet zwei ordentliche Kerne, wobei der zweite Kern bei Bedarf genutzt werden kann
- Mit 30 GPIOs liegt er im durchschnittlichen Bereich
- Es gibt keinen Onboard-Flash; stattdessen wurde mehr Budget in internen RAM gesteckt, der extern schwieriger anzubinden ist
- Der ADC ist ordentlich, außerdem bietet er USB und gängige Peripherie wie UART/SPI/I2C/PWM
- Zu den weniger traditionellen Funktionen gehört PIO
- PIO steht für Programmable Input/Output und ähnelt zwei kleinen Hilfsprozessoren, die schnelle IO mit exaktem Timing ausführen, ohne CPU-Zeit zu verbrauchen
- Es wird zur Implementierung von Kommunikationsprotokollen wie DShot ESC verwendet
- Pico-PIO-USB implementiert einen vollständigen USB-Stack auf PIO und stellt dem RP2040 damit einen zweiten USB-Controller bereit
- Zusammen mit DMA kann ein Display-Treiber die Kommunikation mit Display und Touch vollständig von der CPU auslagern
Bootloader gegen Brick-Zustände und Sicherheitskompromisse
- Der RP2040 hat eine Struktur, die nicht in einen Brick-Zustand versetzt werden kann
- Er enthält einen schreibgeschützten Bootloader
- Firmware lässt sich aktualisieren, indem das Gerät als USB-Massenspeicher gemountet und die Firmware auf das „Speichergerät“ kopiert wird
- Das eigene einfache USB-Protokoll wird von picotool genutzt
- Unter der Annahme, dass sich Firmware vor einem gezielten Angreifer kaum schützen lässt und schon der Versuch Komplexität sowie Kosten für die Developer Experience verursacht, verzichtet das Design auf übertriebene Sicherheitsinszenierung
- Diese Entscheidungen lassen sich als Ergebnis einer pragmatischen Balance verstehen, die die Nische berücksichtigt, in der ein kleines Siliziumbauteil eingesetzt wird
1 Kommentare
Meinungen auf Hacker News
Der eigentliche Star des RP2040 ist PIO; es bietet Fähigkeiten, mit denen konkurrierende Chips wie der ESP32 schwer mithalten können.
Deshalb wird er im Bereich Console Hacking an vielen Stellen eingesetzt. Für batteriebetriebene Anwendungen wäre es allerdings schön, wenn bei V2 der Stromverbrauch im Deep-Sleep-Modus niedriger ausfiele.
Digitale Logik, die sich in einem FPGA verifizieren lässt, ist meist in Ordnung, aber analoge Elemente sind viel schwieriger fein abzustimmen; das zeigt sich dann in schlechtem Stromverbrauch, einem schwachen ADC und dem Fehlen eines internen DAC oder Operationsverstärkers. Dass der Funkchip des Pico W nicht wie beim ESP32 vollständig integriert ist, sondern ein separates Standardbauteil, geht in eine ähnliche Richtung.
Für die Implementierung sehr grundlegender Peripherie ist es großartig, aber mehrmals habe ich angefangen, etwas etwas Komplexeres zu bauen, nur um festzustellen, dass es zu langsam ist und der Platz nicht reicht. Mit ein bisschen mehr Leistung könnte es ziemlich leicht kleinere FPGA-Anwendungen ersetzen.
Wenn man viele I/Os braucht, schaut man normalerweise nicht zum ESP32. Seine Stärken sind, dass er günstig ist und WiFi integriert hat. Es gibt viele andere Mikrocontroller-Optionen, die im Vergleich zum RP2040 ebenfalls gut dastehen, aber die meisten richten sich nicht an den Hobby-Markt.
Wir haben in den letzten Jahren den RP2040 für die elektronischen Badges[1] der Sicherheitskonferenz RVASec verwendet, und die Erfahrung beim Schreiben der Software war ziemlich gut.
Hier ist das GitHub-Repository des diesjährigen Badges. Es gibt einen reinen Software-Badge-Simulator, mit dem man auch ohne Hardware ein Stück weit herumspielen kann; die Multiplayer-Funktion, die auf Infrarot-Kommunikation zwischen Badges basiert, dürfte dann allerdings weniger Spaß machen: https://github.com/HackRVA/badge2024
[1] Video zum Badge 2023: https://www.youtube.com/watch?v=KWZriUMNpLc
[2] https://rvasec.com/
Die Aussage „derselbe Mikrocontroller und nur zwei Bugfix-Revisionen“ ist nicht korrekt.
Tatsächlich ist es genau derselbe Mikrocontroller, nur mit zwei Verpackungsoptionen. Die eine ist eine 7-Zoll-Rolle mit 500 Stück, die andere eine 13-Zoll-Rolle mit 3400 Stück. Man muss nur beim „Ordering code“ im Datenblatt nachsehen: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
Wenn man das offizielle SDK verwendet, muss man sich kaum darum kümmern, welche Version es ist. Die standardmäßigen High-Level-Bibliotheken erkennen zur Laufzeit die Hardware-Revision und aktivieren oder deaktivieren die nötigen Workarounds.
Der RP2040 hat den ziemlich nischenhaften Markt für Custom Controller praktisch im Alleingang wiederbelebt.
Dank gp2040[1], einer Open-Source-Gamepad-Firmware, können Leute Fightsticks und leverless Controller in ordentlicher Qualität deutlich günstiger kaufen als Produkte von Herstellern wie Victrix oder Razer. Weil es Open Source ist, entstehen in der Controller-Hobby-Community außerdem RP2040-PCBs für alle möglichen Projekte und ungewöhnlichen Controller-Ideen.
[1] https://gp2040-ce.info
Ich frage mich, wie viel davon man direkt dem RP2040 zuschreiben kann. Projekte wie QMK0 nutzen schon seit langer Zeit eine technisch ziemlich ähnliche Codebasis für DIY-Tastaturen.
Auf den ersten Blick scheint GP2040 nichts zu enthalten, was nicht auch mit einem halbwegs modernen anderen Mikrocontroller möglich wäre. Der RP2040 war sicherlich ein Katalysator für die breite Verbreitung von GP2040, aber mit einem Pro Micro wäre etwas Ähnliches vermutlich ebenfalls möglich gewesen.
PhobGCC sollte man ebenfalls nicht auslassen. Ich bin der Lead Developer, und es gibt außerdem weniger GameCube-spezifische Nachfolger wie ProGCC V3, GC Ultimate und Phizard.
Die Formulierung „im Alleingang“ scheint mir frühere Dinge wie Brook-Boards, zum Beispiel Zero-Pi[1], zu unterschätzen. Historisch gesehen ist das wohl nicht ganz richtig.
[1] https://www.brookaccessory.com/detail/53169470/
Wenn man Elektronik als Hobby betreibt, aber keine eigenen SMD-Boards herstellen oder entwerfen möchte, gibt es sehr viele günstige und gut zugängliche RP2040-Boards.
Ich habe den Raspberry Pi Pico ($5) verwendet; er sitzt auf einem ordentlichen Board mit vielen I/Os. Für etwas mehr Geld gibt es auch die W-Version mit WiFi.
Wenn etwas weniger I/O in Ordnung ist, kann man den RP-2040 Zero bestellen. Ich habe bei AliExpress 6 Stück für etwa $12 gekauft. Er hat nur 23 I/O-Pins, aber einen Reset-Button, USB-C und ist sehr klein (1,5 cm x 2,5 cm).
Das Gute an solchen Boards ist, dass die Standard-Entwicklungswerkzeuge für Raspberry Pi, MicroPython und C++ unverändert gut funktionieren und man Firmware bequem per USB aufspielen kann.
pico ice würde ich ebenfalls empfehlen. Der Großteil des Preisschilds von 30 US-Dollar geht zwar auf den verbauten UP5K zurück, aber für Embedded-Projekte, die Abläufe im Submikrosekundenbereich benötigen, ist es eine vergleichsweise günstige Option, bei der man Open-Source-Tools nutzen kann.
Ich empfehle dringend, sich an verschiedenen Stellen nach alternativen RP2040-basierten Entwicklungsboards umzusehen. Das offizielle Pi Pico ist überraschend mittelmäßig, und fast jedes alternative Board ist in irgendeiner Hinsicht besser.
Kein Reset, großer Formfaktor, nur 2 Mbit Flash, micro USB – im Jahr 2024 ist das schon etwas fragwürdig. Fast der einzige Vorteil ist, dass es breit verfügbar ist.
Kleine RP2040-Boards sind gut. Ich habe auf Basis des adafruit QT Py ein paar kleine Projekte gebaut.
Eine Wireless-Version wäre schön. Mit dem ESP32 QT gibt es so etwas zwar, aber mit RP2040 scheint es mir das nicht zu geben.
Wenn der Platz nicht extrem knapp ist, sehe ich den Vorteil des 2040 Zero nicht so recht. Er hat weniger Funktionen, ist aber teurer. Der Pico ist ohnehin schon ziemlich klein.
Trotzdem ist die Pin-Kompatibilität des Pico wirklich gut. Bei ESP sieht es zwar so aus, als gäbe es viele I/O-Pins, aber wegen Pins, die mit internem Flash, Bootloadern usw. verbunden sind, schrumpft das mit Glück gerade so auf ausreichend zusammen. Ich frage mich auch, warum man solche Pins überhaupt nach außen führt. Der ESP32-CAM hat 10 Datenpins, aber tatsächlich allgemein nutzbar sind nur 4.
Der Grund, warum ich von ESP32 auf RP2040 gewechselt bin, war, dass es ein stabileres und besser dokumentiertes Bauteil war.
Meine einzige aktuelle Sorge beim RP2040 ist, dass es viele ESP32-Modelle mit SPIRAM gibt, aber RP2040-Boards mit SPIRAM nicht besonders leicht zu finden sind. Ehrlich gesagt ist die C-Entwicklungsumgebung des RP2040 so gut, dass man den Speicher gut ausnutzen kann, aber für große MicroPython-Projekte ist SPIRAM ein wirklich großer Vorteil. Abgesehen davon ist am RP2040 alles hervorragend.
Dario Nieuwenhuis, eine der zentralen Personen hinter Embassy, hat bei RustNL einen sehr guten Überblicksvortrag gehalten: https://www.youtube.com/watch?v=H7NtzyP9q8E
JLC bestückt RP2040-Boards bei einer Stückzahl von 5 für unter 3 US-Dollar pro Stück.
Der Vergleich ist eigentlich einer zwischen Äpfeln und Pfirsichen. RP2040 ist einfach ein Chip, während es auf der ESP32-Seite viele Optionen mit allen möglichen gewünschten Peripheriegeräten gibt.
Man kann zwischen WiFi-/Bluetooth-Antenne, Lithium-Ionen-Akku-Controller, Ethernet, Display- oder Kameraanschlüssen usw. wählen.
Auch bei der CPU gibt es verschiedene Optionen, und wenn man das Ganze mit einer Knopfzelle betreibt, macht es einen Unterschied, ob Strom für einen unnötigen zweiten Core oder WiFi verbraucht wird.
Bei der C6-Variante hat Espressif sogar die ISA erneut gewechselt: vom 8266 über den ESP32 hin zu einer RISC-V-basierten ISA.
Am Ende vergleicht man hier gewissermaßen ein SoC der ersten Generation mit einer 10 Jahre alten SBC-Familie.
Du scheinst das ESP32-Devkit mit dem ESP32 selbst zu verwechseln. Antenne, Akku-Controller oder irgendwelche Steckverbinder sitzen auf einem Devkit oder zumindest auf einem Modul. Der ESP32 selbst ist wie der RP2040 ein kleiner IC.
Du denkst vermutlich an ein Devkit wie dieses: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s...
Dieses Board selbst basiert wiederum auf einem Modul wie dem ESP32-S3-WROOM-1, und dieses Modul bündelt den ESP32-S3-IC mit Komfortelementen wie WiFi-Antenne oder -Anschluss.
Das entsprechende Gegenstück beim RP2040 ist der Raspberry Pi Pico, und auch dort gibt es kleine Komfortelemente wie eine WiFi-Variante. Es gibt auch Produkte, die ihn zusammen mit anderen Peripheriegeräten verpacken.
Weder der RP2040 noch die ESP32-Serie sind SBCs, und beide haben auch keine SBC-Abstammung. Die Raspberry-Pi-SBCs basierten alle auf Broadcom, während der RP2040 ein von Raspberry Pi neu entwickelter IC ist und meines Wissens auch keine von Broadcom lizenzierte IP enthält.
Technisch stimmt das, aber im Kern geht es eher um den Einsatzzweck. Der RP2040 ist tatsächlich etwas Eigenständiges und wurde nicht nur für Hobby und Bildung, sondern auch für professionelle Embedded-Geräte plötzlich für viele Projekte zu einer hervorragenden Wahl.
Gemessen an den Möglichkeiten pro Preis deckt eine einzige Chip-Version wirklich viele Bereiche ab. Für mich ist genau so etwas die Bedeutung von technischem Fortschritt.
Es ist sicherer, davon auszugehen, dass auf beiden Seiten vom Chip selbst die Rede ist. Beide kann man an Akkulader, Kameras oder Reaktoren anschließen, aber solche Peripheriegeräte haben mit diesem Vergleich überhaupt nichts zu tun.
Mich würde interessieren, ob es beim Thema Modulintegration wie WiFi eine nicht-chinesische Alternative gibt, die mit ESP vergleichbar ist. Es wäre auch in Ordnung, wenn sie mehr kostet.
Beim RP2040 habe ich gemischte Gefühle.
Einerseits ist er ein hervorragender Chip für Hobbyentwickler. Er ist billig, leicht zu bekommen, das Board-Design ist einfach, und er bietet genug von dem, was man für durchschnittliche Anwendungen braucht.
Andererseits fehlt aus professioneller Sicht eindeutig ein wenig. Die Peripherie ist in Ordnung, aber sobald man ins Detail geht, stößt man leicht auf Grenzen. Das XIP-Interface ist großartig, unterstützt aber keine Schreibzugriffe, sodass man keinen FRAM-Chip anschließen kann, um den Speicher zu erweitern. Das PIO-Interface ist erstaunlich, aber wenn man komplexere Interfaces implementieren will, ist die Beschränkung auf 2 × 32 Instruktionen ziemlich groß. Wo ist Timer/Counter? Kein kapazitiver Touch? Nur vier analoge Pins? Keine 5-V-toleranten Eingänge? Warum gibt es keinen schnellen Takteingang für die PIO-Module? Warum kann der Bootloader nicht mit dem internen Ringoszillator laufen? Ein USB-C-PHY wäre auch schön gewesen.
Auch die schlechte ESD-Performance hat mich überrascht. Atmega oder STM32 kommen gelegentlich mit elektrostatischen Entladungen zurecht, und ESD-Schutz an nach außen geführten Ports ist eher ein Nice-to-have. Beim RP2040 sieht man praktisch, dass im Alltagsbetrieb einige Pins sterben, wenn man nicht an allen Pins externen Schutz hinzufügt.
Kurz gesagt: ein toller Chip und für Hobbyprojekte hervorragend, aber in einem professionellen Umfeld wäre er wohl nicht meine erste Wahl.
Ich frage mich, was mit USB-C PHY genau gemeint ist. USB-C ist ein Stecker, darüber kann man USB 1.1/2.0/3.0/3.1 betreiben. Realistisch gesehen kann der RP2040 nicht einmal einen USB-2.0-PHY richtig auslasten.
Auch Hobbyentwickler landen irgendwann bei komplexeren Projekten und stoßen genau dann auf solche Grenzen.
Ich frage mich, für welche Arten von Anwendungen FRAM am nützlichsten war. Die Technik selbst wirkt wirklich cool, aber sie ist so teuer, dass schwer zu verstehen ist, wann man sie statt einer Kombination aus SRAM oder PSRAM und NAND einsetzen sollte.
Das Synopsys DesignWare SSI-Makro im RP2040 ließe sich tatsächlich wohl für les- und beschreibbares PSRAM oder FRAM verwenden. Allein mit der gekürzten Dokumentation im RP2040-Datenblatt scheint es aber nicht auszureichen, um es entsprechend zu konfigurieren.
Raspberry Pi begann ursprünglich als gemeinnützige Bildungsorganisation.
Der RP2040 ist ziemlich cool, und ich habe ihn bisher in einem halben Dutzend Projekten verwendet.
Aber der Ansatz „einer für alles“ passt für mich nicht. Ich bevorzuge es, den kleinsten Mikrocontroller zu verwenden, der die nötige Aufgabe erledigen kann.
Der Grund, warum ich den möglichst schwachen Mikrocontroller verwenden will, ist nicht Geld, sondern das Power Budget. Die meisten meiner Projekte laufen mit Batterien, daher ist es ein großer Vorteil, möglichst wenig Strom zu verbrauchen.
Trotzdem: Warum sollte man einen Mikrocontroller für 1 Dollar verwenden, wenn ein 20-Cent-Teil dasselbe kann?
Einen weniger leistungsfähigen Controller zu verwenden, um die Batterielaufzeit zu verlängern, ist ein völlig guter Grund. Billiger zu sein ist theoretisch gut, aber bei einmaligen Projekten in der Praxis fast bedeutungslos. Ich erinnere mich nicht einmal, wann ich zuletzt einen Kauf wegen ein paar Dutzend Cent Unterschied entschieden habe; spürbar ist das nicht.
Ich mag den RP2040, möchte aber erklären, warum ich ihn in aktuellen Projekten verlassen habe.
Erstens kam die Kontroverse um PlatformIO bei mir wirklich schlecht an. Ich möchte auf der Seite der Entwickler stehen, die unter Tooling-Chaos leiden.
Zweitens kommt der ESP32-S3 im Top-End als Modul, das man im Grunde mit nur ein paar Entkopplungskondensatoren auf ein PCB setzen kann. Beim RP2040 muss man rund ein Dutzend Bauteile, einschließlich Quarz, sorgfältig platzieren. Module reduzieren nicht nur die Implementierungskomplexität stark, sondern verringern durch Standardisierung auch die Wahrscheinlichkeit, dass jeder Engineer dumme Fehler bei der Bauteilplatzierung macht.
Drittens hat der ESP32-S3 14 GPIO-Pins, die sich als kapazitiver Touch konfigurieren lassen; der RP2040 hat das nicht. Die meisten Projekte, die RP2040 und kapazitiven Touch kombinieren, verlassen sich auf den MPR121, und dieser IC ist abgekündigt, was in den nächsten Monaten wahrscheinlich viele eilige Redesigns auslösen wird.
Irgendwann wird der RP2040 sehr wahrscheinlich auch stärkere oder schwächere Varianten sowie Modulversionen bekommen. Man wird es wohl nicht bis zu einer Situation wie bei STM oder PIC treiben, aber auch die ESP32-Familie wirkt nicht mehr so seltsam, wenn man sich erst einmal daran gewöhnt hat.
Espressif scheint bei PlatformIO in derselben Lage zu sein wie Pi[1]. Von außen betrachtet wollte PlatformIO offenbar sehr hohe jährliche Gebühren von RPi und Espressif verlangen, und zwar nachdem die anfängliche Unterstützung hinzugefügt worden war und ein Teil der Community sie zu übernehmen begann.
Eine merkwürdige Situation, aber es wirkt so, als hätte PlatformIO zunächst durch Unterstützung vieler Plattformen und das Annehmen von Community-Beiträgen eine dominante Position aufgebaut und dann im Nachhinein versucht, direkt Wert von den Herstellern abzuschöpfen. Sie blockierten auch Community-PRs, die neue Board-Revisionen hinzufügen oder Bugs beheben sollten. Siehe dazu: [2]
[1] https://github.com/platformio/platform-espressif32/issues/12...
[2] https://github.com/platformio/platform-raspberrypi/pull/36
Fairerweise muss man sagen: Der RP2040 ist so entworfen, dass sich diese Bauteile wirklich leicht platzieren lassen. Es gibt praktisch nur eine sinnvolle Anordnung, und man kommt leicht an alle gewünschten Pins heran.
Zusammen mit der hervorragenden Dokumentation ist es fast ein Drop-in-Design mit mehreren Bauteilen, das man einmal einsetzt und dann nicht mehr weiter bedenken muss. Am Anfang sah es etwas einschüchternd aus, aber die tatsächliche Umsetzung hat wirklich Spaß gemacht.
Ich benutze den RP2040 seit dem Launch und habe PlatformIO nie verwendet; mich würde interessieren, wie du es genutzt hast und was daran so schlecht war.
Lokal mit cmake und dem Pico SDK oder mit MicroPython zu entwickeln wirkt sehr einfach; ich verstehe nicht ganz, warum man PlatformIO da hineinmischen sollte.
Ich glaube nicht wirklich, dass es einen nennenswerten Mehrwert bringt, daraus ein Modul zu machen. Jeder will einen etwas anderen Formfaktor, und das Design der Peripheriebeschaltung ist so einfach, dass ein Modul kaum klaren Nutzen liefert.
Touch ist eher eine Nischen-Einzelfunktion, und es ist sogar besser, sie nicht einzubauen. Dafür sollte man einen anderen IC verwenden, und dass Leute aus Bequemlichkeit an einem abgekündigten Bauteil festhalten, ist nicht RPis Problem. Oder man implementiert es eben in Software.
In diesem Punkt stimme ich dem Originalbeitrag zu und finde, dass die Foundation die Produktdefinition wirklich gut gemacht hat.
Ich habe über Jahrzehnte Chips von Atmel, STM, TI, Ambiq, Nordic und anderen in Designs eingesetzt; es ist nicht so, als hätte es keine Möglichkeit gegeben, solche Probleme zu lösen. Der Praktikant zwei Yards neben mir kämpft gerade bei seinem ersten PCB-Design damit, die richtigen Bauteile um einen STM herum zu platzieren. Für jemanden, der so etwas auch nur ein bisschen gemacht hat, ist das kein schwieriges Problem.
Diese rund ein Dutzend Bauteile sind ohnehin Oszillator-/Quarzschaltung, Reset-Hold-up, 3,3-V-Versorgung und sehr viele Entkopplungskondensatoren. Antennentuning kann sicher schwierig sein, aber wenn man eine Chipantenne verwenden kann, ist auch das nicht so schwer.
Das alles ist so standardisiert, dass ich beim Blick auf den Schaltplan des Adafruit RP2040 Feather eher überrascht war, wie viel davon offenbar nahezu unverändert von bestehenden Feathers übernommen wurde. Die Unterschiede zwischen dem RP2040 Feather und dem nRF52840 Feather sind der Mikrocontroller selbst, die gesamte Timing-Schaltung für den RP2040 mit fünf Bauteilen und die Antennenschaltung für das Nordic-Board.
Module sind sehr praktisch, um sie an den Hobby-Markt zu verkaufen, aber wenn man ein echtes Produkt verkaufen will, muss man trotzdem durch den RF-Zertifizierungsprozess. Die Kosten können sinken, aber ob die höheren Vorabkosten eines Moduls durch niedrigere Zertifizierungskosten ausgeglichen werden, muss man selbst beurteilen. Am Ende spart man sich dennoch im Wesentlichen nur den Antennentuning-Schritt, und normalerweise ist das keine große Layout-Änderung, sondern wird über eine BOM-Variante gelöst.
Bei STM- und PIC-Chips ist es genauso: Davon gibt es Dutzende Varianten, und bei TI ist die Lage dieselbe. Kunden wollen nur für das bezahlen, was sie brauchen, und die Hersteller haben die Produktionskapazität, um diese Nachfrage zu bedienen. Wenn die Unterschiede wichtig sind, ist das keine Belastung. Das ist ganz ähnlich, als würde man sich beschweren, dass Home Depot zu viele Holzsorten verkauft.