Suggested strategies for ensuring Windows keeps up with USB device?
-
Scenario:
- We have a third-party data acquisition device which communicates over USB utilizing USB Bulk Endpoints.
- We will be using the device to generate approximately 34Kbytes of data / sample at about 30Hz sampling rate (total about 1MB/sec).
- We can trigger a sample acquisition and the device can hold the 34K of data until it is "sent" via the USB.
- The vendor states the device is "streaming the data out of a small hardware buffer (512 bytes) on the device directly to the USB to achieve the highest performance".
- The device will refuse to acquire the next sample unless the previous 34K has all been sent.
- Missing a data acquisition is an unacceptable condition.
Potential issue: As many of us have experienced, Windows sometimes just seems to “zone out” (daydreaming?) and this might cause the USB driver to go too long between requests for data. The total amount of data bandwidth is not pushing the bounds of USB capabilities, but the timing is (in conjunction with the small device USB buffer). Questions:
- What are recommended strategies for addressing the issue above?
- On a modern multi-core platform, is it a realistic concern?
- Can USB servicing be made a high(er) priority activity for the OS?
- Would Windows Embedded Compact be a better "host" OS? * At least for the data collection? * How different is development for Windows Embedded Compact?
Thanks.
A positive attitude may not solve every problem, but it will annoy enough people to be worth the effort.
-
Scenario:
- We have a third-party data acquisition device which communicates over USB utilizing USB Bulk Endpoints.
- We will be using the device to generate approximately 34Kbytes of data / sample at about 30Hz sampling rate (total about 1MB/sec).
- We can trigger a sample acquisition and the device can hold the 34K of data until it is "sent" via the USB.
- The vendor states the device is "streaming the data out of a small hardware buffer (512 bytes) on the device directly to the USB to achieve the highest performance".
- The device will refuse to acquire the next sample unless the previous 34K has all been sent.
- Missing a data acquisition is an unacceptable condition.
Potential issue: As many of us have experienced, Windows sometimes just seems to “zone out” (daydreaming?) and this might cause the USB driver to go too long between requests for data. The total amount of data bandwidth is not pushing the bounds of USB capabilities, but the timing is (in conjunction with the small device USB buffer). Questions:
- What are recommended strategies for addressing the issue above?
- On a modern multi-core platform, is it a realistic concern?
- Can USB servicing be made a high(er) priority activity for the OS?
- Would Windows Embedded Compact be a better "host" OS? * At least for the data collection? * How different is development for Windows Embedded Compact?
Thanks.
A positive attitude may not solve every problem, but it will annoy enough people to be worth the effort.
The USB servicing by Windows is running with a higher priority but not your application. At first you should check if the driver for your USB device supports increasing the size of his internal receive buffer. This may help if the default size is smaller than your 34 KB. A common solution would be using a worker thread running with a higher priority to receive the date and store them in a ring buffer of sufficient size. The thread must be of course event driven (new data available). When all sample data has been received by the thread it can trigger the next sampling and send a user defined message to your GUI thread indicating that new data are available. Tasks delaying your communication are mainly hardware related actions like disk and network transfers. When you have implemented the worker thread you can check for missing acquisitions by starting such actions (e.g. copying files from a network share to a local disk or USB drive). If necessary, increase the priority of the worker thread. But note that this is a rather simple and system dependant method. I have done this for a serial communication using a serial to USB converter where status line events must be handled before the next event occurs. This does not answer all your questions but I hope it will be useful.