USB device class is CDC class - which device driver to write.

Hi

I am on a task to write a device driver for our native USB device.
Decided to use WDF model and KMDF framework.

After much effort came to know that our USB device falls under
"Communications and CDC class" (Base 0x02h) of system defined USB classes.

Being new to device driver development,
Now, I would like to take help on how to proceed further with the
development of the driver...queries like - Shall I write Function or Filter
driver ?; Does that come under KMDF or UMDF development of drivers?..etc..

Ur help is appreciated.

 

What's the device's subclass? If it's also 0x02h, i.e. a USB modem,
you can use the inbox usbser.sys driver. If you don't want to do
that, you'll need to use KMDF as your driver will be a lower filter to
Modem.sys, and (apparently) the UMDF reflector must live at the top of
the stock, meaning UMDF is out.

If it's going to just be a virtual COM port, I suppose you could use
UMDF, but this ties your hands in the future if you ever want it to be
a Modem also.

If it's going to be something else entirely, we probably can't help
unless we know what specific class of device you have, before we
suggest a driver model.

 

Hi chris,

Thx for the response.
I would like to brief my requirements and updates to your queries below.

- Used UsbView.exe to know that the USB class of my device is 0x02 (CDC), in
the same bDeviceSubclass is 0x00; bDeviceProtocol is 0x00;MaxPacketsize is 8;
No. of configurations being 1.
- We are planning to go for Microsoft Digital signing of the driver.(As we
are planning to support Vista/Xp/2000 and as we dont want any UCA messages
given by the system).
- Currently i tired the approach which you told, tweaking the .INF file of
modem + Using UsbSer.sys. This way the Authentication messages are
encountered, and at the same time I dont think it is according to the norms
of MS as our device may not fit in to the modem functionality.
- To describe our h/w device, It is an Industrial device used to
monitor/measure the relays in the high energy circuits. we have a provision
of rs-232 & a USB to it, whose functionality in Programmer perspective will
be read/write/upload firmware/trending.

Hope i gave you a brief info required.

I add my other queires to them.
- Will WinUSB be useful for me for this approach?

 

A subclass of 0x00 is RESERVED and thus undefined by the CDC spec, so
you're going to need to change that.

Well, even if you reference an inbox driver with an INF manually, you
still need to get your INF signed. Also, usbser.sys can be loaded as
a Ports-class device (as opposed to Modem), which places less of a
burden on your device.

If you are saying the application is expecting a Windows-style serial
interface, then you'll absolutely need to either use usbser.sys or
create your own driver. Otherwise, your driver can expose a custom
device interface and you can use IOCTLs to communicate with it.

WinUSB is not supported on Win2k, which you said you need to support.
So probably not.

 

-Yes,u r right !! i have some thing to add.
As specified we could use the Usbser.sys and use .INF standardised with
digital signing. But, we dont find much change in functionality vis-a-vis
speed, etc.when compared to existing serial port.(as the device will be added
as a virtual COM port and the speed will be that of serial port itself) Right
? if no, let me know how to increase the speed or any other way to attain the
speed of that of USB 2.0.

-In this case if i would like to make out new driver for myself etc. what
do you suggest me likewise Framework - approach - etc.?
Shall i go with "Using KMDF - CDC(port) class for my device - generate a
standard .INF file to get Digi-Signed".

- Regarding the changing of subclass(my case its RSERVED) can you specify
any place to look into on what factors or how it can be changed.

 

Usbser.sys will operate at the native speed of your device and the USB
stack. Baud rate, etc. settings are sent via control requests to
endpoint zero (see the CDC ACM specification for more details). If
you have a USB 2.0 high speed device, you should be able to attain
speeds in the several megabits-per-second range with this driver.

If you are going to make a new driver, which I am not sure you need to
do, I would recommend using KMDF.

I don't know, that's really up to you.

CDC ACM is class 0x02, subclass 0x02. That's what usbser.sys is going
to look for, and also probably what you want if you are going to
emulate a serial device. To change this requires a firmware change to
your device...

 

Hi,

I got a clear picture on why there is no reason in developing a new Dev
driver for my requirement.

I have couple of things to ask,infact to request . (considering using
Usbser.sys)

[For our discussion, consider layers of communication looks like:

- If i understand it right, above thing you quoted is something how it
happens between 'Driver<-->H/w Device'.

-Can you just breifly explain how exactly, from my application I should be
interacting with the device/Driver ?
(For example, In current existing scenario i wrote a serial class to write
&Read on to the port handle with specific baud(19200) rate given by my
protocol MODBUS - packet format.etc.) Similarly, let me know How exactly I
should proceed with my task. As still i feel at the same rate only
sendng/receiving the requests as that of rs-232 port from my application.

- Will the usage of 'usbser.sys-CDC ACM' will still install the driver as a
'virtual COM port' OR Is there any other way to get it installed ? My concern
of questioning being - trying to make it(driver) work optimally and by
following the standards.

More over, Thanks for the earlier info, it is of much use and am looking
into the CDC ACM spec.,as well checking with the h/w guys too regarding the
same.

 

Well, mostly. I'm saying if you call, say, SetCommState() on the COM
port created by usbser.sys, this will result in a series of serial
IOCTLs being sent to the driver. The driver, in turn, will translate
them into endpoint zero control requests sent to the device. In other
words, you won't get much in the way of endpoint zero requests without
interaction from userspace.

Well, if you use usbser.sys, one of the advantages is that (in theory)
you can use exactly the same approach -- ReadFile()/WriteFile() plus
the existing set of serial API's.

You basically have two choices: "Modem" class (which you don't want,
since your device is not a modem) or "Ports" ("virtual COM port")
class.

The class installer for each one will reserve you a COM port on the
system, while "Modem" class will additionally install your device as a
"modem" on the system, which again I don't think you want.

 

Hi,

One last doubt. May not be the least!!!

If i go keeping CDC as the class in .INF (As shown by my device) and create
a standard .INF, Will I be able to get the digital certification?

As I feel, as CDC means a composite class, The MS fellas will be testing all
the functionality of a CDC device. Else, shall i make my Class as ACM.(But
Yes!i understand from our discussion that CDC is baseclass and ACM is the
subclass is you suggested to keep,Yet, I Find only one section related to
Class definition in .INF file; So got a doubt on what CLASS to keep in .INF
file definition..)

Please clarify..

For Implementation from UI, am already looking the perspecitive of the
Serial APIs...

 

Hi,

It would be of great help if you could answer.

Will it be a issue to get digital certification from MS to support
Vista/XP/2000
when the USB device's class is different to that of the one which we specify
in
..INF file. (Given the thing that, my purpose of accessing the USB device is
working fine on Windows 2000/XP/Vista with minimal Authentication message
blocks while installation of the driver)

To be in specific, My USB Device shows baseclass as CDC -0x02; But I used
'Modem' as the Class to mention in .INF; (used the inbox usbser.sys driver,
by
using my own .INF), now would like to go for digital signing to avoid UCA
messages.

 

First of all, "CDC" absolutely does not mean "composite device
class". It actually stands for "communications device class". A
composite device actually has class/subclass/protocol (at the device
descriptor level) of all 0x00's.

To directly answer your question, the Windows setup class (like:
Modem, Ports, and so on) are (almost) totally unrelated to the device/
subclass/protocol values on your device. The former identifies what
"kind" of device you have from a Windows perspective, while the latter
is really more of a low-level implementation detail.

Anyway, if you use the "DTM Unclassified" suite of tests when you are
going for WHQL, they don't pull your device's descriptors at all. So,
no, it won't be a problem.

 

Hi Chris,

First of all pardon me for the kind of english i used which made you explain
little more.."CDC means a composite class,..." saying this i meant that 'with
in CDC (communication device class) specification they mentioned it as a
composite device'.

Any ways thanks for clearing my doubt.

I appreciate your technical support and patience you showed in answering my
questions...

Thanks once again