Hi, I have been wrestling with Microsoft USBSER.SYS as my host driver for an MDK-PRO based Atmel project.
We are using the USB CDC ACM middleware from Keil. (4.73 source)
I have determined a few interesting points and would like to see if anyone else concurs.
1) The slowest USBSER.SYS polls the INTERRUPT endpoint is once every 32ms to get modem state changes. If you indicate a slower polling rate than 32ms, it will be ignored and 32ms will be used. Keil USB middleware does not write to the INTERRUPT IN endpoint useless there is a state change on the control lines. In the Keil usb_config.c, when you are entering polling interval, it is in FRAMES for low/full speed (i.e. ms), and micro frames (i.e. 125microsecond increments) These is a typo in the 4.74 middleware usb_config.c, as they hint you that it is in ms.
2) USBSER.SYS has a small buffer, about 16K in size. Once you attach your device, USBSER.SYS will read up to 16K from the device, and then stop reading.
3) Once you open the USB COM port, USBSER.SYS flushes the buffers and starts reading. As long as you consume the data, it will keep reading from your device indefinitely. Once that buffer fills, it will stop issuing BULK IN requests.
We are trying to use the USBSER.SYS, not the Keil VCOM driver, as we want to use the Windows USB Extended Compat ID OS Feature Descriptor so our device can plug and play with no .inf or useless windows update searches.
Does this sound rational to anyone else? (Tsuneo?)
-Steve
1) Polling interval of interrupt endpoint Windows assigns 1,2,4,8,16 or 32 ms as the actual interval, for every interrupt endpoint (not just for CDC). It originally derives from OHCI host controller limitation.
2) Buffer size You may tune the buffer size by calling SetupComm(dwInQueue).
3) The bulk IN endpoint of usbser.sys runs, regardless of open/close (CreateFile/CloseHandle) by the application. This behavior is similar to legacy UART COM port.
> We are trying to use the USBSER.SYS, not the Keil VCOM driver,
??? "Keil VCOM driver" is just an INF file, which introduces usbser.sys
The problems of usbser.sys are,
a) Poor error recovery on bulk IN pipe www.microchip.com/.../m538194.aspx
b) No WM_DEVICECHANGE message Other drivers of USB-UART (FTDI, SiLabs, Prolific, etc) issue WM_DEVICECHANGE without registratioon. usbser.sys doesn't. We can't even register usbser.sys, because it doesn't open device interface - workaround: attach serenum.sys over usbser.sys, and register its interface, instead
c) RTS changes just with DTR setting.
etc.
> we want to use the Windows USB Extended Compat ID OS Feature Descriptor
Ah, "MS OS descriptors" and "WinUSB device" in MS term.
"MS OS descriptors" msdn.microsoft.com/.../ff537430(v=vs.85).aspx "WinUSB device" msdn.microsoft.com/.../hh450799(v=vs.85).aspx
In above link, MS described that "WinUSB device" has introduced since Windows 8 But actually, it works since WinXP, by installing winusbcompat.inf/.cat once.
"MS-official "WinUSB class" driver for XP, Vista and 7" www.microchip.com/.../m790429.aspx
> so our device can plug and play with no .inf or useless windows update searches.
Agree. "WinUSB device" will be popular more and more, because of "plug and play" without any driver installation.
Tsuneo