Jump to content

Suitability of NI-VISA for sustained high-speed USB transfers?


andymatter

Recommended Posts

Hi all,

Question for the USB programmers:

I am currently attempting to write a LabVIEW application in Windows using a third-party USB driver to communicate with a custom device. The driver's provisions for asynchronous I/O have been giving me grief for a while now, so I am checking out alternatives. I need a driver that will allow me to perform high-speed data transfers over a bulk endpoint. Let me stop to define terms here, just so we're all on the same page...

There are basically two approaches USB data transfers:

Synchronous (blocking)

This is the easy way of doing things, where you issue an I/O request, wait for the data to transfer within a certain timeout and then return your results (data, bytes transferred, success, etc.). Note that there is nothing happening on the bus over the time interval where the transfer bus-signalling has completed, the interrupt is serviced by the OS, the OS signals a transfer-complete event to your waiting function, you process the results of the transfer and call your function again in order to issue the next I/O request over the bus. That time interval represents a huge waste of bus bandwidth and, while this method allows for enough movement of data for most applications, it does not work if you need to move large amounts of data in the shortest possible time.

Asynchronous (non-blocking)

This is where you set up a queue of transfers to make better use of the bus. Basically, you start by issuing a queue-full of I/O requests, service the results of each item as they come in one by one, re-submitting each item back into the queue by issuing another I/O request. This way, the next transfer is always coming in over the bus while you deal with the results of the previous transfer. I've read Windows driver programmers call this "overlapped I/O". This is how sustained high-speed transfers are done.

I'm looking for a driver that provides for an implementation of the latter. I've been looking all over the internet for a generic Windows USB driver that will do the trick, but so far I am unimpressed with the advertised capability and/or cost of what I've found. I know that LabVIEW provides VISA functions for USB and that any device can be set up to use them. Is it possible to use VISA events in a way that will allow me to do fast queued asynchronous I/O over USB? If so, does anyone have an example? Is this beyond VISA's capabilities? What are your experiences? Any suggestions?

I would really like to avoid writing my own Windows drivers or starting over from scratch under Linux.

...As an aside, has anyone successfully used the asynchronous transfer methods of Cypress Semiconductor's CyUSB driver in LabVIEW?

Link to comment

Well assuming you're talking about BULK transfers (VISA doesn't support Isochronous mode transfers) then using the standard VISA Read and VISA Write will get the job done for you. I've never tried it but these VIs have the option for asynchronous or synchronous mode. That would certainly be the easiest thing to try. It would allow a quick change from async to sync and back to compare speeds.

If you're using something other than BULK transfers, things would be a little more interesting. For Interrupt transfery for example you can create more than one listener so that when one listener is busy processing data, others are still actively monitoring the USB port.

I wrote a tutorial over on the NI site. Maybe you'll find an answer there.

Shane.

Link to comment

QUOTE (shoneill @ Dec 10 2008, 03:03 AM)

The endpoint is BULK and the direction is IN. I have just read through the help files for all of the VISA functions and properties relevant to USB Instr and USB Raw and I don't see anything suggestive of different USB transfer modes as I've defined them above. Am I missing something?

QUOTE (shoneill @ Dec 10 2008, 03:03 AM)

If you're using something other than BULK transfers, things would be a little more interesting. For Interrupt transfery for example you can create more than one listener so that when one listener is busy processing data, others are still actively monitoring the USB port.

Asynchronous transfers are, by nature, multi-listener, where each "listener" in the queue is an event callback from the OS. The endpoint can also be BULK or ISOCHRONOUS type, not just INTERRUPT, but I see now that you're speaking specifically of NI-VISA's implementation. Hmmm. I see that there is no specific event "handle" passed between the "VISA Enable Event" and "VISA Wait on Event" functions, suggesting that an individual VISA event is a blocking task. That is, it would suggest that one can't fire off a queue of events and then wait for each specific one to roll in, all within the same thread. That means I would have to divide the task into separate threads, where I'm limited to my remaining unused execution systems * 2 threads per execution system = 8 to 10 threads.

Is that enough?

Does VISA even allow this sort of multiple-access to the same USB device endpoint?

It might be do-able. [whine] I was hoping to stay lazy and use a BULK endpoint of the USB chip's built-in Default Device, but to give me an INTERRUPT endpoint with a decent buffer depth requires that I write a buttload of firmware first [/whine].

Thanks for the link to the tutorial. It was interesting, but I didn't see anything that addresses this specific issue. Again, I may have missed something.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.