SPI MISO signal without SPI.transfer() function

Projects Programming
21

lennon-pledge:
With LabView, it's got it's own mindset...the Arduino has to abide by it

How does Labview physically connect to your Arduino?

...R

22

Via 4 wires going to the Mega SPI pins. In LabView, it signals pulling SS low, then performs transactions.

I'm using an FPGA module, where each SS, MOSI, MISO, SCK is represented as a node. If I write to the SS node the boolean "False", the signal will go low, triggering the connection from slave to master. Again, there's no specific SPI protocols in LabView for what I'm doing.

23

lennon-pledge:
Via 4 wires going to the Mega SPI pins. In LabView, it signals pulling SS low, then performs transactions.

I'm using an FPGA module, where each SS, MOSI, MISO, SCK is represented as a node. If I write to the SS node the boolean "False", the signal will go low, triggering the connection from slave to master. Again, there's no specific SPI protocols in LabView for what I'm doing.

I think a bit more detail will be helpful as you don't seem to be doing standard Arduino stuff.

Am I right to think that

  • you are running Labview on a PC.
  • the PC is connected to an FGPA module
  • the FGPA module implements SPI
  • the FGPA SPI pins are connected to the Arduino SPI pins.

If I am not right please give the correct version.

Assuming I am correct,

  • how accurately does the FGPA implement SPI?
  • Is it effectively equivalent to how another Arduino board would do it?
  • If so, is the FGPA acting as SPI master or SPI slave?
  • If it is acting as SPI master is the Arduino properly organized as SPI slave?

...R

24

Yes, LabView runs off a PC...is connected to an FPGA module...FPGA module implements SPI based on hard-coded commands regarding signals passed along wires. Basically you take command of what happens to your signal...there's no software to do it for you after reading a line that says "transfer byte" or whatever. Everything has to be pre-thought out pulse by pulse, time by time, in order for the LabView operation to work the way it should. The FPGA SPI pins are indeed connected to Arduino SPI pins [50-53].

The FPGA is always accurate...again I'm mimicking the SPI ideologies in LabView but the pins that I use to send SPI commands to the Arduino are not "SPI"....they are just random I/O pins that will behave like SPI pins based on how my SPI command structure is set up.

I don't know how an Arduino board does it, but in terms of shifting bits out and bringing them in, everything works well in that regard.

FPGA is the master...it calls the shots by outputting a high or low signal on the SS I/O pin. The Arduino is set up as a slave and will respond adequately when called upon. So long as the SPI registers are setup correctly, the Arduino does not really care for the authenticity of the master, so long as it gets to receive the proper pulses and bits.

25

lennon-pledge:
The Arduino is set up as a slave and will respond adequately when called upon. So long as the SPI registers are setup correctly, the Arduino does not really care for the authenticity of the master, so long as it gets to receive the proper pulses and bits.

This is the bit that puzzles me - but I just needed to be sure I understood the rest of it.

Assuming what you say about the Arduino is true, what is the problem you are having? I would expect everything to "just work".

Can you describe how the Arduino program is intended to work and what is the purpose of the ISR on the Arduino?

...R

26

So, I reread the Atmega2560 datasheet and more of that Arduino book a couple more times.

Turns out the order in which I was putting data into the SPDR buffer, then performing a transaction, etc. was all out of whack.

Here is my solution that ended up working:

  1. In my loop, there is a delay(20); that I incorporate. There is now a function called updateSPDR();

  2. In the updateSPDR() function, I get the input from the LM35 sensor and convert it to a global volatile uint8_t variable called converted.

  3. My SPI MOSI pin in LabView sends out the 00100000 signal every 1 second. Most of them time, there is no valuable temperature information to return, so it just runs (hence the asynchronous situation.) However, sending the 00100000 causes the SPIF flag to set to 1, triggering an interrupt. The way LabView is set up, if I don't return any data, the temperature indicator box (that displays my temp info) will set itself to 32 (because of the 00100000 that gets returned since it was the last thing in the SPDR.) To combat this, I added the updateSPDR() as described above, so the SPDR always has data to relay back.

  4. I did not mention the other scenario where 00100000 is actually 00000000. If that 6th bit is not set, that means I'm using LabView to set a temperature setpoint (which I use to construct the "goal" for a PID that uses the LM35, a Peltier and a fan to refrigerate a box.) So, in the interrupt, I read the SPDR (automatically returning the temperature data), then evaluating the 6th bit. If it's set, then nothing really happens except the read transaction. If it's 0, then I can perform a set temperature action on the Arduino AND a return read to LabView.....satisfying everything.

I appreciate all the help, a lot of which helped trigger my final program. I did not understand the SPI process enough. Hopefully what I described made sense.

27

This is a cross-post of SPI MISO signal without SPI.transfer() function - Programming Questions - Arduino Forum where most of these questions were already answered by Lennon.

Please don't waste everyone's time by forcing them to ask you the same questions again.

28

Sorry, what's a cross post? You're link contains all the posts and replies that match up with this one's. I continue on this post if I have another question.

"Please don't waste everyone's time by forcing them to ask you the same question again."

Is that why certain questions were repeated? I'm looking at the post and I don't see how that could happen (so long as responders read the original replies.) I was blocked by StackOverflow once for not using the same thread to continue a conversation (I would make new threads that could have easily been continued on a previously-created thread.)

29

MorganS:
This is a cross-post of SPI MISO signal without SPI.transfer() function - Programming Questions - Arduino Forum where most of these questions were already answered by Lennon.

I think @MorganS has got mixed up. Or else there were two Threads that have now been merged by a Moderator.

Continue with your questions here.

...R