Hallo zusammen, ich bin momentan mit einem nicht mehr ganz so kleinen Hobbyprojekt beschäftigt. Um den Eingangspost nicht zu groß werden zu lassen, hier nur ganz kurz die Anforderungen, bei Interesse (be-)schreibe ich aber gerne noch etwas ausführlicher. Für die Anbindung einer USB-Schnittstelle bräuchte ich einen passenden MC, aktuell läuft ein NodeMcu (ESP8266). Da der Zugriff sowieso maximal über Fullspeed stattfinden kann, gibt es diesbezüglich keine Anforderungen. Es sollen Dateien per WLAN empfangen und per USB geschrieben werden. Ich hatte eine der STM32 Serien mit USB-Hostmode/OTG in betracht gezogen oder vielleicht so etwas wie ein pic24fj128gb202. Wobei ich eigentlich auf einen externen PHY verzichten möchte. Allerdings möchte ich auch nicht noch eine Baugruppe, da ich schon 5-6 Baugruppen/Module habe. Am liebsten wäre mir etwas wie ein ESP8266 oder ESP32 mit USB-Host/OTG bzw. ein STM32 mit WLAN. Gibt es sowas, könnt ihr was empfehlen oder ist meine beste Chance ein entsprechender STM32 der dann vom ESP8266 angesteuert wird? Danke
ESP32-S2 hat angeblich USB Host: https://hackaday.com/2019/05/21/new-part-day-espressif-announces-esp32-s2-with-usb/ Der kennt dafür aber kein Blueooth mehr - und ich sehe den noch nirgends zu kaufen. Die Programmerung von USB Host ist aber derart kompliziert dass man denn lieber was "dickeres" nimmt wo gleich ein Linux drauf läuft. Lies: Nimm lieber einen RPi oder ähnliches.
SD Karten sollen einfacher sein und funktionieren immer im Gegensatz zu Sticks(Meiner Erfahrung mit Druckern nach, ist wohl nen Treiber Problem)
Jim M. schrieb: > ESP32-S2 hat angeblich USB Host: > > https://hackaday.com/2019/05/21/new-part-day-espressif-announces-esp32-s2-with-usb/ Warum postest Du nicht den Link zum Hersteller? https://www.espressif.com/en/news/espressif-announces-%E2%80%A8esp32-s2-secure-wi-fi-mcu
Spongebob schrieb: > Warum postest Du nicht den Link zum Hersteller? Ich fand den Artikel passender und kompakter. Dort liesst man was von USB auf der 1. Seite, beim Hersteller muss ich weit runter scrollen bis was von USB kommt.
Alt schrieb: > SD Karten sollen einfacher sein und funktionieren immer im Gegensatz zu > Sticks(Meiner Erfahrung mit Druckern nach, ist wohl nen Treiber Problem) SD-Karten sind einfacher, da die meisten (alle?) noch einen SPI-Modus haben und wenn auch langsam aber zuverlässig über SPI beschrieben und gelesen werden können. Das kann auch nen einfacher ATMega z.B. Falls es um Logging oder Config-Files geht, würde ich immer SD einem USB-Stick bevorzugen.
Sebastian R. schrieb: > SD-Karten sind einfacher, da die meisten (alle?) noch einen SPI-Modus > haben Den haben alle, der ist spezifiziert, allerdings wird dort keine garantierte Datenrate geboten. Aus Programmier-Sicht ist die "SD bus" Schnittstelle bis "High Speed" nicht wesentlich komplizierter, kann aber Datenraten bis 10 MB/s garantiert. Das können aber dann nur Controller mit entsprechendem "SDIO" oder "SDMMC" Modul. Das ist aber alles immer noch viel einfacher als eine USB Host Implementation...
Danke für den Vorschlag mit dem ESP32-S2. Auf Bluetooth kann ich gut und gerne verzichten. Leider scheint der erst ab September verfügbar zu sein. Als einzigen Verkäufer habe ich jetzt RS gefunden, aber mit einem ganzen Gurtabschnitt (100 Stk.) kann ich momentan wenig anfangen... Ansonsten aber sehr vielversprechend. Auf USB kann ich nicht verzichten, da ich ein dediziertes Bauteil habe, dass eben genau diese Schnittstelle zur Verfügung stellt und nur hierüber einen schreibenden Zugriff anbietet. Gespeichert werden die Daten schlussendlich auf eine Speicherkarte, aber eben über dieses Bauteil. Geschrieben werden sollen Audio- und ggf. Bild-Dateien auf ein FAT16 oder FAT32 FS. Auch da habe ich wenig Spielraum. Um die graußige Programmierung mache ich mir vorerst weniger Sorgen, nach 15+ Jahren in dem Sektor (mit C, CPP, ASM, Perl, C#, Java, etc.) habe ich schon ein paar Sachen gesehen. Bestimmender Faktor ist da eher die zur Verfügung stehende Zeit ;) Einen RPi hatte ich für mich relativ früh ausgeschlossen. Das Ganze soll über 2S2P Li-Ion versorgt werden, mit möglichst wenig Ladezyklen. Da lutscht mir der RPi zu sehr an der Stromquelle (120mA/h vs. ~100µA/h) Vor allen Dingen da ich beim RPi eher weniger Kontrolle über die Powerstates habe. Bei der MC Lösung kann ich die meisten Bauteile für 99% der Zeit in den Stand-By bzw. Deep-Sleep mit Interrupts schicken - das spart ungemein. Stimmt aber das ein RPi Zero W wohl die einfachste Lösung wäre.
Sven C. schrieb: > Auf USB kann ich nicht verzichten, da ich ein dediziertes Bauteil habe, > dass eben genau diese Schnittstelle zur Verfügung stellt und nur > hierüber einen schreibenden Zugriff anbietet. Und das Protokoll dieses Bauteils ist hoffentlich bekannt (USB MSC oder so)? Sven C. schrieb: > Um die graußige Programmierung mache ich mir vorerst weniger Sorgen, Grausig nicht, nur sehr komplex. Es gibt aber auch Libraries dafür.
Sven C. schrieb: > Geschrieben werden sollen Audio- und ggf. Bild-Dateien auf ein FAT16 > oder FAT32 FS. > Auch da habe ich wenig Spielraum. Man nehme eine SDHC Karte. Macht das Leben deutlich leichter. Allerdings musst Du vorher den RAM Bedarf abschätzen - SDHC Karte darf laut Spec für einen Schreibzugriff bis zu einer Sekunde(!) im Worst case benötigen. Dürfte bei Audio knapp werden. USB Stick ist bei Full Speed übrigens langsamer - SD Karte kann SPI bis 25 MHz (und SD Modi noch vieeel schneller), USB nur 12 MHz.
Niklas G. schrieb: > Und das Protokoll dieses Bauteils ist hoffentlich bekannt (USB MSC oder > so)? Das Bauteil propagiert sich als Mass Storage Device, also MSC. MTP oder PTP werden nicht unterstützt. Falls mit bekannt also namentlich bekannt gemeint ist, dann ja. Technisch vertraut wie Dokumentation gelesen, verstanden und bereit Low-Level Treiber dafür zu schreiben - eher nicht.
Sven C. schrieb: > Für die Anbindung einer USB-Schnittstelle bräuchte ich einen passenden > MC Dafür gibt es doch schon einige Jahre den VNC1L [1] [1] https://www.ftdichip.com/Products/ICs/VNC1L.htm
Jim M. schrieb: > Man nehme eine SDHC Karte. Macht das Leben deutlich leichter. Außer das ich die SDHC Karte dann mit z.B. Multiplexern an mehrere Bauteile anklemmen müsste. Oder Dioden und entsprechend das genutzte Bauteil per Transistoren schalten. Für mich hört sich das nach der fummeligeren Arbeit an.
Sven C. schrieb: > Außer das ich die SDHC Karte dann mit z.B. Multiplexern an mehrere > Bauteile anklemmen müsste. Auf einmal mehrere Bauteile? USB müsste man ebenso multiplexen, was noch viel schwieriger ist. Oder wie ist das gemeint? Sven C. schrieb: > Auf USB kann ich nicht verzichten, da ich ein dediziertes Bauteil habe, > dass eben genau diese Schnittstelle zur Verfügung stellt und nur > hierüber einen schreibenden Zugriff anbietet. Was ist das denn für ein kurioses Bauteil? Sven C. schrieb: > Für mich hört sich das nach der fummeligeren Arbeit an. Immer noch viel, viel weniger Arbeit als eine USB-Host-Implementation. Schreib doch mal genauer wo hier zwischen was für Bauteilen was für Daten wie schnell übertragen werden sollen. Es ist so, dass das eigentliche Problem WLAN und nicht USB ist. Im Vergleich zu WLAN ist USB schön einfach und gut dokumentiert, und es gibt viele Controller die das können. WLAN-fähige Controller gibt's aber nur wenige, dokumentiert sind die alle nicht besonders gut und außer zu den Espressif-Teilen findet man kaum Ressourcen. Das Problem ist also, die Kombination aus WLAN und USB zu finden. Da gäbe es ATSAMW25 und CYW54907. Bei denen muss man aber nicht erwarten, WLAN-technisch so komfortabel und schnell an ein Ergebnis zu kommen wie bei ESP, denn die ESP-Teile sind nur deswegen überhaupt nutzbar, weil die Hobby-Community da sehr viel Arbeit hinein gesteckt hat. Mit einem anderen WLAN-Modul von Microchip hab ich die Erfahrung gemacht, dass die zugehörige Software und Doku miserabel ist, alle möglichen Fallstricke lauern und der Support überhaupt keine Ahnung hat. Vielleicht hat man mehr Möglichkeiten wenn man 1 Mio p.a. abnimmt, wer weiß. Wenn auch Ethernet statt WLAN ginge: Es gibt viele Controller mit USB und Ethernet (auch STM32), und das ist besser handhabbar.
Schau dir mal Nuttx an. Das ist ein RTOS, was sehr an Linux angelehnt ist aber eben einen sehr kleinen Footprint hat und somit sogar auf einem STM32F103C8 noch läuft. Nuttx bringt einen kompletten USB-Host Stack mit und es ist relativ einfach den einzubinden. Ich hatte mal vor ein paar Jahren einen Test mit einem F4 Discovery Board gemacht. USB-OTG auf USB Adapter dran, Stick eingesteckt, gemountet und schon konnte ich auf das Teil lesen und schreiben.
Christopher J. schrieb: > Schau dir mal Nuttx an. Danke für den Tipp. Ich werde mir das mal ansehen. Niklas G. schrieb: > Was ist das denn für ein kurioses Bauteil? Niklas G. schrieb: > Auf einmal mehrere Bauteile? USB müsste man ebenso multiplexen, was noch > viel schwieriger ist. Oder wie ist das gemeint? Nicht auf einmal. Ich hatte geschrieben dass das Bauteil auf eine SD-Karte zugreift, diese aber über ein USB-Interface zur Verfügung stellt. Mir ist allerdings ein Fauxpas passiert, geschrieben wird nicht auf eine SD sondern eine microSD Karte. Das Bauteil ist nichts großartiges - ein Sound-Modul ähnlich dem SOMO 2, vom Asiaten des "Vertrauens". Den USB-Zugang habe ich so schon ohne großes umschalten und muss nur darauf achten das während der Zeit kein Zugriff vom µC stattfindet. Da VCC und GND für Player und µC gleich sind muss ich mich darum auch nicht kümmern. Wenn ich die microSD-Karte direkt beschreiben möchte muss ich diese sowohl mit dem Slot des Players als auch mit den Pins des µC verbinden. Niklas G. schrieb: > Schreib doch mal genauer wo hier zwischen was für Bauteilen was für > Daten wie schnell übertragen werden sollen. Wie weiter oben geschrieben. Audiodateien und ggf. noch Bilddateien. Die Daten werden aktuell vom ESP8266 aus dem lokalen WLAN gezogen. Diese Daten sollen auf die microSD-Karte geschrieben werden, die in dem Player hängt und von diesem per USB-Schnittstelle zur Verfügung gestellt wird. Soweit ich das bisher testen konnte läuft die USB-Schnittstelle sowieso maximal mit Fullspeed, mehr braucht es also nicht. Bei Datenmengen von maximal 100MB pro Vorgang finde ich 1,5MB/s zwar nicht optimal ist aber für mich im Rahmen. Besser als jedes mal aufschrauben, Karte rausholen, am PC bespielen, Karte einsetzen und wieder Zuschrauben - schneller ist es allemal. Den ATSAMW25 werde ich mir mal anschauen. Das sieht interessant aus. Ethernet wäre als einzige Möglichkeit suboptimal. Wenn das Ding mal den Standort wechselt (wie gesagt das soll über Li-Ion versorgt werden), dann wäre Essig mit Download.
Der ganze Aufwand für ein Sound-Modul? Du könntest auch direkt vom Mikrocontroller auf eine SD-Karte speichern und die Sounds auf dem Controller abspielen. Dann brauchst du kein Sound Modul und kein USB. Die STM32F4 haben IIRC genug Leistung um MP3 zu dekodieren. Vielleicht kann das ja auch der ESP32. Wenn nicht, musst du dir "nur" überlegen wie du WLAN an einen leistungsfähigen Controller bekommst - z.B. STM32F4 + ESP8266 im AT-Modus über UART, oder das ATWILC1000 an einem beliebigen Cortex-M7 der 2 SDIO Schnittstellen hat. Dieses ATWILC1000 ist allerdings das erwähnte Modul mit den schlechten Erfahrungen. Dafür hat man damit vermutlich den höchsten Durchsatz.
Mit einem STM32 gehts aber recht einfach. Man muss nur im CubeMX bei USB Host ein Häckchen setzen und kann dann mit:
1 | if (f_open(&USBHFile, filename, FA_READ) == FR_OK) |
2 | {
|
3 | while (f_gets(sLine, LINELENGTH, &USBHFile) != 0) |
4 | {
|
5 | ...
|
6 | }
|
7 | }
|
Eine Datei lesen. Schreiben geht ähnlich.
Sven C. schrieb: > Bei Datenmengen von maximal 100MB pro Vorgang finde ich 1,5MB/s zwar > nicht optimal ist aber für mich im Rahmen. Wie kommst du auf 1.5MB/s? USB fullspeed ist 12MB/s brutto. Für Daten stehen max 90% zur Verfügung im besten Fall also 1.35MB/s. Dein Modul wird ISO Daten erwarten, die Frage nach einem Protokoll stellt sich also nicht. Viel Spass mit der Implementierung des USB Audio Hosts. Wie sehen denn die Descriptoren des Moduls aus? Samplerate, Alternate Settings? 48k 16bit braucht 384 Bytes / ms. (frame) Thomas
Thomas Z. schrieb: > Dein Modul wird ISO Daten erwarten, die Frage nach einem Protokoll > stellt sich also nicht. Viel Spass mit der Implementierung des USB Audio > Hosts. Das Modul hat USB MSC, kein Audio. Es spielt selbstständig Daten von der SD-Karte ab. Diese Teile sind dafür gedacht, dass man mit kleinen Controllern Audio-Ausgaben steuern kann - nicht dafür, dass man per USB live Daten hinein füttert, weil die kleinen Controller eben genau das nicht können. Ein Controller, der dem Modul live oder im Vorraus per USB Daten schicken kann, könnte die Audio-Daten wahrscheinlich auch selbst live abspielen und braucht das Modul nicht. Bräuchte man das WLAN nicht, könnte man das alles auf einem STM32F4 oder F7 erledigen (z.B. STM32F746 Discovery hat alles was man braucht) - das WLAN ist hier der eigentliche Strich durch die Rechnung. Vielleicht wäre ein sparsames Embedded Linux Board (gibt ja mehr als nur den R-PI) doch gar nicht so verkehrt, denn mit Linux hat man praktisch freie Wahl an WLAN-Modulen (wg. Treiber) und SD-Karten-Zugriff und Ton-Abspielen ist dann sowieso kein Problem.
Niklas G. schrieb: > Bräuchte man das WLAN nicht, könnte man das alles auf einem STM32F4 oder > F7 erledigen (z.B. STM32F746 Discovery hat alles was man braucht) - das > WLAN ist hier der eigentliche Strich durch die Rechnung. Niklas Gürtler schrieb: > Der ganze Aufwand für ein Sound-Modul? Du könntest auch direkt vom > Mikrocontroller auf eine SD-Karte speichern und die Sounds auf dem > Controller abspielen. Dann brauchst du kein Sound Modul und kein USB. > Die STM32F4 haben IIRC genug Leistung um MP3 zu dekodieren. Das Projekt macht mich noch bekloppt ;) In Anbetracht der Ratschläge hier werde ich mich doch mit einem STM32 + ESP8266 zufrieden geben. Da ich mir sowieso erst einen STM32 mit USB-Host kaufen müsste, hole ich direkt einen STM32F446 und spar mir USB und Sound-Modul. Ein DSP, zwei DAC mit DMA Unterstützung und SDIO-Interface sind onboard, dann sollte es auch ohne Modul klappen. Daran kommt der ESP8266 um Dateien herunterzuladen oder ggf. Nachrichten mit dem MQTT-Broker auszutauschen. Schade eigentlich, mit der Hardware könnte man besseres Anfangen als einen popeligen Iot-Audio-Player (na gut, mit 2-3 Extras) zu basteln... Wenn dann im September der ESP32-S2 rauskommt kann ich ja immer noch testen ob ich es auch mit dem Audio-Modul und dem USB-Host hinbekommen hätte - nur der Neugier wegen, ob der USB-Hostmode wirklich so kompliziert ist :) Danke für die zahlreichen Antworten und Anregungen.
Ich sehe gerade, der ESP32 hat I2S und genug Leistung zum MP3 dekodieren. Du braucht also weder STM32, USB noch Sound Modul. SD-Karten kannst du per SPI schreiben und lesen. Es gibt sogar Code, z.B.: https://github.com/schreibfaul1/ESP32-audioI2S
Thread beobachten
Seitenaufteilung abschaltenBitte 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.