SPI_STC_vect : grabbing SPDR byte too many times

Projects Programming
1

I'm sending a U8 bit integer from LabView SPI program to my Arduino Mega 2560 (which is supposed to be acting as the slave.) In my ISR function, I grab the byte from the SPDR register and store it in a buffer array (to be processed and printed to my Serial console.)

In Labview, I literally just copied the following setup, situation by situation (except I added a 'reverse 1D array' so that, hopefully, the MSB is in the 0th element of the array. This setup passes SPI data in an 8-iteration loop so that all bits get sent.

http://www.ni.com/example/9398/en/

Every time I print to the console, I receive a lot of data, hundreds of numbers, as a result. Here's the code:

#include <SPI.h>

char buff[3];
volatile bool process_it;
volatile byte vial;
volatile byte spot;

void setup() {
    Serial.begin(115200);
    SPCR |= bit(SPE);
    SPI.attachInterrupt();
    process_it = false;
    spot = 0;
}

void loop() {
    valuesSPI();
}

void valuesSPI() {
    if (process_it) {
      vial = buff[0];
      Serial.print("vial: ");
      Serial.println(vial);
      memset(buff, 0, sizeof buff);
      process_it = false;
    }
}

ISR (SPI_STC_vect) {
  byte b = SPDR;
  buff[spot] = b;
  spot++;
  if (spot > 1) {
    spot = 0; 
    process_it = true;
  }
}

The output looks like this except repeated hundreds of times.

vial: 0
vial: 64
vial: 16
vial: 8
vial: 4
vial: 32
vial: 64
vial: 4
vial: 0
vial: 8
vial: 4
vial: 16
vial: 0
vial: 32
vial: 130
vial: 8
vial: 4
vial: 128
vial: 32
vial: 1
vial: 4
vial: 8
vial: 8
vial: 128

Let me know if any of this is unclear, or if you would like to see more information.

2

so that, hopefully, the MSB is in the 0th element of the array.

The most significant byte of a one byte value?

Your buff array is used by the ISR and by loop, without it being declared volatile. Not a good idea.

3

most significant bit, according to Labview....without the array reversal, the 0th element would contain the least significant bit. Although, all in all, I don't believe that reversing the array is necessary anyway...the results would still be noticeable.

And good call, I switched it to volatile, however the results were the same.

4

without the array reversal, the 0th element would contain the least significant bit.

I don't understand what you mean by "array reversal". You store an 8 bit value in the array - whether in the first element or the second isn't really clear. You read the first element in the array. You never, that I can see, reverse the bits in any element in the array.

Storing an element in an array doesn't, fortunately, reverse bits automatically.

5

Reversing the array occurs in LabView.

Example:

Input - 6
initial array[8] - 00000110, where the two 1's are the 5th and 6th elements.
reverse array - 01100000, then the MOSI line transfers the data.

Problem is, when I read that entire byte from the SPDR register, I get the jargon I posted above. I should be able to read the byte, whether it as 00000110 or 01100000 and get a solid number in the first element position for my volatile char buff[] array.

6

The array is completely useless. Get rid of it.

Without an array, there is no need for an index. Get rid of it.

The ISR needs to store the character in a global volatile variable, not in a local variable.

process_it should be set unconditionally. All it means is that the ISR was called.

When you get rid of all the red herrings, the moldy green crap underneath them might reveal itself.

7

Turns out the issue was my method for sending data on the MOSI line...the button I used was not being properly shut off at the end of the transaction so the register kept piling up random data (which had the Arduino interrupt function capture each data bit...or so I believe at least.)

I do have a follow up question in terms of syncing clock signals. My master runs at 40MHz and, from what I've read, the Arduino runs at 16MHz. I configured the 8-bit data to be sent with 2us pulses at 50% duty cycles. This was too fast for the Arduino, so how do I match up these differing clocks?