Hallo, kennt jemand eine Alternative zur Virtual COM Port Implementation mittels Communication Device Class? Mein Ziel ist es, zwei COM-Schnittstellen mit meinem Wunschmicrocontroller zu realisieren, das Problem ist, dass dieser maximal 3x IN und 3x OUT USB-End-Points (neben Endpoint 0) unterstützt. CDC setzt aber 2x IN und 1 x OUT pro VCP voraus. Das Ziel wäre also zusammengefasst eine VCP-Alternative zu der CDC-Implementation, welche keine OS-Treiberentwicklung fordert. Vielleicht hat ja jemand ne Idee? Ralf
Tja, Windows bringt nur den CDC Treiber mit, wenn du also keinen Eigenen Treiber schreiben willst, bleiben dir nur Treiber von anderen USB->RS232 Lösungen. Also: Mal Prolific, FTDI & co Chips ansehen, welcher davon mit den wenigsten Endpoints auskommt. Danach einen "Simulator" für so einen Chip für deinen µC schreiben. Testen ob der gewählte Treiber den Chip auch erkennt. Simulator auf zweite Function mit dem zweiten Comport erweitern. Wieder testen, ob der Treiber das noch schluckt. Wenn nicht, Goto 1. Wenn du alle verfügbaren Chips/Treiber durch hast, Pech gehabt. Einen USB-Hub Simulator wirst du wohl kaum noch zusätzlich auf deinen µC bekommen.
Hi Ernst, hm, die Idee ist gar nicht schlecht. Mal sehen, ob ich irgendwie rausbekomme, wieviele Endpoints diese Treiber verwenden... Danke. Ralf
Ralf wrote: > hm, die Idee ist gar nicht schlecht. Mal sehen, ob ich irgendwie > rausbekomme, wieviele Endpoints diese Treiber verwenden... Das geht unter Linux mit lsusb, z.B.
1 | # lsusb -v -d 0x04b4:0x5500 |
2 | |
3 | Bus 002 Device 067: ID 04b4:5500 Cypress Semiconductor Corp. HID->COM RS232 Adapter |
4 | Device Descriptor: |
5 | bLength 18 |
6 | bDescriptorType 1 |
7 | bcdUSB 1.00 |
8 | bDeviceClass 0 (Defined at Interface level) |
9 | bDeviceSubClass 0 |
10 | bDeviceProtocol 0 |
11 | bMaxPacketSize0 8 |
12 | idVendor 0x04b4 Cypress Semiconductor Corp. |
13 | idProduct 0x5500 HID->COM RS232 Adapter |
14 | bcdDevice 0.00 |
15 | iManufacturer 1 ? |
16 | iProduct 2 PS/2+USB Mouse |
17 | iSerial 0 |
18 | bNumConfigurations 1 |
19 | Configuration Descriptor: |
20 | bLength 9 |
21 | bDescriptorType 2 |
22 | wTotalLength 41 |
23 | bNumInterfaces 1 |
24 | bConfigurationValue 1 |
25 | iConfiguration 4 ? |
26 | bmAttributes 0x80 |
27 | (Bus Powered) |
28 | MaxPower 100mA |
29 | Interface Descriptor: |
30 | bLength 9 |
31 | bDescriptorType 4 |
32 | bInterfaceNumber 0 |
33 | bAlternateSetting 0 |
34 | bNumEndpoints 2 |
35 | bInterfaceClass 3 Human Interface Device |
36 | bInterfaceSubClass 0 No Subclass |
37 | bInterfaceProtocol 0 None |
38 | iInterface 0 |
39 | HID Device Descriptor: |
40 | bLength 9 |
41 | bDescriptorType 33 |
42 | bcdHID 1.00 |
43 | bCountryCode 0 Not supported |
44 | bNumDescriptors 1 |
45 | bDescriptorType 34 Report |
46 | wDescriptorLength 37 |
47 | Report Descriptors: |
48 | ** UNAVAILABLE ** |
49 | Endpoint Descriptor: |
50 | bLength 7 |
51 | bDescriptorType 5 |
52 | bEndpointAddress 0x81 EP 1 IN |
53 | bmAttributes 3 |
54 | Transfer Type Interrupt |
55 | Synch Type None |
56 | Usage Type Data |
57 | wMaxPacketSize 0x0008 1x 8 bytes |
58 | bInterval 2 |
59 | Endpoint Descriptor: |
60 | bLength 7 |
61 | bDescriptorType 5 |
62 | bEndpointAddress 0x02 EP 2 OUT |
63 | bmAttributes 3 |
64 | Transfer Type Interrupt |
65 | Synch Type None |
66 | Usage Type Data |
67 | wMaxPacketSize 0x0008 1x 8 bytes |
68 | bInterval 10 |
69 | Device Status: 0x0000 |
70 | (Bus Powered) |
=> Komisches Teil, meldet sich als HID, und hat einen IN und einen OUT Endpoint (zusätzlich zum Endpoint0, der ja immer gebraucht wird) Ausserdem hat das verfluchte Teil einen Wackelkontakt, ausgerechnet in dem eingegossenen Steckergehäuse…
Hi Ernst, > Das geht unter Linux mit lsusb, z.B. Muss gestehen, dass ich verwöhnter Windows-User bin, mich mit Linux zu beschäftigen, steht zwar in Planung, aber da leg ich mir neue Hardware zu und papp es dann auf den alten Rechner :) > => Komisches Teil, meldet sich als HID, und hat einen IN und einen OUT > Endpoint (zusätzlich zum Endpoint0, der ja immer gebraucht wird) Laut der Beschreibung, dass das gesamte Produkt eine Maus ist, würde ja HID (Human Interface Device) schon mal passen. Dass offenbar ein USB-UART-Wandler der Sache "übergeordnet" ist, wundert mich jetzt auch... > Ausserdem hat das verfluchte Teil einen Wackelkontakt, ausgerechnet in > dem eingegossenen Steckergehäuse… Sorry, jetzt musste ich schmunzeln... Du meinst direkt im USB-Stecker? Das ist doof. Kannst du nicht aufmachen und das Kabel auswechseln? Ralf
Mit USBView kannst du unter Windows die USB Deskriptoren anzeigen lassen. Wird mit dem WDK mitgeliefert, findet man aber auch auf der FTDI HP. Ansonsten könntest du von CDC auf HID umsatteln. Windows liefert hier ebenfalls einen Treiber mit.
> Mit USBView kannst du unter Windows die USB Deskriptoren anzeigen lassen. > Wird mit dem WDK mitgeliefert, findet man aber auch auf der FTDI HP. Okay, das guck ich mir mal an, danke... > Ansonsten könntest du von CDC auf HID umsatteln. Windows liefert hier > ebenfalls einen Treiber mit. Aber ich brauch doch n VCP, und den kann man mit HID nicht realisieren (oder zumindest kenne ich keinen Treiber, der das über HID implementiert). Ralf
So, hab jetzt mal mit USBView einen FT232 ausgelesen:
1 | Device Descriptor: |
2 | bcdUSB: 0x0110 |
3 | bDeviceClass: 0x00 |
4 | bDeviceSubClass: 0x00 |
5 | bDeviceProtocol: 0x00 |
6 | bMaxPacketSize0: 0x08 (8) |
7 | idVendor: 0x0403 (Future Technology Devices International Limited) |
8 | idProduct: 0x6001 |
9 | bcdDevice: 0x0400 |
10 | iManufacturer: 0x01 |
11 | 0x0409: "FTDI" |
12 | iProduct: 0x02 |
13 | 0x0409: "USB <-> Serial" |
14 | 0x0409: "USB <-> Serial" |
15 | iSerialNumber: 0x00 |
16 | bNumConfigurations: 0x01 |
17 | |
18 | ConnectionStatus: DeviceConnected |
19 | Current Config Value: 0x01 |
20 | Device Bus Speed: Full |
21 | Device Address: 0x01 |
22 | Open Pipes: 2 |
23 | |
24 | Endpoint Descriptor: |
25 | bEndpointAddress: 0x81 IN |
26 | Transfer Type: Bulk |
27 | wMaxPacketSize: 0x0040 (64) |
28 | bInterval: 0x00 |
29 | |
30 | Endpoint Descriptor: |
31 | bEndpointAddress: 0x02 OUT |
32 | Transfer Type: Bulk |
33 | wMaxPacketSize: 0x0040 (64) |
34 | bInterval: 0x00 |
35 | |
36 | Configuration Descriptor: |
37 | wTotalLength: 0x0020 |
38 | bNumInterfaces: 0x01 |
39 | bConfigurationValue: 0x01 |
40 | iConfiguration: 0x00 |
41 | bmAttributes: 0x80 (Bus Powered ) |
42 | MaxPower: 0x2D (90 Ma) |
43 | |
44 | Interface Descriptor: |
45 | bInterfaceNumber: 0x00 |
46 | bAlternateSetting: 0x00 |
47 | bNumEndpoints: 0x02 |
48 | bInterfaceClass: 0xFF |
49 | bInterfaceSubClass: 0xFF |
50 | bInterfaceProtocol: 0xFF |
51 | iInterface: 0x02 |
52 | 0x0409: "USB <-> Serial" |
53 | 0x0409: "USB <-> Serial" |
54 | |
55 | Endpoint Descriptor: |
56 | bEndpointAddress: 0x81 IN |
57 | Transfer Type: Bulk |
58 | wMaxPacketSize: 0x0040 (64) |
59 | bInterval: 0x00 |
60 | |
61 | Endpoint Descriptor: |
62 | bEndpointAddress: 0x02 OUT |
63 | Transfer Type: Bulk |
64 | wMaxPacketSize: 0x0040 (64) |
65 | bInterval: 0x00 |
Scheint tatsächlich so zu sein, dass nur zwei Endpunkte verwendet werden, obwohl ein CDC VCP m.W. zwei IN und einen OUT verwendet, der zweite IN ist soweit ich für die Signalisierung der Zustände bzw. Zustandsänderungen (RTS, usw.). Interessant... Ralf
Ralf wrote: > So, hab jetzt mal mit USBView einen FT232 ausgelesen: > Scheint tatsächlich so zu sein, dass nur zwei Endpunkte verwendet > werden, obwohl ein CDC VCP m.W. zwei IN und einen OUT verwendet, der > zweite IN ist soweit ich für die Signalisierung der Zustände bzw. > Zustandsänderungen (RTS, usw.). > Interessant... Das mag daran liegen, dass FTDI kein CDC macht, sondern ein eigenes Protokoll.
> Das mag daran liegen, dass FTDI kein CDC macht, sondern ein eigenes > Protokoll. Ja, das hab ich mir auch gedacht, jetzt muss ich mal versuchen, rauszufinden, wie man auf einfachstem Wege auf die Art einen VCP realisiert. Ich such mal nach "universellen" VCP-Treibern, welche quasi nur die Host-Seite implementieren und nur ein Interface für das Device bereitstellen, sodass man die Device-Steuerung selbst schreiben kann. Ich halt euch auf dem Laufenden... Ralf
Gibts da nicht dieses Com-To-Com oder com2com o.ä.? Stellt zwei Virtuelle Com-Ports zur Verfügung, die sozusagen mit einem virtuellen Null-Modem-Kabel gekoppelt sind. Ein Ende nimmst du für die Anwendung, das andere nimmt dein Userspace-Treiber zum Datenschaufeln?
> Ein Ende nimmst du für die Anwendung, das andere nimmt dein > Userspace-Treiber zum Datenschaufeln? Naja, das wär ne Notlösung :) Im Prinzip bräuchte ich eine COM-to-MyDevice Implementierung grins Bin noch am Suchen, aber wie gesagt, falls ich was brauchbares finde, stell ichs hier rein... Ralf
Also, mal ein Update zu meiner bisherigen Suche: Die einzige Möglichkeit, die mir am flexibelsten erscheint, ist einen VCP zu erzeugen, der aber erstmal nix mit USB am Hut hat, sondern über die Programmiersprache der Wahl erzeugt wird. Gekoppelt an den eigentlichen USB-fähigen Microcontroller wird eben über die programmierte Applikation. Die meisten µC-Hersteller geben neben VCP-Treibern ja meist auch DLLs für die Einbindung in eine Programmiersprache raus, um direkt mit den µC's kommunizieren zu können. Nochmal zur Erinnerung, ich brauche ja eine spezielle Lösung, da ich bei meinem Wunsch-µC nicht genug USB-Endpunkte für einen USB-VCP habe. Mit der Lösung über einen "allgemeinen" VCP-Treiber kann ich mir also das System passend hinbasteln. Es gibt viele Hersteller von solchen VCP-Treibern, ich denke, ich werde mal den von Eltima evaluieren: http://www.eltima.com/products/vspax/ Über das Timing-Verhalten lässt sich natürlich jetzt noch nix aussagen, ich halte euch auf dem Laufenden. Aber vielleicht hilft dieser Beitrag dem einen oder anderen. Ralf
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.