Do I need to write my own host side USB driver for a CDC device?

I have tried looking at a variety of websites but so far Google has not been my friend.

I am having trouble finding out whether I need to write my own device driver for the various windows/linux/mac platforms that the device I am developing may be connected to, or whether the functionality is provided by the standard drivers.

My device is a USB CDC (communications device) that appears as a COM: port. It also includes a battery charger that will, once the device has been enumerated require the full 5 unit load (500mA) supply current that can be drawn from the USB connector. My problem is that if the USB driver in the host decides that it cannot deliver the full supply current then it should fail to enumerate the device.

If, as a fallback, I provide a second configuration set that only allows the device to draw 1 unit load from the interface connector will the standard drivers enumerate the device using this configuration.

Reply to
Ian
Loading thread data ...

Is there a reason why you can't detect this condition and detach? For example, turn on a dummy load that will shut the port down?

Reply to
larwe

I don't know about Windows, but the sample CDC code in Microchip's USB framework minimally works with Linux' "generic" usb-serial driver.

By "minimially", I mean that Tx/Rx works, but get/set line-coding (baud rate, parity, etc) doesn't. You also need to explicitly pass the vendor= and product= parameters to the usbserial module so that the module knows it is supposed to be driving that device.

On Windows, the lack of a generic ACM driver may be less of a technical issue and more an opportunity for MS to control access via driver-signing.

When Linux auto-configures a USB device, it ignores configurations which draw more current than the bus can provide. If there are other configurations, they will be considered.

If there are no other configurations, the device will end up in the "address" state rather than the "configured" state. The driver could subsequently configure the device if the available current increases (actually, it could just configure it anyhow; the kernel generates a warning if you do this, but doesn't prevent it).

Reply to
Nobody

d

=3D

s
.
t

er

it

s

Thank you. That last part of your answer was what I was looking for - some confirmation that the host side driver would ignore configurations that it did not have the resource to support (in this case power supply) and choose an alternate configuration that it could support.

Ian

Reply to
Ian

We use CDC/ACM units with Windows, Linux and OSX with no additional host drivers. Under Windows XP upwards, they work fine. We also use composite MSC and CDC/ACM units under all three. Surprisingly, composite devices are most difficult under OSX because OSX up to

10.5.6 does not support the IAD descriptor.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
 Click to see the full signature
Reply to
Stephen Pelc

Another data point: I've since noticed the cdc-acm "modem" driver, and can confirm that it will recognise Microchip CDC demo without needing any parameters, and supports the line-coding (baud rate etc) request.

Apparently there are quite a few modems which actually use the CDC-ACM class.

The driver appears to recognise anything with bInterfaceClass=2 (Communication Interface Class), bInterfaceSubClass=2 (Abstract Control Model) and bInterfaceProtocol in the range 1-6 (V25ter, PCCA101, PCCA101_WAKE, GSM, 3G, CDMA) as a CDC-ACM modem. A union descriptor should be attached to the interface with the control interface as the master and the data interface as the first slave.

Also, on Windows, the "driver" is just a .inf file which uses Microsoft's usbser.sys and msports.dll, plus a security catalogue (although installing the driver results in an "unsigned driver" warning).

So it shouldn't be necessary to write a custom driver for a CDC-ACM device for either Windows or Linux.

[That would seem to make CDC-ACM a good choice for all manner of DIY USB widgets which just need a two-way "pipe" for communicating with the host.]
Reply to
Nobody

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.