VendorID und ProductID

[Hans M. (anno)]

Hallo zusammen,

ich verusche gerade einen USB Virtual COM Port Gerät zu programmieren.

Dazu habe ich mir von Atmel für den 90USB162 controller auf der atmel 
homepage eine fertiges projekt heruntergeladen.

Jetzt waren da aber die Standard-ID's von Atmel dabei für die USB 
Geräteerkennung.

Also

#define VENDOR_ID             0x03EB // Atmel vendor ID = 03EBh
#define PRODUCT_ID            0x2018

Jetzt meine Frage, ob es von Microsoft standardmäßig Vendor und Product 
ID's gibt, die mit der Systemdatei "usber.sys" zusammenarbeiten um keine 
inf-Datei für die Treiberkonfiguration mehr zu benötgen.

Man soll also einfach das USB-Gerät anstecken können und den Treiber 
automatisch von XP suchen lassen. fertig.

PS:

Die usber.sys wird standardmäßig für die Kommunikation von so einem 
Gerät verwendet.

gruß anno

Vielen Dank im Voraus.

[Εrnst B. (ernst)]

Kannst ja mal die Registry/Die mitgelieferten .INFs durchsuchen, ob MS 
da bereits VID/PID Paare vorgegeben hat.

Viel bringen wird dir das aber nicht, verkaufen/sonstwie vertreiben 
solltest du das Gerät mit geklautem VID/PID Paar eh nicht, und für den 
Eigenbedarf ist ein Doppelklick auf ein INF-File pro Rechner doch kein 
Aufwand...

[Timmo H. (masterfx)]

Nimm doch die vom USBProg. 
http://www.embedded-projects.net/index.php?page_id=160
Einfach die Inf-Datei angucken

[Εrnst B. (ernst)]

Timmo H. wrote:
> Nimm doch die vom USBProg.

Das bringt ihm doch auch nix. Dann müsste er ja die USBProg-INF-Datei 
installieren.

Er will ja das bei einem jungfräulichen Windows ohne Installation sein 
Gerät sofort dem usbser-Treiber zugewiesen wird.
Das wiederum geht nur, wenn das Windows bereits eine entsprechende 
INF-Datei installiert hat.
Wenn es da wirklich was passendes gibt, hat er zwei Folgeprobleme:
1) Gehört der Treiber höchstwahrscheinlich zu einem USB-Modem, und sein 
Gerät wird sofort nach dem Einstöpseln mit AT-Kommandos zugespammt.
2) Hat das Gerät, dessen VID/PID-Kennung er geklaut hat, wohl einen 
gewissen Bekanntheits- und Verbreitungsgrad, sonst hätte Microsoft den 
Treiber sicher nicht mit auf die Installations-CD gepackt. Konflikte 
hier sind also recht wahrscheinlich.

[Christian R. (supachris)]

Hm...war das bei Win nicht so, dass man keinen Treiber braucht, wenn man 
eine der Standard-USB-Klassen benutzt, wie z.B. Massenspeicher oder eben 
SerialPort? Bei Massenspeichern klappt das ja auch, und da sind nicht 
alle VID/PID im Windows.

[Εrnst B. (ernst)]

Klar, bei Storage und HID geht das.
Für Serial Port gibts leider keine eigene Klasse, nur CDC für 
"Communication Devices", z.B. Ethernet und Modems.
Der "usbser" Treiber für Modem-CDC stellt zwar auf OS-Seite einen 
COM-Port zur Verfügung, aber halt keinen "Vollständigen", z.B. keine 
Baudrateneinstellung, Flow-Control etc, die ein USB-Modem ja auch nicht 
braucht.
Aus dem Grund haben die FTD/Prolific/etc USB->RS232 Wandler auch alle 
eigene Treiber...
Zur Frage zurück, Windows lädt aus unerfindlichen Gründen den 
usbser-Treiber nicht bei erkannter Geräteklasse, es braucht immer die 
INF-Datei.
Und unter Vista gehen diese Selbstbau-CDC-Lösungen (obdev.at usw) 
garnicht mehr, wg. der Low-Speed-Device <=> Bulk Endpoint Falle...

[Timmo H. (masterfx)]

Unter Vista gibts eigentlich eh keine Probleme, da wird online auf die 
Treiberdatenbank zurückgegriffen. Als ich mein FTDI USB->RS232 
angeschlossen habe hat er innerhalb weniger Sekunden den Treiber 
runtergeladen und installiert.

[Hans M. (anno)]

Danke mal an alle für die Antworten.

Diese haben mir doch schon weiter geholfen.

Wäre es aber mit dem "usber" treiber möglich, dass der usb->rs232 
wandler nicht neu installiert werden muss, wenn ich ihn in einen anderen 
USB-Slot rienstecke?

gruß anno

[Christian R. (supachris)]

Bei mir kann ich alle FTDIs an beliebigen Ports betreiben, ohne dass 
Windows (XP) nochmal den Treiber haben will. XP will nur beim 
allerersten Mal den Treiber.