STM32f4 USB HS onboard support?

[Philipp_M (Gast)]

Hallo,

Ich beschäftige mich derzeit mit der USB Schnittstelle an meinem STM32f4 
Evalboard von Waveshare.

Mein Ziel ist es derzeitig eine MIDI-USB Schnittstelle mit sehr 
niedriger Latenz zu schaffen.
Leider ist bei Fullspeed Geräten eine Latenz von 1ms vorgeschrieben.

Highspeed Geräte sind hier wesentlich schneller, und schaffen 0.125ms.
(Siehe auch hier: 
http://en.wikipedia.org/wiki/Universal_Serial_Bus#Latency)

Nun hab ich ein wenig in den Datenblättern von dem MCU geschaut und 
folgendes gefunden:

The STM32F405xx and STM32F407xx devices embed a USB OTG high-speed (up to
480 Mb/s) device/host/OTG peripheral. The USB OTG HS supports both full-speed and
high-speed operations. It integrates the transceivers for full-speed operation (12 MB/s) and
features a UTMI low-pin interface (ULPI) for high-speed operation (480 MB/s). When using
the USB OTG HS in HS mode, an external PHY device connected to the ULPI is required.

The USB OTG HS peripheral is compliant with the USB 2.0 specification and with the OTG
1.0 specification. It has software-configurable endpoint setting and supports
suspend/resume. The USB OTG full-speed controller requires a dedicated 48 MHz clock
that is generated by a PLL connected to the HSE oscillator.
The major features are:
2.2.31
● Combined Rx and Tx FIFO size of 1 Kbit × 35 with dynamic FIFO sizing
● Supports the session request protocol (SRP) and host negotiation protocol (HNP)
● 6 bidirectional endpoints
● 12 host channels with periodic OUT support
● Internal FS OTG PHY support
● External HS or HS OTG operation supporting ULPI in SDR mode. The OTG PHY is
   connected to the microcontroller ULPI port through 12 signals. It can be clocked using
  the 60 MHz output.
● Internal USB DMA
● HNP/SNP/IP inside (no need for any external resistor)
● for OTG/Host modes, a power switch is needed in case bus-powered devices are
   connected

Dort wird ja so fern mich meine Englischkenntisse oder sonstiges nicht 
täuschen davon geredet, das Highspeed mit der Geschwindigkeit von 
Fullspeed unterstützt wird, oder?

Könnte ich also davon ausgehen, obige Latenz zu erreichen, ohne die ULPI 
Schnittstelle nutzen zu müssen?

Denn große Datenraten brauche ich nicht...

Oder hab ich das falsch verstanden, und es muss schon auf der physischen 
Seite 480Mbits unterstützen(was die Pins vom MCU natürlich nicht 
können)?


Gruß

Philipp

[Martin K. (martinko)]

Hi,

Wenn der HS USB im FS Modus betrieben wird, dann macht der auch nur FS 
;-)

Gruß Martin

[abc (Gast)]

HS ist High speed, läuft auf anderen pegeln als FS / LS daher vermutlich 
auch der externe PHY (was der braucht so was wirklich?)

FS und LS läuft über den internen PHY.

Es unterscheiden sich somit nicht nur die Geschwindigkeit, sondern auch 
die Pegel, als auch die Paektgrössen, und noch einiges mehr.


und was nutzt die MIDI classe für endpoints (Bulk  Interrupt  ... )? 
davon ist die latency überhaupt erst mal abhängig.

[Norbert (Gast)]

Philipp_M schrieb:
> Mein Ziel ist es derzeitig eine MIDI-USB Schnittstelle mit sehr
> niedriger Latenz zu schaffen.
> Leider ist bei Fullspeed Geräten eine Latenz von 1ms vorgeschrieben.
>
> Highspeed Geräte sind hier wesentlich schneller, und schaffen 0.125ms.
> (Siehe auch hier:
> http://en.wikipedia.org/wiki/Universal_Serial_Bus#Latency)

Hmmm, ist es nicht so, das im statistischen Mittel die Wartezeit auf's 
Host Polling 500µs (mit einem Jitter +/- 500µs) beträgt?

Ein Byte über MIDI übertragen braucht ja wohl 320µs.

Bei einem MIDI-USB Konverter macht das im 'best case' 320µs, im Mittel 
820µs, im 'worst case' 1,23ms plus ein paar µs für die USB Übertragung 
an Gesamtverzögerung.

Ohne trollen zu wollen, kann das ein menschliches Ohr wahrnehmen?

PS. Die größte Verzögerung wird man sich wohl im OS einfangen!

[Philipp_M (Gast)]

abc schrieb:
> und was nutzt die MIDI classe für endpoints (Bulk  Interrupt  ... )?
> davon ist die latency überhaupt erst mal abhängig.

Ich denke, dass es auf Interrupt-Transfer hinausläuft, da das genau in 
das Anwendungsprofil von MIDI passt.
Allgemein bin ich da relativ frei, da ich auch vor habe mal einen 
Treiber für sowas zu programmieren(zu Lernzwecken, bevor hier die 
Wirtschaftlichkeitsdiskussion auftaucht ;) )

Aber ich denke auch die built-in Treiber laufen über Interrupt.

Norbert schrieb:
> Hmmm, ist es nicht so, das im statistischen Mittel die Wartezeit auf's
> Host Polling 500µs (mit einem Jitter +/- 500µs) beträgt?

Mir geht es aber um die Worst-Case Laufzeit. Und die ist wenn ich mich 
nicht irre bei 1ms.

Norbert schrieb:
> Ein Byte über MIDI übertragen braucht ja wohl 320µs.

Ja deswegen möchte ich weg von DIN und auf eine reine USB-Lösung setzen.
Denn es bleibt nicht bei einem Byte bei einer Note, es kommen noch 
mindestens 2 hinzu. Und wenn noch andere Informationen übertragen werden 
sollen, die für die Note entscheidend sein können(CC z.B.), kann es 
durchaus mal 2-3ms dauern, bis die komplette Information da ist.
Wenn man das Szenario weiterverfolgt, und mehrere Noten gleichzeitig 
ausgeben möchte, kann es letztendlich bei ca. 10ms landen, und das 
sollte auch für einen Musiklaien hörbar sein.

USB hat bei der rohen Übertragungsleistung keine Probleme, dort gehen 
die paar Bytes innerhalb Bruchteile einer Millisekunde durch die 
Leitung.

Norbert schrieb:
> Ohne trollen zu wollen, kann das ein menschliches Ohr wahrnehmen?
>
> PS. Die größte Verzögerung wird man sich wohl im OS einfangen!

Ich gebe dir recht, dass man diese Unterschiede nicht hören kann, aber 
man muss es als Zusatz sehen, also, dass die Zeit auf die endgültige 
Latenz addiert wird.

Bezüglich OS-Latenz auch dort hast du im Groben recht. Ich konnte 
allerdings unter Realtime-Linux eine OS-Latenz von unter einer 
Millisekunde
erreichen. Bei Windows über VSTis hab ich leider trotzdem ca. 5ms 
Latenz.

Achja um meine subjektive Meinung/Erfahrung noch dazu zu bringen: Ich 
kann einen guten Unterschied zwischen 10ms und 4ms hören. Und wenn man 
die 4ms als Referenz nimmt erscheint einem die 1ms Latenz von (FS/LS)USB 
relativ groß. Aber das ist alles eine sehr subjektive Sache. Es gibt 
Menschen denen macht es nichts aus ob sie jetzt 5ms oder 15ms Latenz 
haben.
Da hat man diesbezüglich als Drummer Nachteile...

Achja die MIDI-USB Verbindung soll direkt vom "Klangerzeuger" 
angesteuert werden. Im konkreten Fall wird es eine Piezo-drum-Trigger to 
MIDI Lösung.
Es wird daher noche ein wenig Zeit benötigt(ca. 2ms) um die Piezos 
ordentlich auszuwerten.


Um jetzt noch mal auf's eigentliche Thema zurückzukommen.
So wie ich es den Posts entnehmen konnte, ist alleine die "physische" 
Verbindung, bzw. das Protokoll ein Stück anders, so dass es nicht 
"onboard" klappt, und ich auf ULPI zurückgreifen muss oder?


Gruß
Philipp

[Chris (Gast)]

Dann übertrag nicht 1 Byte auf einmal sondern gleich 64 Bytes oder was
der Buffer hergibt, und auch wenn du da noch Timing hinzufügen musst,
du hast dann mindestens die 10fache Übertragungsrate.

[Philipp_M (Gast)]

Naja ich übertrage soviel, wie gerade da ist.
Das ich einen FIFO-Buffer davor schalte ist klar...

Es soll ja eine Echtzeitanwendung sein, daher wenn ich auf's Pad schlage 
soll es so schnell wie möglich übertragen werden...

Meinst du, dass ich einen konstanten Datenstrom errichte, der nur 
dummy-bytes überträgt, und diese dann per Treiber verworfen werden, und 
ab und zu die relevanten bytes kommen?
So wäre es wahrscheinlich möglich, aber eine ziemlich "dirty" Lösung...

Gruß
Philipp