Does CDC device need writting Windows side driver?

NTDEV
1

Dear all
we want to create an USB CDC device.
I want to know if I need to write Windows side PC driver? or using Windows default sys and inf file?

thank you very much.

2

huaping jiang wrote:

we want to create an USB CDC device. I want to know if I need to
write Windows side PC driver? or using Windows default sys and
inf file?

You don’t “need” to create a Windows-side driver, no, but many seem to choose to do so regardless. The usbser.sys driver which is available in Windows is compatible with CDC devices.

However, I’m a little puzzled as all of your questions over the last several months have been about you creating a USB modem driver. So I don’t get why you’re asking this now…

3

Dear Chris
But I found many companies supply msmdm.inf file and *ser.sys, so if our device is CDC device, we only need to supply the inf file.

Yes, we have written a modem driver on Windows side. Because many companies supply CDC class, so I want to so some research on it.

thank you again chris.

4

Since you mentioned “serial” I guess, you talk about CDC ACM device.
Not all CDC devices are of a “serial” nature, there are a couple of networking CDC subclasses that are just irrelevant for usbser.sys.

usbser.sys has only basic functionality and it does not support all CDC features.
Some of the disadvantages of usbser.sys are:

  1. There is no support for CDC encapsulated commands.
  2. There is no way to optimize usbser.sys for specific traffic, e.g. issue USB transfers of N packets, where N user controlled.
  3. usbser.sys deals with standard CDC ACM and *probably* a couple of other serial subclasses,
    and it also deals with not-so-standard CDC devices.
    However, there is no documentation regarding the range of supported configurations and what
    exactly is supported in each configuration.

And there are more technical and business reasons why one would want to buy/develop
a serial flavor of CDC driver.

5

huaping jiang wrote:

Yes, we have written a modem driver on Windows side. Because many
companies supply CDC class, so I want to so some research on it.

Okay. Well, Alexey gave some decent reasons, but nothing that couldn’t be worked around with an upper or lower filter.

Actually, I’d say the biggest drawback to usbser.sys is if you have to support Win2k – that version issues reads that are only one packet in size, killing performance. And, it will stop reading from your device if it sends a zero-length packet. (The XP version of the driver issues 4096-byte reads, and understands ZLP’s…)

6

Hi Alexey
Can you give me more information about the following…?

>And there are more technical and business reasons why one would want to
>buy/develop a serial flavor of CDC driver.

What are th techincal and business reasons?

thank you very much.
huaping jiang

7

thank you Chris.

8

huaping jiang wrote:

> And there are more technical and business reasons why
> one would want to buy/develop a serial flavor of CDC
> driver.

What are th techincal and business reasons?

Here’s my list, in addition to what’s already been stated. Note that you probably shouldn’t consider any of these “deal-killers”, and also note that all (or nearly all) of them can be obviated by use of a lower- or upper-filter:

  1. It will refuse to load unless your USB descriptors match the CDC ACM spec exactly, or nearly exactly (i.e. it will accept a single-interface device). If you have, say, devices in the field that can’t be changed and expose only (for example) a pair of IN/OUT bulk endpoints, it won’t load.

  2. Its internal data buffer is only 16K. This may be a limitation for you.

  3. You have no way to send vendor-specific commands to the device (i.e. endpoint zero control requests, etc.)

  4. This is sort of a corollary to 1), but if you have a multi-function device, it will only load on the first interface/function (because it expects interface number to be zero).

  5. I regularly encountered customer’s machines which were so hosed that we couldn’t unpack usbser.sys reliably, or their certclas.inf was corrupted (whatever that means) and we would get WHQL warnings even though our INF against the driver was signed. If you have an out-of-box driver, these seems to be avoidable.

9

Adding to Chris’s list:
6) Some CDC ACM devices would expect to get a zero-length packet (ZLP) at the end of
USB transfer which is an integer multiple of max packet size.
Other CDC ACM devices do not really need or even do not expect to get a ZLP.
With usbser the ZLPs behavior is not configurable.

And a couple of business reasons:

  1. When you buy a 3rd party driver you pay not only for IP but also for commitment
    to fix things if something is broken.
  2. Some companies want to buy the source code. I don’t know if it’s hard or not to get
    the source code of usbser from Microsoft, but in the case of 3rd party providers the
    source code issue is more straight forward. You pay the money - you get the source.
10

thank you Chris and Alexey very much.

huaping

11

Alexey Polonsky wrote:

  1. Some CDC ACM devices would expect to get a zero-length
    packet (ZLP) at the end of USB transfer which is an integer
    multiple of max packet size. Other CDC ACM devices do not
    really need or even do not expect to get a ZLP. With usbser
    the ZLPs behavior is not configurable.

Ooh, that’s a really good one that I forgot…

  1. When you buy a 3rd party driver you pay not only for IP
    but also for commitment to fix things if something is broken.

I agree with this in theory, but not in practice. Actually, the main reason I rewrote our entire driver set from scratch at my last assignment (modem, CDC Ethernet, generic parent) was because our vendors were totally unresponsive to requests for support. Thus I would highly recommend that if you’re not going to use usbser, just write your own driver yourself – don’t buy or license it from somewhere.