SPI slave response delayed by 1 transfer
Opened this issue · 2 comments
First off thank you very much for your work getting the teensy to act as an SPI slave. I'm having a strange issue though and was hoping you would recognize it and have a simple solution.
I have a master Teensy LC sending a few transfers and a Teensy 3.2 slave just sending back a matching response. I believe I understand SPI thoroughly and know responses are expected on the next transfer, but I'm actually getting the responses after 2 transfers. My slave code just responds with the received data and my master code is using the standard SPI library that works with everything else so I'm at a loss.
All I'm doing on the master is:
Serial.Println(SPI.transfer(0xFF), HEX);
Serial.Println(SPI.transfer(0x01), HEX);
Serial.Println(SPI.transfer(0x02), HEX);
Serial.Println(SPI.transfer(0x03), HEX);
Serial.Println(SPI.transfer(0x04), HEX);
but the returned result is:
0x03 // I know the first result will be junk left over from the last sequence, so this is ignored
0x04 // This is where I would expect the 0xFF back from the slave
0xFF // response arrives 1 byte late as well as subsequent bytes
0x01
0x02
My slave code doesn't differ much from the example, the onReceive function looks like this:
void myFunc()
{
while (mySPI.active())
{
if (mySPI.available())
{
uint16_t rx = mySPI.popr();
mySPI.pushr(rx);
}
}
}
From my understanding this code should just reflect any received data back as a response on the next transfer.
The SPImode argument is set to 8 on my slave, setting it to 16 actually makes the response delayed by another 2 bytes so that's not the issue. Thanks in advance for any help you can offer
it is the way it is designed, I too had this issue and was unable to find a solution for it, probably because the initial FIFO frame includes a command for the clock setup, not sure. You'll have to just push it out with another dummy transfer
That's unfortunate. Might want to put that info in the readme or something