vicnet31 wrote:
More generally, why a private protocol for such device.
To maximize both the throughput on the bus and the data's integrity.
USB devices are more complex and nuanced that what I'm saying here, but there is a key tradeoff a hardware designer must make when creating a USB device: does the device need gauranteed bandwidth from the host (aka isochronous transfers) or does it need to send/receive a lot of data (aka bulk transfers)?
Gauranteed bandwidth is desirable since USB I/O is round-robin controlled from the host -- even when another device on the bus monopolizes the bus, the host will periodically service an isochronous device. Cameras and audio devices usually choose this approach since everyone wants their video and audio to be both as real-time live as possible and without stutters. Unfortunately, isochronous transfers are allowed to drop old data in order to keep giving the host the newest data.
Bulk transfers are desirable since they can use the nearly the entire bandwidth of the bus, so that the data can move quickly. Flash drives and other external storage choose this approach. Unfortunately, bulk transfers aren't gauranteed a minimum bandwidth or latency, so communication can be 'bursty'.
NI created a private protocol to help bulk transfers behave more like isochrohous transfers -- a DAQ device cannot lose data (so bulk is a requirement), but a DAQ device should also be resonsive and fast (so isochronous is a desire). For more details, see NI Signal Streaming: Sustaining High-Speed Data Streams on External PC Buses at http://www.ni.com/tutorial/4636/en/ .
vicnet31 wrote:
Currently, I need these boards only for counter.
Any suggestions ?
- get a small lib from NI on ARMv7 just to access counter ?
- sign a non-disclosure-agreement to get protocol specifications or lib code sources ?
- reverse ingeneering USB protocol ?
- leave NI boards, and try USB-DUX that has an open source protocol ?
You can pursue the first two options by visiting http://www.ni.com/support/daq/usbddkForm.htm . For the third option, I seem to recall a few reports on the NI 6501's communication being studied and made into a library. Finally, depending on how you're using the counters, it might be even easier or cheaper to use a microcontroller from Atmel or PIC than a full device from NI or USB-DUX.
Joe Friedchicken| NI Configuration Based Software |
|---|
Get with your fellow OS users
[ Linux ] [ macOS ] | Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008) |
).
More generally, why a private protocol for such device. There is no add value on protocol, not here.