Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does ni845xDioReadLine take several milliseconds to execute?

Solved!
Go to solution

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.

 

Thanks.

 

 

 

 

0 Kudos
Message 1 of 4
(2,084 Views)

IntAndTest,

 

This is expected. The digital lines on the 8451 are static software timed ports. Therefore a few milliseconds of delay is normal.

National Instruments
Product Support Engineer
0 Kudos
Message 2 of 4
(2,072 Views)

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?

 

Thanks again.

 

0 Kudos
Message 3 of 4
(2,067 Views)
Solution
Accepted by topic author IntAndTest

Hi IntAndTest,

 

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,

 

Jen W

Applications Engineer

National Instruments

ni.com/support

0 Kudos
Message 4 of 4
(2,049 Views)