Re: USBSER.SYS: where to get a bug-free version?
From: Marc Reinig (AOLab_at_newsgroup.nospam)
Date: 08/30/04
- Next message: Gereon: "Re: Handle To Driver Not Closing"
- Previous message: toni: "Problem creating reference clock in filter"
- In reply to: Holi: "Re: USBSER.SYS: where to get a bug-free version?"
- Next in thread: Alexander Grigoriev: "Re: USBSER.SYS: where to get a bug-free version?"
- Reply: Alexander Grigoriev: "Re: USBSER.SYS: where to get a bug-free version?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 30 Aug 2004 11:10:41 -0700
In general, Windows does support composite devices.
However, USBSer does not support operation in a composite mode (well, you
might try using the endpoints after the ones USBSer expects, but I'm not
sure if that works across all revs).
Also, as far as I am aware, Windows does not support DFU as a class and USB
has not identified any class which must be supported.
So this is not a violation of the USB spec. Should it be changed in Windows
to make development easier? Yes. Do you need to write a Windows driver or
change your device to not cause a blue screen on a Windows host? Yes.
Marc Reinig
System Solutions
"Holi" <holi@nospam.com> wrote in message
news:%23Vn8DTmjEHA.2776@TK2MSFTNGP10.phx.gbl...
> First of all I'm not so sure if Windows supports composite devices at
> all - not to support is one thing, but producing BSOD's because of not
> supporting is another.
>
> DFU specs (chapt. 4.1.) say:
> "During normal run-time operation, the device exposes its normal set of
> descriptors. However, the
> following additional descriptors are inserted within each run-time
> configuration that supports DFU:
> - A single DFU class interface descriptor
> - A single functional descriptor
> 4.1.1 Run-Time Device and Configuration Descriptors
> The run-time descriptor set exposes the device’s normal run-time device
> and configuration descriptors.
> The bNumInterfaces field of configuration descriptor of each configuration
> that supports DFU is incremented by one to accommodate the addition of the
> run-time DFU interface."
>
> Our device was checked by a validator program on MAC OS and looks fine.
> Windows ends up with a BSOD with this implementation of DFU specs. I think
> for DFU support this IS a requirement.
>
> What do you think?
>
> Holi
>
> Marc Reinig wrote:
>> The USB spec has many features. Some are required and are labeled as
>> such.
>> Some are optional and are not labeled as required. Which of the required
>> features do you feel have been either omitted or incorrectly implemented.
>>
>> Marc Reinig
>> System Solutions
- Next message: Gereon: "Re: Handle To Driver Not Closing"
- Previous message: toni: "Problem creating reference clock in filter"
- In reply to: Holi: "Re: USBSER.SYS: where to get a bug-free version?"
- Next in thread: Alexander Grigoriev: "Re: USBSER.SYS: where to get a bug-free version?"
- Reply: Alexander Grigoriev: "Re: USBSER.SYS: where to get a bug-free version?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|