I am using a USB-8451 to communicate with an RM3000 device using the SPI protocol. My software uses the 8451's 'basic' C API. The RM3000 has a DRDY line that goes high when the requested data is available. This is connected to port 0, line 0 of the 8451's dio interface.
When I use ni845xDioReadLine to check the DRDY line after writing a command and before reading the response, the ni845xDioReadLine call takes several milliseconds to execute. The DRDY line is always already high because the ni845xDioReadLine call takes so long.
Would you expect the ni845xDioReadLine call to take that long? Would doing the DRDY check using the 'advanced' scripting version of the ni845xDioReadLine call be any faster? I am hoping to read data a 200Hz and need to minimize the transaction time to achieve this sample rate.
I am measuring the time by looking at the SPI transactions on a scope and looking at the command and response timing with and without the ni845xDioReadLine call commented out.
Any help would be appreciated.
Solved! Go to Solution.
This is expected. The digital lines on the 8451 are static software timed ports. Therefore a few milliseconds of delay is normal.
Thanks for the reply. Would scripting the sequence help my performance any? Currently I do a
ni845xSpiWriteRead - to write the command
ni845xDioReadLine - to check DRDY
ni845xSpiWriteRead - to read the response
This sequence takes about 4.5ms if DRDY is already set the first time it is checked.
Would making a script the does
ni845xSpiScriptWriteRead - to write the command
ni845xSpiScriptDelay - delay the expected DRDY setup time
ni845xSpiScriptDioReadLine - to verify DRDY was set
ni845xSpiScriptWriteRead - to read the response
and then re-running this script at my sample rate take less than the 4.5ms that the sequence takes using the basic API calls?
Also, I don't have a hi-speed USB 2.0 port on my PC would that affect the above performance?
Yes, scripting does often improve performance because it allows the programmer to manage the steps that are being taken. In turn, this can eliminate steps that the higher level VIs execute and manage for you that may not be necessary depending on the application. There are examples of scripting in the Example Finder, under Hardware Input and Output»I2C and SPI»SPI Advanced or I2C Advanced. It is also possible that not having the higher speed USB port is making a difference, but the only real way to know would be to try a USB 2.0 port with your application.
Hope this helps,