CDC Virtual Serial Port

[Dinosaur]

Hi Bret

I have investigated a board to use with MS-Dos that utilises CDC , a Virtual Serial Port on usb.

Can you tell me if this is currently supported on your drivers, and if so what are the settings needed ?

Regards

Edit: My understanding is that, a device driver will use usb as a serial port, that I can then open
within my code as a Com(n) port. Then by sending the char's that the board requires to this com port
I will be able to control and read/write this board.

[Bret]

There is no serial driver currently written, but you should be able to do what you want fairly easily (assuming the device complies with the CDC specification). You can download the CDC spec from http://www.usb.org/developers/devclass_docs.

For a "simple" CDC device, which I assume this is, you set up the port parameters (bps, parity, etc.) and control leads (DTR, RTS, etc.) with control requests, and send/receive the data via bulk or interrupt requests. I assume the vendor will provide you the information you need to understand the format of the data that will get sent back and forth across the virtual serial port.

One reason I haven't written a serial driver (besides not having the time) is that many of the popular serial devices are not CDC-compliant, and require vendor-specific drivers.

[Dinosaur]

Hi Bret

I now have the usb Bit Wacker board.
I will test it in Windows, but I thought I would post the Device & Descr information here first.
UsbDevic output.

Code: Select all

ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Host Index:  0  Host Type: UHCI  Bus Type: PCI   IRQ#: 10  Root Hub Ports: 2
Vendor: 1106h = VIA Technologies Inc                       Product: 3038h
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
                DEVICES                                   INTERFACES           
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ  ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
                           L                C  I A                O           
ADRS                       o         P      o  n l                w           
ÍÍÍÍ   (hex)               S         o BUS  n  t t                n           
Test VEND PROD     Sub Pro p USB HUB r POWR f  f I                e     Sub Pro
RWak  ID   ID  Cls Cls col d VER ADR t (mA) g  c n  DESCRIPTION   d Cls Cls col
ÍÍÍÍ ÍÍÍÍ ÍÍÍÍ ÍÍÍ ÍÍÍ ÍÍÍ Í ÍÍÍ ÍÍÍ Í ÍÍÍÍ Í  Í Í ÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Í ÍÍÍ ÍÍÍ ÍÍÍ
  1  1106 3038   9   0   0 . 1.0 ... . s  0 1  0 0*Root Hub       Y   9   0   0
     VIA Technologies Inc                   
ÄÄÄÄ ÄÄÄÄ ÄÄÄÄ ÄÄÄ ÄÄÄ ÄÄÄ Ä ÄÄÄ ÄÄÄ Ä ÄÄÄÄ Ä  Ä Ä ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Ä ÄÄÄ ÄÄÄ ÄÄÄ
  2  04D8 000A   2   0   0 . 2.0   1 1 s100 1  0 0*Modem V.25ter  .   2   2   1
     Microchip Technology Inc                  1 0*Comm Device?   .  10   0   0



Usbuhcil Descr output

Code: Select all

USBUHCIL 0.11, (C) 2007-2009, Bret E. Johnson.
DOS Driver for a Universal HCI compatible USB Host Controller.
  LITE version (maximum 16 Devices, no Isochronous Transactions).

DEVICE ADDRESS:   2
CONFIGURATION:    1

        DEVICE DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 12h  18
Descr Type:                   01h  Device
USB Release:                0200h  2.00
Device Class:                 02h  Communications
Device SubClass:              00h  None
Device Protocol:              00h  None
Max Packet Size EP0:          08h  8
Vendor ID:                  04D8h  Microchip Technology Inc               
Product ID:                 000Ah  10
Device Release:             0001h  0.01
Manufacturer String:          01h  "Microchip Technology Inc."
Product String:               02h  "CDC RS-232 Emulation Demo"
Serial # String:              00h  None
# of Configs:                 01h  1

    CONFIGURATION DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   02h  Configuration
Descr Total Length:         0043h  67
# of Interfaces:              02h  2
Configuration Value:          01h  1
Configuration String:         00h  None
Attributes:                   C0h  Valid Historical Attribute 80h
                                   Self Powered
                                   No Remote Wakeup
                                   Not Battery Powered
Current Draw / 2:             32h  50 (100 mA)

      INTERFACE DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   04h  Interface
Interface Number:             00h  0
Alternate Setting:            00h  0
# of End Points:              01h  1
Interface Class:              02h  Communications Control
Interface SubClass:           02h  Abstract Control (modem)
Interface Protocol:           01h  AT commands V.25ter
Interface String:             00h  None

       UNKNOWN DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 05h  5
Descr Type:                   24h  Unknown!
__Unknown Data:               00h  0
__Unknown Data:               10h  16
__Unknown Data:               01h  1

       UNKNOWN DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 04h  4
Descr Type:                   24h  Unknown!
__Unknown Data:               02h  2
__Unknown Data:               02h  2

       UNKNOWN DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 05h  5
Descr Type:                   24h  Unknown!
__Unknown Data:               06h  6
__Unknown Data:               00h  0
__Unknown Data:               01h  1

       UNKNOWN DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 05h  5
Descr Type:                   24h  Unknown!
__Unknown Data:               01h  1
__Unknown Data:               00h  0
__Unknown Data:               01h  1

      END POINT DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 07h  7
Descr Type:                   05h  EndPoint
End Point Number:             82h  EndPoint = 2  Direction = In
Attributes:                   03h  Interrupt NonSynchronous Data
Max Packet Size:            0008h  8
Max Poll Interval:            02h  2

      INTERFACE DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 09h  9
Descr Type:                   04h  Interface
Interface Number:             01h  1
Alternate Setting:            00h  0
# of End Points:              02h  2
Interface Class:              0Ah  Communications Data
Interface SubClass:           00h  None
Interface Protocol:           00h  None
Interface String:             00h  None

      END POINT DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 07h  7
Descr Type:                   05h  EndPoint
End Point Number:             03h  EndPoint = 3  Direction = Out
Attributes:                   02h  Bulk NonSynchronous Data
Max Packet Size:            0040h  64
Max Poll Interval:            00h  0

      END POINT DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 07h  7
Descr Type:                   05h  EndPoint
End Point Number:             83h  EndPoint = 3  Direction = In
Attributes:                   02h  Bulk NonSynchronous Data
Max Packet Size:            0040h  64
Max Poll Interval:            00h  0




Regards

Edit: Bret in the log file I sent you, on Sequence 24 and 35 the Transmitted char "V" appears.
And the reply is in Sequence 36, finished by an "OK" cr/lf

[Bret]

It looks like this is set up as a modem that responds to the standard Hayes AT-command set, rather than just a straight serial port.

The unknown descriptors are CDC-class-specific (described in the spec), so we'll need to look those up to see what they mean.

[Bret]

Here is the decoding of the Unknown Descriptors (derived from the CDC Spec):

Code: Select all

     CDC HEADER DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 05h  5
Descr Type:                   24h  CDC Interface
Descr SubType:                00h  Header
CDC Version:                0110h  1.10

CDC ABSTRACT CONTROL DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 04h  4
Descr Type:                   24h  CDC Interface
Descr SubType:                02h  Abstract Control Management
Supported Requests:           02h  NO:  Get/Set/Clear CommFtr
                                   YES: Get/Set LineCode, SetCtlLineState,   SerialState
                                   NO:  SendBreak
                                   NO:  NetworkConnection

      CDC UNION DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 05h  5
Descr Type:                   24h  CDC Interface
Descr SubType:                06h  Union
Master Interface Number:      00h  Interface #0
Slave Interface Number:       01h  Interface #1

CDC CALL MANAGEMENT DESCRIPTOR
ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
Descr Length:                 05h  5
Descr Type:                   24h  CDC Interface
Descr SubType:                01h  Call Management
Capabilities:                 00h  Call Management = Class Interface Only
                                   Does NOT handle Call Management Itself
Call Mgmt Data Intf #:        01h  Interface #1

I haven't reviewed the Snoop details yet.

Based on my interpretation of this data compared to the CDC spec, though, this is a "virtual modem" that responds to Hayes AT commands. However, instead of going into command mode with a "+++" like you usually do with a modem, this is like a "special" modem that is dedicated (not dial-up), and has a set of lines dedicated to the AT commands separate from the normal data lines. The AT commands are sent to the device using a USB control request (Send_Encapsulated_Command) and responded to with a Get_Encapsulated_Response USB control request. In your particular case, I'm not sure why you would need to send any AT commands, except maybe an "ATD" to connect and an "ATH" to disconnect. I suspect you may be able to control everything with the virtual DTR & RTS leads and not even need to mess with AT commands at all.

You will control and monitor the virtual UART leads, and set the port speed, parity, etc. with USB control requests (Set_Line_Coding, Get_Line_Coding, Set_Control_Line_State, and Serial_State). Since this is not a real modem or even a real serial port that connects to a remote device, I'm not sure why it should matter what those things are set to, other than maybe DTR & RTS.

The data that gets sent across the "real" data lines (EndPoints 3 in your case) goes to the "virtual device" at the other end of the "virtual modem connection". That is where you are going to get your data from, using some device-specific commands. For example, the "V" you sent must be short for "Version", which is why it responded like it did. You will send data down the data lines with USB bulk requests, or could also do it with periodic interrupt requests if you wanted the polling to be handled "automatically".

The one thing I'm not sure of is what EndPoint 2 (associated Interface 0 and the AT commands) is for. It is a periodic interrupt end point, which returns 8 bytes of data, and needs to be polled every 2 milliseconds. But I have no idea what kind of data would be delivered from the Device. At least from a cursory reading of the CDC spec, I don't see anything related to that. I should point out that many USB mass storage devices (flash drives) also have an "extraneous" interrupt end point, which doesn't appear to be used for anything (at least none of the USB developers seems to know what it's for). So, it's possible that the interrupt endpoint doesn't really do anything at all, but is just there because interface 0 (the "AT command interface", which actually only uses control requests to endpoint 0) has to have at least one endpoint to be considered valid interface.

Again, this is my understanding based on what the CDC spec says. I could be completely wrong about a bunch of this.

[Dinosaur]

Hi Bret

Having been away from the usb program for weeks now, I have to get back into it,
and it is taking a little bit of time.
In parallel to this, I am working out how to compile applications to put into this board
and also the updating of firmware.
The more I understand about this chip and board, the easier it will be to implement the
interface.

There appears to be a few users that have developed apps for this board, including a "Basic" like
programming interface.(for Windows)

Will keep you updated on my progress.

Regards