Hallo, ich habe grade versucht bei den üblichen Verdächtigen ein Breakoutboard mit USB HS zu finden - bisher erfolglos. Es gibt einige Cortex M4(f) & M7 mit 64 Beinen und USB HS. Hat jemand schonmal ein kompaktes Breakoutboard gefunden mit dem das ohne externe Beschaltung möglich ist (Phy ist ja meistens extern)? Das SAME70-XPLD kann das z.B., aber mir wäre etwas kompakteres lieber. Es soll auch wirklich eine MCU mit USB HS sein, kein FTDI etc. Wenn mir jemand einen Tipp geben kann, wäre das super :)
EZ-USB FX2 CY7C68013A * mcs51-derivat * sdcc als Compiler "Blue Pill" STM32F105RxT6 * ARM cortex * arm-none-eabi-gcc als Compiler
Danke für den Hinweis! Auf die Idee nach einem 8051 mit USB HS zu suchen wäre ich jetzt wirklich nicht gekommen. Irgendwie grotesk und interessant zugleich. Besorgen werde ich mir so ein Teil auf jeden Fall. Auch wenn ich lieber mit einer moderneren Architektur arbeiten möchte. Mein Traum wäre quasi ein Board in dem Footprint mit einem M4 oder besser. Der Blue Pill ST scheint mir leider nur 12 MBit/s zu haben.
Was genau verstehst du unter Breakout Board? Was genau soll da drauf sein - Controller oder ULPI Chip oder was? Einige STM32F73 haben integrierte USB HS Transceiver. Das STM32F746NG Discovery hat einem USB HS Transceiver IC (ULPI) drauf. Handlich ist das aber alles eher nicht...
Andreas J. schrieb: > Auch wenn ich lieber mit einer moderneren Architektur arbeiten möchte. Dann nimm den Cypress doch einfach nur als Companion zu einem modernen 32bitter nebenan. Beim Bluepill habe ich mich vertan... das ist der '103er. Klar können größere STM32 und andere ARMe Vollgas-USB-2.0, aber auf kompakten Platinchen gibt's die dann auch nicht mehr.
Nachtrag STM32: Der 105er und der 107er können angeblich schon USB2.0 Gibt aber nur klobige Eval-Boards dafür...
Gut wenn man andersrum drüber nachdenkt, sonen 8051 ist schon sehr günstig und für einfache USB-HID "Volumenprodukte" o.Ä. somit sicherlich eine logische Wahl. Mit Breakoutboard meine ich eine Leiterplatte mit Microcontroller, USB, ggfs. Onboard Programmer und eine Menge I/Os die auf DIL Kontakten verfübar sind. So in etwa wie der Arduino Micro. Die SAM(E/S/V)70 haben auch einen integrierten 480 MBit USB Phy, als ich damit gearbeitet hatte, war allerdings nur ab dem 100er Gehäuse USB HS möglich wegen Errata. Aber sehr kompakte Boards scheint es davon und den ST F7s wohl nicht zu geben. Die kleinen ST haben laut Übersicht auf der ST Webseite aber USB 2.0 FS, also nicht HS. Ich denke es wird auf den Cypress als Companion hinauslaufen, oder eben doch mit 12 MBits begügen. Das war sehr hilfreich!
:
Bearbeitet durch User
Wie schaffst du denn die 480 MBit/Sec zum Companion? Und hat der überhaupt die Leistung für so eine Datenmenge?
Der Renesas RX71M hat einen integrierten HS-PHY und spielt mit seiner Rechenleistung jeden ärmlichen ARM Cortex M4/M7 locker an die Wand. Einzig die doppelt genaue FPU fehlt ihm. https://www.renesas.com/en-eu/products/microcontrollers-microprocessors/rx/rx700/rx71m.html
RX Lover schrieb: > Der Renesas RX71M hat einen integrierten HS-PHY und spielt mit > seiner > Rechenleistung jeden ärmlichen ARM Cortex M4/M7 locker an die Wand. > Einzig die doppelt genaue FPU fehlt ihm. > https://www.renesas.com/en-eu/products/microcontro... Hättest Du wohl gerne: Der STM32H7 macht doppelt soviel Coremark wie der Renesas. Und die lausige FPU des Renesas ist da noch aussen vor...
Dr. Sommer schrieb: > Wie schaffst du denn die 480 MBit/Sec zum Companion? Und hat der > überhaupt die Leistung für so eine Datenmenge? In meinem Hobby Project möchte ich USB Midi benutzen. Soweit ich mich erinnere kann bei einem USB FS 12 MBit/s maximal 1 Transfer pro ms gesendet werden. Z.B. 1x Note On = 1 Transfer. (Ist leider ein paar Monate her, dass ich mich eingelesen habe). Die theoretische Bandbreite von 12 MBit/s wird dabei nichtmals ansatzweise genutzt, weil die einzelnen Transfers wenig Payload haben. Diese minimal Intervalle sind im Betriebsystem (bzw. in der USB Spec) aber fest vorgegeben. Um auf eine höhere Anzahl Transfers zu kommen muss es eben USB HS sein. In dem Fall ist der HS also nur Mittel zum Zweck und die Netto Datenmenge eher gering. Das kann auch ein 8051 an eine andere CPU schnell genug weiterreichen. Ich steuere eine LED Lichterkette an und möchte schon so in etwa auf 60 "FPS" kommen. Dazu werden aber um die 10-20 Transfers pro Frame benötigt (die "Lightshow" wird von den Midi Events abgeleitet, die LED Farben werden nicht einzeln über Midi übertragen). Es wäre notgedrungen sicher mit 12 MBit möglich, aber nicht elegant. RX Lover schrieb: > Der Renesas RX71M hat einen integrierten HS-PHY und spielt mit seiner > Rechenleistung jeden ärmlichen ARM Cortex M4/M7 locker an die Wand. Also der Atmel/Microchip SAME70 macht 300 MHz und laut Hersteller 1500 Coremark, der wäre also noch schneller als der Renesas. In meinem Fall reicht alles was eine FP-Unit hat, da ich einige Berechnungen als float ausführe. Auf der Seite steht übrigens, das der Renesas erst in der 176/177 Pin Variante USB HS kann. Scheint wie bei Atmel ein Problem zu sein, den USB PHY in kleinere Gehäuse zu integrieren.
Andreas J. schrieb: > (Ist leider ein paar Monate her, dass ich mich eingelesen habe). Es klingt ein wenig wirr, zugegebenermaßen. Die Forderung nach hsusb wegen der zu großen Latenz von fsusb ist ... Seltsam. Soll der Controller Host oder device sein? Ich mag es nicht die komplette Herangehensweise eines OT in Frage zu stellen, glaube aber, dass dich hsusb nicht viel weiter bringen wird. Prinzipbedingt. Waveshare hat Boards mit stm32f4 und usb3300 hs phy (und Ethernet). Natürlich etwas größer als ein nucleo. Das Layout ist an manchen Stellen fragwürdig, funktioniert aber anscheinend ausreichend gut.
Gibt es nicht für genau so etwas isochrone Transfers?
Nein. Isocrone endpoints werden garantiert einmal pro timeslice bedient und es wird eine feste Bandbreite reserviert. Die Latenz ist bei einem sonst leeren Bus nicht besser als beim Bulk.
Andreas J. schrieb: > Soweit ich mich erinnere kann bei einem USB FS 12 MBit/s maximal > 1 Transfer pro ms gesendet werden. Z.B. 1x Note On = 1 Transfer. Der Treiber kann auch mehrere Noten in ein Paket verpacken, und mehrere Pakete pro Frame versenden/empfangen. Er muss es nur tun, was zumindest bei älteren Windows-Versionen nicht der Fall ist. Roland hat deswegen einen eigenen Treiber für das selbe Protokoll geschrieben, und nennt das ganze "FPT": https://www.cakewalk.com/Support/Knowledge-Base/20090330/Fast-Processing-Technology ("Hardware tuned for the FPT" heißt nur, dass das Gerät dem OS sagt, dass es nicht den Standard-Treiber benutzen will.) Willst du überhaupt Windows benutzen? Mit Linux hättest du dieses Problem nicht. Dr. Sommer schrieb: > Gibt es nicht für genau so etwas isochrone Transfers? Nein, USB MIDI benutzt Bulk-Transfers.
Andreas J. schrieb: > In meinem Hobby Project möchte ich USB Midi benutzen. Soweit ich mich > erinnere kann bei einem USB FS 12 MBit/s maximal 1 Transfer pro ms > gesendet werden Nö, das gilt nur für klassisches Midi wegen dessen mickriger Baudrate. Mitunter verwenden USB-Midi-Geräte das noch intern, weil man dann die restliche (MIDI-)Hardware nicht ändern muss. Außerdem verwechselt man das gerne mit USB HID, das nur 1 Transfer pro Frame (1ms bei Full Speed) kennt. Da USB Midi laut Spec auf Bulk Endpoints aufbaut, kannst Du aber eigentlich sehr viel mehr Transfers pro ms auslöen als nur einen. Sollte für die Lichterkette dicke reichen.
Karl schrieb: > Es klingt ein wenig wirr, zugegebenermaßen. Die Forderung nach hsusb > wegen der zu großen Latenz von fsusb ist ... Seltsam. > Soll der Controller Host oder device sein? Ich mag es nicht die > komplette Herangehensweise eines OT in Frage zu stellen, glaube aber, > dass dich hsusb nicht viel weiter bringen wird. Prinzipbedingt. Es wird ein Device. Ich definiere also nur mein Device und bin dann davon abhängig, wie der Windows USB-Stack / Host es bedient. Was USB theoretisch hergibt ist also mehr oder weniger belanglos. Das durch den HS Mode mehr Transfers möglich sind sollte soweit klar sein. Natürlich wird es auch mit einem FS Device irgendwie möglich sein. Wenn hier aber jemand ein schickes kleines Board mit USB HS aus dem Hut gezaubert hätte (den 8051 mal ausgeklammert), wäre das meine Wahl gewesen. Clemens L. schrieb: > Der Treiber kann auch mehrere Noten in ein Paket verpacken, und mehrere > Pakete pro Frame versenden/empfangen. Er muss es nur tun, was zumindest > bei älteren Windows-Versionen nicht der Fall ist. > > Roland hat deswegen einen eigenen Treiber für das selbe Protokoll > geschrieben, und nennt das ganze "FPT": Relevant für mich erstmal wie der Windows USB-Stack das standartmäßig handhabt, denn einen eigenen Gerätetreiber wollte ich nicht schreiben :) So wie es dort dargestellt ist, scheint der Normalfall eine Message pro Transfer zu sein. Jim M. schrieb: > Nö, das gilt nur für klassisches Midi wegen dessen mickriger Baudrate. > Mitunter verwenden USB-Midi-Geräte das noch intern, weil man dann die > restliche (MIDI-)Hardware nicht ändern muss. > > Außerdem verwechselt man das gerne mit USB HID, das nur 1 Transfer pro > Frame (1ms bei Full Speed) kennt. > > Da USB Midi laut Spec auf Bulk Endpoints aufbaut, kannst Du aber > eigentlich sehr viel mehr Transfers pro ms auslöen als nur einen. Ich muss zugeben, dass ich zuvor mit einem etwas merkwürdigem USB-Midi Device gearbeitet hatte ("Novation Dicer"). Dieses verwendet entgegen der Spec einen 1,5MBits Interrupt Transfer. Der sendet auch definitiv nur 1 Message pro Transfer (obwohl 2 in den zulässigen Payload passen würden) und das maximal alle 8ms. Dieses Device benötigt unter Windows übrigens trotzdem keinen Treiber, vermutlich gibt es für Low-Speed Devices eine eigene Regel. LS unterstützt ja nichtmals Bulk Transfers. Grundsätzlich ist der Interrupt Transfer eigentlich geeigneter für eine Echtzeit Anwendung. Ich würde sogar soweit gehen zu behaupten, dass der BULK Transfer für Musiker Anwendungen das ungeeignetste ist. Ich will daher in der Tat einmal versuchen auch für mein eigenes Device den Endpoint als Interrupt Transfer festzulegen, auch wenn die Spec etwas anderes sagt. Probieren geht über studieren :)
Du könntest einen www.microchip.com/wwwproducts/en/PIC32MZ0512EFE064 verwenden. Der hat High Speed USB Host/Device/OTG eingebaut, inkl PHY. Und mit 200 MHz ist er auch nicht der langsamste. fchk PS: Wenn Du ein komplettes Board haben willst: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM320104 Da ist eine größere Variante mit mehr Flash, RAM und Pins eingebaut.
Andreas J. schrieb: > So wie es dort dargestellt ist, scheint der Normalfall eine Message pro > Transfer zu sein. Wenn du mit Message ein Paket meinst, dann ist das falsch. In einem frame können so viele Pakete übertragen werden wie Platz ist. Oder ist eine Message eine Kommunikationseinheit deiner Anwendung? Andreas J. schrieb: > Das durch den HS Mode mehr Transfers möglich sind sollte soweit klar > sein. Falls der Treiber die Möglichkeiten der microframes ausnutzt sind es exakt acht Mal so viele. Wie gesagt sind die waveshare xcore Module welche der wenigen die überhaupt usbhs können zu einem akzeptablen Preis. Mittlerweile wäre s samv70 xplained noch verfügbar, allerdings Recht groß.
Karl schrieb: > In einem frame können so viele Pakete übertragen werden wie Platz ist. Aber nicht, wenn der Treiber wartet, bis das Paket übertragen wurde, bevor er das nächste sendet. Andreas J. schrieb: > Relevant für mich erstmal wie der Windows USB-Stack das standartmäßig > handhabt In Windows 10 sind die Treiber neu geschrieben worden. Kein Ahnung, ober dieser Aspekt verbessert wurde. > denn einen eigenen Gerätetreiber wollte ich nicht schreiben Dein Gerät könnte einfach behaupten, ein Roland UM-1G zu sein ...
Clemens L. schrieb: > Aber nicht, wenn der Treiber wartet, bis das Paket übertragen wurde, > bevor er das nächste sendet. Da hast du sicherlich Recht.
Hallo, wenn die Daten raus sollen, obwohl die Paketgröße nicht voll ausgenutzt wird, sendet das Device ein Zero-Length-Packet. Dann wartet auch kein Host, egal welches OS. HS für MIDI ist Kanonen auf Spatzen. Wahrscheinlich würde es LS tun. Am besten erstmal die USB Spezifikation lesen. VG Dennis
Teensy 3.6 wäre eventuell etwas. Der HS USB Port ist aber nur über eine Stiftleiste erreichbar, die in der Mitte des Boards liegt. Die aufgelötete USB Buchse ist mit einem FS USB Port verbunden. Der verwendete NXP K66 ist als BGA Variante verbaut, gibt aber auch 144 Pin LQFP Varianten. Teensy verwendet einen Bootloader der Closed Source ist. Diesen muss man nicht benutzen - aber beim Kauf bezahlt man dafür.
Dennis O. schrieb: > wenn die Daten raus sollen, obwohl die Paketgröße nicht voll ausgenutzt > wird, sendet das Device ein Zero-Length-Packet. Quatsch. Wenn die Paketlänge nicht genutzt wird ist der Transfer beendet. Nur wenn zufällig so viele Bytes gesendet werden wie in ein Paket passen folgt ein zlp um das Ende des Transfers anzuzeigen. Außerdem hat der OP ein ganz anderes Problem. >Dann wartet auch kein > Host, egal welches OS. HS für MIDI ist Kanonen auf >Spatzen. Das mag sein. Scheinbar hat der OP aber noch andere Zwänge. > Wahrscheinlich würde es LS tun. > Am besten erstmal die USB Spezifikation lesen. Was ein bescheuertes Totschlagargument. Versuch zu helfen oder lass es. Wenn du so geil bist wie du andeutest, dann könntest du dem OP sicher sofort helfen. Deine Aussagen von oben lassen aber eine andere Intention vermuten...
Andreas J. schrieb: > Ich steuere eine LED Lichterkette an und möchte schon so in etwa auf 60 > "FPS" kommen. Dazu werden aber um die 10-20 Transfers pro Frame benötigt > (die "Lightshow" wird von den Midi Events abgeleitet, die LED Farben > werden nicht einzeln über Midi übertragen). Wieviele RGB Lichtlein sind es denn? Nur so, DMX512 schafft 512 8bit Werte in 44Hz Updaterate und wurde oh Wunder für Lichtgedöns erfunden. Man muss auch nicht alle 512 Kanäle nutzen. USB-DMX-Hardware dazu gibt es auch selbstbaubar. Warum also MIDI?
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.