Wieso braucht man überhaupt einen Treiber für einen Virtual Com port?

Auch Windows wird mit einem generischen Treiber für CDCs geliefert, 
allerdings aus irgendeiner grenzwertigen Debilität heraus ohne eine 
passende *.inf-Datei, die zur Nutzung erforderlich ist.

USB-Seriell-Bridges wie die von FTDI, Prolific etc. aber sind keine 
CDCs, sondern nutzen proprietäre Protokolle und benötigen also 
individuelle Treiber. Bei manchen Linux-Distributionen sind auch solche 
Treiber im Lieferumfang enthalten, ob deswegen das OS "richtiger" ist?

Wie dem auch sei, für eigene Versuche mit USB ist es ratsam, eine der 
Standardgeräteklassen wie eben CDC zu verwenden.
Im Anhang ist ein Beispiel für eine *.inf-Datei nebst *.cat für eine 
USB-VID von Microchip. Wird auf die *.cat-Funktionalität (Signierung) 
verzichtet, kann die Datei leicht durch Ändern von VID und PID an eigene 
Controller angepasst werden.

Dank Dir!

Verstehe trotzdem nicht, wieso Windows einen CDC beim einstecken nicht 
automatisch Erkennt soe wie ein Mass Storage Device ja auch.

Gruß
Tom

Auch wenn sich das Device als CDC meldet, ist, um es unter Windows 
nutzen zu können, eine passende *.inf-Datei erforderlich. Das ist eines 
der Defizite von Windows, warum auch immer. Vermutlich haben die, die 
dahinterstecken, niemals die Möglichkeit vorhergesehen, CDC-Devices 
außerhalb von USB-Modems zu begegnen (die sowieso mit Treibern 
ausgeliefert werden).

Vielleicht sollte man das mal jemand denen in Redmond sagen...

Weiß einer von euch wie es beim Mac aussieht?

Gruß
Tom

Zwar habe ich einen und nutze den auch, aber ein CDC habe ich da noch 
nicht drangehängt. Ich vermute aber stark, daß das "out-of-the-box" 
funktionieren wird.

Thomas Burkhart schrieb:
> Sollte nicht ein OHCI-Treiber im OS verfügbar
> sein?

Das ist doch nur die unterste Schicht, der Zugriff auf den
angeschlossenen Bus.  Mit dem OHCI- oder EHCI-Treiber kannst du
erst einmal nur Pakete auf dem USB senden und empfangen.  Darüber
sitzen dann im Betriebssystem die Treiber, die geräteabhängig
die Einbindung ins System vornehmen, wobei diese wiederum unabhängig
vom zu Grunde liegenden USB-Controller sind.

Allerdings bietet Windows von Haus aus verdammt wenig in dieser
Richtung, man verlässt sich dort voll und ganz auf die Hersteller
der jeweiligen am USB angeschlossenen Geräte.  Insbesondere bietet
Windows keinen generischen USB-Treiber, über den man einfach nur an
die rohen Datenpakete der USB-Controller-Hardware herankommt (die
gängigen Unixe und Mac OS haben sowas).  Der einzige Treiber, der
bei Windows offensichtlich standardmäßig dabei ist und sich wirklich
jede Instanz der entsprechenden Geräteklasse krallt, ist ein HID-
Treiber (human interface device), eigentlich für Keyboard und Maus
gedacht.  Das führt dann zur absurden Situation, dass jeder, der
irgendein USB-Gerät baut und selbst keine Treiberinstallation
machen möchte, sein Gerät als HID auslegt -- egal, was das Gerät
tut.  Mit "human interface" hat das oft dann nichts zu tun, da
hängen dann Programmiergeräte für Microcontroller dran und sonstwas.

Jörg Wunsch schrieb:
> Allerdings bietet Windows von Haus aus verdammt wenig in dieser
> Richtung, man verlässt sich dort voll und ganz auf die Hersteller
> der jeweiligen am USB angeschlossenen Geräte.  Insbesondere bietet
> Windows keinen generischen USB-Treiber, über den man einfach nur an
> die rohen Datenpakete der USB-Controller-Hardware herankommt (die
> gängigen Unixe und Mac OS haben sowas).

Jein, mit WinUSB http://msdn.microsoft.com/en-us/library/ff540207.aspx 
geht sowas mittlerweile recht gut (unterstützt nur keine isochronen 
Transfers).