USB VUSB Viruel COM Port

Nicole28 schrieb:

> es gibt Geräte mit einem USB Anschluss die aber in Wirklichkeit einen
> Virtuellen COM-Port machen wie z.B. mit dem FDTI Chip.
>
> und dann gibt es Geräte die einen echten USB Erkennung haben.
>
> Warum ist das so?

Weil die meisten µC zwar einen seriellen Port haben (oder sehr leicht in 
Software emulieren können), aber nur vergleichweise wenige einen 
USB-Anschluss. Das liegt einfach daran, dass USB sehr viel aufwendiger 
ist als ein einfacher serieller Anschluss, sowohl was die Hardware 
betrifft als auch die Software. Vor allem für kleinere µC ist das ein 
Problem.

> Was ist der unterschied zwischen den echten USB und VUSB bzw virtuel
> COM-Port?

Da gibt es eigentlich keinen. Auch "echtes" USB benutzt letztlich einen 
virtuellen COM-Port, jedenfalls USB-CDC. Es gibt aber auch noch andere 
Geräteklassen bei USB, aber die sind eben nicht für den Austausch von 
Datenströmen gedacht, sondern zu anderen Zwecken. Aber sie lassen sich 
notfalls auch zum Austausch von Datenströmen missbrauchen.

Besonders häufig wird USB-HID missbraucht. Das ist OK, solange die 
auszutauschenden Datenmengen gering sind und in die Beschränkungen 
passen, die der zugrunde liegende "Interrupt-Transfer" ihnen auferlegt.

Für größere Datenmengen braucht man aber andere Transfertypen, z.B. den 
"Bulk-Transfer", den halt auch USB-CDC benutzt. Das Blöde ist halt nur: 
Bulk-Transfers sind nicht allen Geräten erlaubt. Sie müssen mindestens 
mit Fullspeed (12Mbit/s) kommunizieren können, Lowspeed-Geräte 
(1,5MBit/s) dürfen ihn hingegen nicht verwenden. Das sperrt sie leider 
auch von der Verwendung von USB-CDC aus, denn dafür sind halt 
Bulk-Transfers vorgeschrieben.

Diese Beschränkung ist mehr oder weniger künstlich. Früher(tm) haben 
sich die Betriebssysteme nicht darum gekümmert und so war es möglich, 
auch mit Lowspeed-Geräten USB-CDC zu implementieren. Aber mit der 
massenhaften verfügbarkeit dieser Möglichkeit (durch V-USB) sahen die 
Leute, die an USB verdienen wollen, ihre Felle wegschwimmen und übten 
über die Standardisierungsorganisation Druck auf die 
Betriebssystemanbieter aus, diese künstliche Beschränkung auch praktisch 
zu erzwingen.

Microsoft tut das ganz rigeros, solche Geräte funktionieren mit 
aktuellen Windows-Versionen einfach nicht. Bei Linux hat man sich einen 
anderen Trick einfallen lassen, hier werden die Bulk-Endpoints solcher 
Geräte einfach in Interrupt-Endpoints verwandelt. Damit funktionieren 
sie zwar wenigstens irgendwie, aber weit langsamer als sie funktionieren 
könnten.

Clemens L. schrieb:

> c-hater schrieb:
>> Diese Beschränkung ist mehr oder weniger künstlich.
>
> Nein; Low-Speed-Pakete sind acht mal langsamer als Full-Speed-Pakete,
> und blockieren deshalb den Bus so lange wie Full-Speed-Pakete

Natürlich, da hast du vollkommen Recht.

Nur: Das wäre nicht wirklich ein Problem. Sie belegen den Bus längst 
nicht lange genug, als dass die Busfunktionalität insgesamt dadurch 
gefährdet wäre. Alles, was lt. Standard zwingend über den Bus muss, kann 
über den Bus. Natürlich steht den restlichen Endgeräten weniger 
Bandbreite zur Verfügung.

Das ist aber in einem hierarchischen Bussystem wie USB der NORMALFALL.

Deine eigene Ansage zeigt das doch bereits: Wenn man acht 
Fullspeed-Geräte an den Bus hängt, ist seine Belastung nämlich ganz 
genauso hoch und er muss damit ebenfalls klarkommen (und tut das auch 
problemlos).

Schlimmstenfalls (bei saumies implementierten Hostcontrollertreibern) 
könnte die Erkennung von potentiellen Problemen für isochrone Transfers 
scheitern, d.h.: es könnte u.U. ein Gerät am Bus akzeptiert werden, was 
nicht hinreichend schnell bedient werden kann. Das Gerät würde dann 
nicht funktionieren.

Der einzige Unterschied zu dem Szenario mit 8 Fullspeed-Geräten wäre 
dann: Hier würde das Gerät mit den isochronen Transfers und für die 
Busbelegung zu hohen Bandbreiten erst garnicht akzeptiert werden. 
Effektiv (für den Anwender) ändert sich dadurch aber rein *garnix*: Der 
Endeffekt ist nämlich übereinstimmend: Das Gerät funktioniert nicht.

So sieht das aus. Und wenn der Hostcontrollertreiebr halt nicht saumies 
implementiert ist, berechnet er Bulk-Bandbreite auch für LowSpeed 
richtig und es entfällt auch noch dieser kleine Unterschied zwischen dem 
erlaubten und dem verbotenen Szenario.

Wenn das keine künstliche Limitierung ist, was denn sonst?

Rufus Τ. F. schrieb:

> Das halte ich für eine an Telly Savalas' Haaren herbeigezerrte
> Verschwörungstheorie.

Hmm. Na klar ist das irgendwie eine Art Verschwörungstheorie, denn für 
den eigentlichen Vorgang der Einflussnahme habe ich natürlich keinen 
sachlichen Beweis.

Aber: Hast du eine bessere Theorie, die die dargelegten beweisbaren 
Fakten (insbesondere unter Berücksichtigung des Zeitfaktors) plausibel 
erklärt? Dann würde ich sie gerne lesen.

Oder willst du gar die dargestellten Fakten abstreiten? Dann aber bitte 
konkret werden. Alles andere wäre so unseriös wie 
Verschwörungstheorien...

Volker S. schrieb:

> Was hat VUSB überhaupt mit verdienen oder nicht zu tun?

Mein Gott, bist du dumm, wenn du dir nichtmal das allein zusammenreimen 
kannst.

Wenn ich irgendwas mit V-USB implementieren kann, brauche ich nicht die 
teureren Chips mit integrierter USB-Hardware kaufen oder die (relativ) 
noch teureren zusätzlichen USB-Chips.

Das kann den Herstellern der genannten Chips natürlich nicht gefallen, 
denn hier kommt das "verdienen" in's Spiel: sie würden dadurch einfach 
weniger verdienen. Und sie sind nachweislich Mitglieder im (inzwischen 
ziemlich elitären) USB-Standardisierungsclub...

>und dann gibt es Geräte die einen echten USB Erkennung haben.
Was auch immer eine "echte USB Erkennung sein soll" ;-)

>Kommt drauf an ;-) Ich persönlich würde aber einen Controller mit
>integriertem USB verwenden.

Kann man machen, viel Spass dabei, den eigenen Treiber für's Windoof zu 
schreiben und signieren zu lassen. Außerdem kannst Du Dir dann auch 
gleich für ein paar Euro bei der USB.org eine Vendor ID rauslassen ;-)

Die FTDI-Teile haben gegenüber den "echten USB Ports" z.B. von uC
den VOrteil, dass man ein Interface über USB in den PC hat und die 
Treiber von FTDI fertig sind und signiert. Dann meckert Windows nicht 
wegen fehlender Signierung rum. Hat man dann noch eine Anbindung an eine 
einfache "serielle Schnittstelle" (COM-Port) in der PC-Software, dann 
mus man sich mit dem USB-Subsystem etc. pp nich rumschlagen, sondern 
kann Standard-Code verwenden. Vom FTDI zum uC kann man sich dann 
entweder eine FIFO oder eine UART-Schnittstelle wünschen (je nach IC).

Nimmt man den USB-Port eines uC (ASICs man aussen vor) direkt, dann
muss man sich von der USB.org eine Vendor ID ziehen und prinzipiell auch 
eine (signierte?) Treiber-Infodatei (INF) fuer Windows organisieren.
Zusätzlich muss man das entsprechende USB-Device-Zeugs implementieren.

Teilweise gibt es das fertig, einige uC-Hersteller haben auch 
"Demo"-Code für CDC und andre USB Device-Klassen. Deren PID/VID "sollte" 
man aber nicht verwenden. ("Hobbybastler / Privatpersonen" könne das, 
Firmen sollten da nicht run ;-) )