SPI and I2C Driver API CS Info

[Aditya_Shankar]

Hello,

I am trying to implement SPI in the FPGA target of myRIO. I am using this API(https://www.ni.com/en/support/downloads/tools-network/download.spi-and-i2c-driver-api.html) from NI for it. I am posting in the LabVIEW thread as this API is for LabVIEW FPGA and not only for myRIO From the examples, I learnt that i need to use the vis in the following order.

write->Arm->Read

I am communicating with an IC. I have been successful in writing 3 bytes of data to it. Now I need to read data from it after sending 2 bytes. The CS shouldn't be brought back to HIGH between writing the 2 bytes and reading. My code for the reading is not working

I went through all the examples but I couldnt find any information regarding whether CS toggles between the Write and Read. My codes for both writing 3 bytes and the reading are attached

I would grateful if any one could give information regarding the CS or point out any error in my read code

[aeastet]

Hi Aditya,

When I am working with SPI and I have to pull the digital line low to read I usually set up a state machine. I have a write state, read state, Interpret state, digital state. I then have the loop timed to the read loop time. The last one that I did was 10msec. So every 10msec I would pull the digital line low. Write the bytes and then read the bytes interpret and then send the line back to high after. then I go through another loop. on and on until you stop the program.

Tim

[Aditya_Shankar]

Hi Tim

Thanks for your tip. However the API that I am using lowers the CS itself. If I input a dummy cs pin to the library and lower the actual pin myself then even the write code doesn't work. My issue seems to be that the library pulls CS to high between the write and the read

[aeastet]

I have SPI loops that work this way as well. In fact I have an SPI loop depending on how it configured will do either. I that case you would still do the same thing only you read the DI to know if you need to write, read and interpret from the SPI.

[nathand]

Note, I don't have LabVIEW installed and haven't looked at your code.

SPI always reads back one byte for each byte it sends. Often when you're doing an SPI Write, you ignore the bytes that are being read, and vice versa - when you're doing a read you don't care what bytes are being written simultaneously. However, this lets you do a read and a write in the same operation, which is what you want to do. Add however many empty bytes are needed to what you write, then read back the bytes that were read during the time you were sending the empty bytes.

[Aditya_Shankar]

Thank you so much for the quick reply. I did as you suggested. However I had query whether the read vi needs to be in parallel with the write vi or in parallel with arm vi or in sequence with write and arm vi(after arm vi). So i tried all three configurations and got similar results.

I am able to read the register but the issues is that i am getting the correct value only sometimes. Most of the other times I get either 00 or FF as opposed to 60. Do you have any idea what might be causing it ? I have also attached the screenshots of all the three codes

[Aditya_Shankar]

UPDATE: Ok so I solved the issue by reading 3 bytes by setting the for loop input to 3. This works for all three cases. However now there is a new issue. The first time I run the code, I get 00 in all three bytes. However further executions give a output of FF, FF and 60 as each of three bytes which is the correct output

[nathand]

I'm not sure this is your problem, but all of the SPI functions, including initialization, should be in series not in parallel. Can you post a screenshot of the almost-working code?

[Aditya_Shankar]

I have attached pictures of both my near working code as one of the examples of the API. The example also shows that the IP Port vi is in parallel. Infact the IP Port vi doesnt have a error out or reference out. so i dont think it can be placed in series

[Aditya_Shankar · Accepted solution]

Alright. I figured out what the issue was but sorry I couldnt post the solution earlier. The issue was I didnt take into account the time delay for the API to actually send the data and the clock pulses. So I added a delay for the time required to send two bytes and further clock pulses for receiving one byte back from the IC. The delay was placed between the write vi and read vi. The amount of delay was determined by the time period of clock pulses x3 + some extra time. Further I also cleared the internal fifos after configuring the api to clear any data from previous executions. I have also attached the vi.