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.

On Jul 28, 5:35=A0am, Ian <ian.o...@gmail.com> wrote:

> 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.

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?

On Tue, 28 Jul 2009 02:35:00 -0700, Ian wrote:

> 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.

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.

> 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.

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).

On Jul 28, 7:31=A0pm, Nobody <nob...@nowhere.com> wrote:
> On Tue, 28 Jul 2009 02:35:00 -0700, Ian wrote:
> > 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 provide=
d
> > by the standard drivers.
>
> > My device is a USB CDC (communications device) that appears as a COM:
> > port.
>
> 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=
=3D
> and product=3D parameters to the usbserial module so that the module know=
s
> 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=
.
>
> > It also includes a battery charger that will, once the device has
> > been enumerated require the full 5 unit load (500mA) supply current tha=
t
> > can be drawn from the USB connector. My problem is that if the USB driv=
er
> > 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 allow=
s
> > the device to draw 1 unit load from the interface connector will the
> > standard drivers enumerate the device using this configuration.
>
> 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).

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

On Tue, 28 Jul 2009 19:31:36 +0100, Nobody <n...@nowhere.com> wrote:

>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.

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, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On Tue, 28 Jul 2009 19:31:36 +0100, Nobody wrote:

>> 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.
> 
> 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.

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.]