USB-8452 Read Speed is slower than expected

[ChrisFeucht]

Hi,

I am trying to use the USB-8452 to repeatedly read a 2Mb SPI EEPROM, and I am finding the that read speed is much slower than expected.  I am running the SPI clock at 5MHz, so I would expect that the time to read the full EEPROM should be on the order of 0.5s.  Instead, I can not read the entire EEPROM faster than 1.3s regardless of using the LabVIEW basic or scripting models.  With a competing device using a Python programming interface, I reach a value closer to the nominal read speed (0.53s per dump).

Are there driver updates or other settings that I may need to change to approach closer to the theoretical speed?  Generally speaking, I don't need the timing granularity that the scripting model provides, so I would prefer to stick with the basic model if possible.

I am running LabVIEW2015, and the USB-8452 is running driver version 2.1.3.0.  Attached are the subVIs that I am using to read the EEPROM in my larger project as well as a simple wrapper VI to enable testing.

[GatorChomp]

Hi ChrisFeucht,

It looks like the driver version you are running is not compatible with LabVIEW 2015. It might be working to some degree, but there's likely some incompatibilities or untested behavior that could be causing what you describe. Try updating to the NI-845X 15.0 Driver, and see if the behavior persists.

http://digital.ni.com/public.nsf/allkb/3F9B7A67207EF793862574BF00764C9F
http://www.ni.com/download/ni-845x-15.0/5611/en/

[ChrisFeucht]

As best as I can tell, I am running the latest software.  Just to be sure, I ran the installer at the provided link, and it said that everything was up to date.  This isn't terrribly surprising as I just started using this adapter two months ago and downloaded the driver from the NI site at that time, but it was worth trying.

[GatorChomp]

Hi ChrisFeucht,

I'm going to guess that the version "2.1.3.0" would be your USB-8452's firmware, then. I think your best bet is going to be the scripting API if you want faster performance out of the USB-8452 in LabVIEW. You could also use the C API, but I'm not sure if that would result in any difference regarding performance since the driver calls would be similar or that same. 

I know our Basic API is explicitly slower than the Scripting API, as mentioned in the "SPI Basic API" section of the following White Paper. I have not, however, been able to track down any numbers regarding what the difference in performance actually is. There is also the SPI Streaming API, which might be applicable if you were focused on only reading from the SPI Slave.

http://www.ni.com/white-paper/8359/en/#toc4
http://www.ni.com/tutorial/14269/en/

I did find a forum post from a previous question regarding performance of the USB-8452, and while the numbers there are customer generated they may prove useful to you as well. If you absolutely need low latency reads or precise timing, I would recommend looking at one of our FPGA devices.
http://forums.ni.com/t5/Digital-I-O/NI-USB-8452-Achieving-maximum-SPI-write-speed/td-p/2626837

[ChrisFeucht]

Hi Charlie J,

As odd as it sounds, I find that the scripting version is somewhat slower than the Basic API.  I updated the example code that came with the driver install for my particular SPI EEPROM and instrumented tick counters at various boundaries (VI attached).  The segment with the Run SPI Script VI came in at around 2700ms.  That strikes me as a bit counterintuitive, but I can't see anything that I would have done incorrectly to yield that result.

Thanks for the suggestion about the FPGA; if my internal customer requires the test to run faster, that will the next proposal.

Chris

[ChrisFeucht]

I decided to go with another vendor's hardware platform due to the read limitations of the NI-8452.  While the FPGA was an interesting suggestion, it wasn't feasible in the timeframe allotted.

[sandeep2009.1988]

Hi,

      I am trying to communicate with NI USB 8452 with slave sensor in labview using stream API. I am not getting proper response .Number of bytes written is 11. Clock rate 500 k hz. Please help me out to solve this problem.

[GatorChomp]

Hi sandeep2009.1988,

This is an older forum thread, and your question appears unrelated to the original one posted by Chris. I would advise posting your question in a new thread specifically for that purpose, as you should get more visibility and assistance that way.