Hallo, 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? Was ist der unterschied zwischen den echten USB und VUSB bzw virtuel COM-Port? Was ist besser? VG Nicole
Alle drei sind "echtes" USB. V-USB implementiert USB notdürftig in Software, mit Bit-Banging (deshalb kann es nur Low Speed); normalerweise hat man dafür Hardware. Auf einer höheren Ebene kann man über USB viele verschiedene Protokolle sprechen. CDC (für COM-Ports) ist nur eines davon, und wird oft benutzt, weil der Treiber dafür heutzutage schon im Betriebssystem dabei ist. Es gibt auch andere Protokolle wie UAS (Festplatten, Sticks) und HID (Mäuse, Tastaturen), und wenn keins passt, kann man sich auch selbst was ausdenken (und muss dann einen eigenen Treiber schreiben).
:
Bearbeitet durch User
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.
c-hater schrieb: > 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. Das halte ich für eine an Telly Savalas' Haaren herbeigezerrte Verschwörungstheorie.
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? > Was ist der unterschied zwischen den echten USB und VUSB bzw virtuel > COM-Port? Von der Hardware aus betrachtet wird ein System das noch einen zusätzlichen Chip wie den FTDI braucht natürlich größer und teurer. Softwareimplementierungen wie VUSB sind natürlich etwas "eingeschränkt", verwendbar brauchen aber nur einen Chip. Bei MCs mit USB fallen mir spontan keine Nachteile ein. Nicole28 schrieb: > Was ist besser? Kommt drauf an ;-) Ich persönlich würde aber einen Controller mit integriertem USB verwenden.
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 mit acht mal so viel Daten (sogar etwas mehr wegen des Protokoll-Overheads). Low-Speed-Bulk würde die anderen Geräte am selben Bus größtenteils lahmlegen.
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...
Also ich kann mir beim besten Willen nicht vorstellen, dass V-USB irgend jemanden der an USB verdient nur im entferntesten juckt. Was hat VUSB überhaupt mit verdienen oder nicht zu tun?
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...
c-hater schrieb: > Mein Gott, bist du dumm, Scheint so :-( c-hater schrieb: > oder die (relativ) noch teureren zusätzlichen USB-Chips. Zumindest da muss ich dir zustimmen ;-)
>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 ;-) )
Wie ist das eigentlich mit CDC und neueren Windoof Versionen nach Win7? Braucht man da noch eine .inf Datei oder geht das inzwischen so problemlos wie HID, bzw wie bei Linux? Dass Kosten für die Vendor ID anfallen ist klar, aber bei höheren Stückzahlen müsste das im Vergleich zu den FTDI Preisen doch drin sein. Bin da aktuell nicht im Bilde. Vor Jahren waren es 2k€ oder so? Selber habe ich 3 kostenlose Sublizenzen von MCHP. Wenn ich mich richtig erinnere sollten da aber nicht mehr als je 10k Teile verkauft werden ;-) Softwarelösungen wie VUSB brauchen ja auch eine VID wenn die "legal" sein sollen, oder? Das "entsprechende USB-Zeugs" gabs oder gibt es inzwischen tatsächlich "fertig". Weiss ich natürlich wieder nur sicher von MCHP aber wird es vermutlich von den meisten MC Herstellern was geben.
:
Bearbeitet durch User
Volker S. schrieb: > Bin da aktuell nicht im Bilde. Vor Jahren waren es 2k€ oder so? Es waren wohl vor 10 Jahren 2k$. Jetzt scheinen es schon mindestens 5k zu sein. René K. schrieb: > http://www.usb.org/developers/vendor > Ich zitiere mal: "If you would like to purchase a vendor ID without > signing the logo license agreement, the administration fee for this > purchase is US$2,000."
:
Bearbeitet durch User
c-hater schrieb: > 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). Aber acht solche Low-Speed-Geräte würden nicht funktionieren. Ein Gerät, das genügend Power hat (und verbraucht), um Bulk-Daten zu verarbeiten, kann sich auch die Full-Speed-Hardware leisten. Das jemand auf die Idee kommen würde, so eine leistungsfähige Hardware dazu zu benutzen, jedes Bit einzeln anzufassen, ist damals niemand gekommen.
Volker S. schrieb: > Wie ist das eigentlich mit CDC und neueren Windoof Versionen nach Win7? Seit Windows 10(?) geht das auch ohne Extra-.inf. > Selber habe ich 3 kostenlose Sublizenzen von MCHP. So etwas bieter praktisch jeder Hersteller von USB-Chips an. (Und für Open Source gibt es kostenlose IDs von Openmoko oder pid.codes.) > Softwarelösungen wie VUSB brauchen ja auch eine VID wenn die "legal" > sein sollen, oder? https://github.com/obdev/v-usb/blob/master/usbdrv/USB-IDs-for-free.txt
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.