Hallo zusammen! Ich möchte von einem STM32WB55 aus möglichst breitbandig Daten an eine MPU (ARM oder amd64) auf dem gleichen, spezialangefertigten Board (eines Linux-Systems) übermitteln und möchte USB möglichst vermeiden. Was habe ich da für Möglichkeiten? UART wäre mir natürlich gleich eingefallen, ist aber zu langsam.
Bei dem Chip hast du dann noch laut Datenblatt 2xSPI mit max 32 MBit/s
Fabiano S. schrieb: > möglichst breitbandig ... ist gleichzeitig auch "möglichst teuer". Wie wäre es wenn du sagst welche Bandbreite du mindestens brauchst.
Fabiano S. schrieb: > an eine MPU (ARM oder amd64) Tja, was hat die für Schnittstellen? Und welche davon wird von dem Linux, das darauf laufen soll, auch unterstützt? Das entscheidet darüber, was Du verwenden kannst.
Fabiano S. schrieb: > Ich möchte von einem STM32WB55 aus möglichst breitbandig Daten UWB!! Breiter geht nicht! https://de.wikipedia.org/wiki/Ultrabreitband Ansonsten. Siehe Netiquette. "Das Problem in Zahlen fassen! Nicht einfach schreiben "so schnell wie möglich", "so stromsparend wie möglich" etc, sondern mal ein paar Zahlen nennen. X MHz, Y ms, Z µA etc. Wenn man keine exakte Vorstellung davon hat, sollte wenigstens eine Größenordnung angegeben werden (1..5 MHz, <1mA etc.)"
Tut mir leid, dass ich die Bandbreite nicht näher beschrieben habe. Aber ich habe die Anwendung noch nicht ganz zu Ende "designt" und daher auch etwas generell gedacht. 32 Mbps sollten aber fürs erste reichen... An SPI hab ich auch gleich gedacht, dann müsste ich aber das Linux-System um SPI-Funktionalität erweitern, was ich eigentlich vermeiden will. Aber wenn es gar nicht anders geht, was wäre dann die Vorgehensweise? Natürlich könnte ich mit ICs wie MCP2210 arbeiten, aber dann kommt wieder USB ins Spiel...
Fabiano S. schrieb: > An SPI hab ich auch gleich gedacht, dann müsste ich aber das > Linux-System um SPI-Funktionalität erweitern, was ich eigentlich > vermeiden will. Wie Harald schon schrieb: Schau dir an, welche Schnittstellen du zur Verfügung hast, die deine Anforderungen erfüllen. Aus denen musst du dann wohl oder übel auswählen. Und was dein spezialangefertigtes Linux-Board außer USB noch an Schnittstellen hat, weiß außer dir ja keiner hier. Wie soll man da was vorschlagen?
Fabiano S. schrieb: > 32 Mbps sollten aber fürs erste reichen... Wurde für sowas nicht Ethernet erfunden? Gruß Klaus (der soundsovielte)
Fabiano S. schrieb: > dann müsste ich aber das > Linux-System um SPI-Funktionalität erweitern Ist beim RaspberryPi bereits enthalten.
Fabiano S. schrieb: > aber dann kommt wieder USB ins Spiel... Und was ist Dein Problem mit USB? Damit lassen sich erheblich höhere Datenraten erzielen als die genannten 32 MBit/sec, vorausgesetzt, Dein ARM kann auch High-Speed USB2.0 (und nicht nur, wie einige einfachere Kandidaten, nur Full-Speed mit 12 MBit/sec Brutto).
Fabiano S. schrieb: > Aber ich habe die Anwendung noch nicht ganz zu Ende "designt" und daher > auch etwas generell gedacht. 32 Mbps sollten aber fürs erste reichen... Wenn du eh' noch nicht fertig designt hast, dann mach dir doch einfach mal Gedanken, ob und wie du die zu übertragende Datenmenge reduzieren kannst. Denn wenn die Daten übertragen sind, was passiert dann damit? Ab ins Nulldevice oder "für später" auf einen Massenspeicher? Oder werden die evtl. gleich nach der breitbandigen Übertragung im schlimmsten Fall auf 1 Bit (Objekt da oder nicht da) reduziert?
Harald K. schrieb: > Und was ist Dein Problem mit USB? Damit lassen sich erheblich höhere > Datenraten erzielen als die genannten 32 MBit/sec, vorausgesetzt, Dein > ARM kann auch High-Speed USB2.0 (und nicht nur, wie einige einfachere > Kandidaten, nur Full-Speed mit 12 MBit/sec Brutto). Naja, das scheint eben das Problem mit dem STM32WB55:
1 | 1x USB 2.0 FS device |
https://www.st.com/en/microcontrollers-microprocessors/stm32wb55rg.html Wenn das Teil gesetzt ist (evtl. wegen den Funk Geschichten) dann finde ich die SPI bis jetzt den besten Vorschlag. Ein anderes, schnelleres Interface, habe ich auf den ersten Blick auch nicht gesehen bei dem Chip.
N. M. schrieb: > Ein anderes, schnelleres Interface, habe ich auf den ersten Blick auch > nicht gesehen bei dem Chip. Nee, hat er wohl auch nicht: https://www.st.com/en/microcontrollers-microprocessors/stm32wb55rg.html Tja. USB geht dann trotzdem. Nicht mit dem USB-Device-Controller im ARM, sondern mit einer USB-Parallel-Bridge, die an den Linux-Host angeschlossen wird, wie z.B. https://ftdichip.com/products/ft232hl/ Hier wird die Betriebsart "Sync Fifo" verwendet, die kann 40 MByte/sec übertragen. Dann muss der ARM allerdings acht Bits zuzüglich einiger Handshake-Signale ausgeben können. Wenn genügend freie I/O-Leitungen verfügbar sind, sollte das machbar sein. Geht das nicht, lässt sich mit etwas Hardwaregebastel (Schieberegister etc.) auch SPI verwenden, das dann in paralleler Form an die Sync-Fifo-Funktion des FT232HL übergeben wird (bzw. aus dem 'rauskommt).
:
Bearbeitet durch User
Klassischerweise macht man das mit SDIO ("SDMMC"). Damit erreicht man bis 400 Mbps brutto (High Speed Mode, 8bit). Die STM32 haben das allerdings nicht als "Slave" Interface, manche ESP32 aber z.B. schon. Eventuell musst du also einen Controller suchen der das kann.
:
Bearbeitet durch User
Niklas G. schrieb: > Klassischerweise macht man das mit SDIO ("SDMMC"). Wenn das nicht genannte und nur vage spezifizierte Linux-System -- "eine MPU (ARM oder amd64)" -- das kann, dann ja.
Harald K. schrieb: > Niklas G. schrieb: >> Klassischerweise macht man das mit SDIO ("SDMMC"). > > Wenn das nicht genannte und nur vage spezifizierte Linux-System -- "eine > MPU (ARM oder amd64)" -- das kann, dann ja. Ja, aber die allermeisten SoC's können das. Schließlich wird es sehr oft benutzt um externen Speicher (eMMC oder SD-Karte) oder auch WLAN-Module anzubinden. PS: Stellt sich die Frage, ob es nicht vielleicht ein fertiges Funkmodul mit SDIO-Interface gibt, was den STM32WB ersetzen kann. Für WiFi und Bluetooth gibt's das natürlich, für Zigbee & Co vermutlich auch? PPS: ESP32-C6 kann SDIO Slave (200 Mbps) und 2.4 GHz Wi-Fi 6 (802.11ax), Bluetooth® 5 (LE), Zigbee and Thread (802.15.4).
:
Bearbeitet durch User
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.