Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

USB CDC lose data under system-load

123 views
Skip to first unread message

Rob

unread,
Jan 13, 2009, 2:42:04 AM1/13/09
to
Hi,
I wrote a CDC usb driver.
At first it only read data from the lower-level drivers when the application
issueed a read(). With this approach the driver missed a lot of data. After
that I implemented a receive buffer, that is filled by a high-prio thread
(prio 0) that waits on a receive-event. This seems to work ok, only when the
system is really busy it still loses data.

My questions are :
- When the system is "busy" it does file-IO to flash, could this involve
other high-prio threads causing the usb driver to fail ?

- CPU load by regular threads (normal prio) should not harm the prio-0
thread, right ? or will the consume their full timeslice before the
driver-event is handled ?

- Is this a known problem ?

- Anything else I can do to avoid losing data from USB ?

Kind Regards,
Rob
www.robtso.nl

Rob

unread,
Jan 13, 2009, 3:05:02 AM1/13/09
to
BTW, It's CE6.0R2....
Rob.

Valter Minute

unread,
Jan 13, 2009, 4:41:54 AM1/13/09
to
=?Utf-8?B?Um9i?= <__rob_AT_robtso_DOT_nl__> wrote in
news:B4939AA1-5452-48F5...@microsoft.com:

[...]


> - Anything else I can do to avoid losing data from USB ?

You can build a transfers queue, having multiple asynchrounous
transfers pending while your USB device is sending data.
Each time a transfer is completed a new one is appended to the queue.
In this way the USB host driver will not need to wait until your
driver issues a new receive request to get data from the device.
You may try also to increase priority of the host controller IST.
You said also that it seems that you lose data when you access flash.
If you have an external USB controller that shares the same bus of
your flash interface check if access times are configured for maximum
performances. If you have an internal USB controller that uses DMA for
its transfers, check if you can increase its priority using a bus-
arbiter or something like that.

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Rob

unread,
Jan 13, 2009, 5:06:07 AM1/13/09
to

Hi Valter,
Thanks for your response.
"multiple asynchrounous transfers pending", I'm not 100% sure what you mean.

In the current setup a receive is continuously pending, when it's event
fires, the data is read and a new receive started. Can it be faster than that
?
(I have to check the order of these last 2 actions...., might be other way
around)
I suspect you mean a somewhat more elaborate scheme, right ?
The IST has prio 0... (highest)

The DMA/bus things are an entirely differrent matter.....
I'll have to get into that if it cannot be avoided.

Kind Regards,
Rob
www.robtso.nl

Valter Minute

unread,
Jan 13, 2009, 5:27:07 AM1/13/09
to
=?Utf-8?B?Um9i?= <__rob_AT_robtso_DOT_nl__> wrote in
news:7CAE03BA-89E4-48BB...@microsoft.com:

> Hi Valter,
> Thanks for your response.
> "multiple asynchrounous transfers pending", I'm not 100% sure what
> you mean.
> In the current setup a receive is continuously pending, when it's
> event fires, the data is read and a new receive started. Can it be
> faster than that ?
> (I have to check the order of these last 2 actions...., might be
> other way around)
> I suspect you mean a somewhat more elaborate scheme, right ?

Yes. You can start multiple receive transfers (you can do that only in
asynchrous mode). In this way the host driver can start a new receive
transfer as soon as the previous one is completed. It does not need to
wait a new request from your driver.
If you build a small queue of transfers (5-10 of them should be more
than enough) and fill it each time you receive new data you'll keep
the host driver busy receiving at full speed and your receive time
(and priorities, if this involve multiple thread) won't impact
reception speed (provided that the hardware is fast enough and that
the transfers queue is never empty).

> The IST has prio 0... (highest)

Ok.



> The DMA/bus things are an entirely differrent matter.....
> I'll have to get into that if it cannot be avoided.

Sometimes this is the key to improve performances.
Having a slow device (or a fast device accessed in a slow way)
connected to a shared bus may heavvily impact the performances of your
system.

Rob

unread,
Jan 13, 2009, 5:46:02 AM1/13/09
to
Hi Valter,
Any keywords I can search for on this "multiple receive transfers" method ?
I think that will solve my problem....
I'll try to fix it as soon as it's put in the sprint-planning ;-)
Thanks a lot !

Kind Regards,
Rob van den Bergh
www.robtso.nl

Valter Minute

unread,
Jan 13, 2009, 6:03:36 AM1/13/09
to
=?Utf-8?B?Um9i?= <__rob_AT_robtso_DOT_nl__> wrote in
news:99D9398C-9F1E-4D48...@microsoft.com:

> Hi Valter,
> Any keywords I can search for on this "multiple receive transfers"
> method ? I think that will solve my problem....
> I'll try to fix it as soon as it's put in the sprint-planning ;-)
> Thanks a lot !

You can search "asyncronous USB transfers" or something like that, bu
I dubt you'll find a working sample on CE.
The functions that you will have to use are the same you already use
to issue inbound transfers, anyway.

0 new messages