Recommendations/experiences please
-
Our project seems to be heading in the need of having a small computer to mediate between the UI control/data presentation Windows PC (workstation) and an OEM vendor's device. The system must support at least 1 USB 2.0 interface (to the device) and some other interface (>= 100BaseT ?) to the workstation. The vendor provides an x86 DLL to encapsulate communication with their device so this will need to run 32-bit Windows Embedded Compact (for the real-time capability as well). Smaller physical size is better, as is lower cost. ;) Does anyone have any experiences and/or recommendations (and/or who/what to avoid!) they're willing to share about such systems? Thanks Matt
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
-
Our project seems to be heading in the need of having a small computer to mediate between the UI control/data presentation Windows PC (workstation) and an OEM vendor's device. The system must support at least 1 USB 2.0 interface (to the device) and some other interface (>= 100BaseT ?) to the workstation. The vendor provides an x86 DLL to encapsulate communication with their device so this will need to run 32-bit Windows Embedded Compact (for the real-time capability as well). Smaller physical size is better, as is lower cost. ;) Does anyone have any experiences and/or recommendations (and/or who/what to avoid!) they're willing to share about such systems? Thanks Matt
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
Why cant the vendors device connect straight to the PC?
-
Why cant the vendors device connect straight to the PC?
We've done some experiments and the PC just will not have the real-time responsiveness to keep up with the required data rate (i.e., keeping the USB data stream "drained" so its buffer is available for the next data acquisition). The intermediate Windows CE will be to keep up with the USB in real-time and serve as a bigger buffer than the device has on its own.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
-
We've done some experiments and the PC just will not have the real-time responsiveness to keep up with the required data rate (i.e., keeping the USB data stream "drained" so its buffer is available for the next data acquisition). The intermediate Windows CE will be to keep up with the USB in real-time and serve as a bigger buffer than the device has on its own.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
Right, so the device is USB, what's the problem sucking data out of it? What sort of driver is it using on windows? What was the experiment setup? I have windows drivers for USB devices that will take data off the device faster than the device bus speed. So we are talking mbps for HS devices. (Actually, USB is rather slow really).
-
Right, so the device is USB, what's the problem sucking data out of it? What sort of driver is it using on windows? What was the experiment setup? I have windows drivers for USB devices that will take data off the device faster than the device bus speed. So we are talking mbps for HS devices. (Actually, USB is rather slow really).
The device vendor provides both a driver and an API dll (both 32 bit) to talk to the device. The device uses USB bulk endpoints. The data is guaranteed to be available to the host, however, if the host gets behind, then the device will skip performing the next data acquisition :( The amount of data is actually pretty small, it is the latency that is the bigger issue. Each device acquisition is a little less than 40kB, at 15Hz rate: ~610kB/sec data rate. However, the effective acquisition rate is twice that since the device will not start an acquisition until all of the previous acquisition data has been read. The device takes approximately 30ms to readout an acquisition. And 30ms is about the shortest acceptable data acquisition "exposure time". The experiment I ran was using c# software I wrote to retrieve data from the device using an API function which spins up a separate thread to pull the data into a managed buffer. The application has a separate thread which pulls the data from the buffer and "drops it on the floor". (This is a best case: minimal application computation, though not realistic. Actual application includes significant computation.) The device has a status line indicating if it is ready for an external trigger to begin an acquisition. We have an STmicro eval board running simple SW to provide triggering at a specified interval and a counter of occurrences of status not ready when a trigger was scheduled. I specified an exposure time of 1ms since the exposure time is not concurrent with the data transfer. On an i5 Quad core Windows 7 PC, triggering at 40ms is required to ensure no "not ready" conditions were detected. If I added writing the acquired data to a local file, then there were many "not ready" detections. The actual application has significant additional computation required.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
-
The device vendor provides both a driver and an API dll (both 32 bit) to talk to the device. The device uses USB bulk endpoints. The data is guaranteed to be available to the host, however, if the host gets behind, then the device will skip performing the next data acquisition :( The amount of data is actually pretty small, it is the latency that is the bigger issue. Each device acquisition is a little less than 40kB, at 15Hz rate: ~610kB/sec data rate. However, the effective acquisition rate is twice that since the device will not start an acquisition until all of the previous acquisition data has been read. The device takes approximately 30ms to readout an acquisition. And 30ms is about the shortest acceptable data acquisition "exposure time". The experiment I ran was using c# software I wrote to retrieve data from the device using an API function which spins up a separate thread to pull the data into a managed buffer. The application has a separate thread which pulls the data from the buffer and "drops it on the floor". (This is a best case: minimal application computation, though not realistic. Actual application includes significant computation.) The device has a status line indicating if it is ready for an external trigger to begin an acquisition. We have an STmicro eval board running simple SW to provide triggering at a specified interval and a counter of occurrences of status not ready when a trigger was scheduled. I specified an exposure time of 1ms since the exposure time is not concurrent with the data transfer. On an i5 Quad core Windows 7 PC, triggering at 40ms is required to ensure no "not ready" conditions were detected. If I added writing the acquired data to a local file, then there were many "not ready" detections. The actual application has significant additional computation required.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
SO on WIndows you cant get enough reads down to their dll/driver to get data off the device quick enough, but on winCE you can? I would approach them and ask why this is. SOunds like their API-dll/driver isn't working properly. If they sell windows SW to go with the device, it HAS to be able to work properly.
-
SO on WIndows you cant get enough reads down to their dll/driver to get data off the device quick enough, but on winCE you can? I would approach them and ask why this is. SOunds like their API-dll/driver isn't working properly. If they sell windows SW to go with the device, it HAS to be able to work properly.
The recommendation to use Windows CE came from the device vendor. The "real time capabilities" of Windows CE, and the ability to strip it of anything else that could interfere with servicing the USB device are the basis of their recommendation. The Windows CE system would mediate all communications with the device (only data collection operates in a time sensitive mode). Communication with the host necessarily would be at a lower priority than servicing the USB.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
-
The recommendation to use Windows CE came from the device vendor. The "real time capabilities" of Windows CE, and the ability to strip it of anything else that could interfere with servicing the USB device are the basis of their recommendation. The Windows CE system would mediate all communications with the device (only data collection operates in a time sensitive mode). Communication with the host necessarily would be at a lower priority than servicing the USB.
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed." - G.K. Chesterton
What? They must be incapable of writing a usable windows driver then and their suggestion is a kludge. I repeat, kernel code is perfectly capable of pulling data off a USB device. It can handle data way way quicker than a USB device can produce it. All they need to do id provide a half decent driver and you wont have to buy extra hardware.