Teensy 3.5 SPI Interrupt Routine on SPI Bus 1 or 2

Status
Not open for further replies.
you can tie the pin low if you want and the isr will keep looping over the array till the line is deasserted. make sure the array response buffer is big enough for the bytes your sending, the demo has no protection on this, so make a bigger response array and be sure to reset the pointer before it goes out of bounds on the slave end
 
you can tie the pin low if you want
Then the ISR should always be fired and with it the function myFunc(), right? My problem now is that the function myFunc() is simply not called...

Can you explain to me exactly how that works? Just put the CS pin on ground?

Can your constructor be rewritten so that you don't have to specify CS?
 
the isr fires once and only ends on deassertion, the pins must be specified as it’s set in the hardware registers to trigger
 
the isr fires once and only ends on deassertion, the pins must be specified as it’s set in the hardware registers to trigger

Okay, thanks for the quick answer.
I'm relatively new to microcontrollers and especially teensy. So I didn't understand much about your answer...
Can you give me a concrete example (wiring, code) of how I can tie the cs pin low?
Or is my approach to simply connect the cs pin to ground correct?
 
The CS pin should never be tied constantly to either high or low. The SPI specification states clearly that the SPI master has to assert it (tie low) before a transaction begins and to de-assert it (tie high) after the transaction is completed.
 
The CS pin should never be tied constantly to either high or low. The SPI specification states clearly that the SPI master has to assert it (tie low) before a transaction begins and to de-assert it (tie high) after the transaction is completed.

I know, but the machine (coffee machine) I want to sniff doesn't deliver CS.
So the SPI specification doesn't play a role here.
It already worked with an Arduino UNO, but not with the Teensy!
It would be great if someone could answer my questions from my previous post :):)
 
In that case, you answered your question already yourself: Yes, the CS pin has to be tied to GND to make the slave side basically work. As long as it is high (reverse logic), the SPI hardware of the slave Teensy will sleep.
 
also note that the way that this slave library was designed in order to allow continuous data response, the main loop will never run till after deassertion. you could probably put a led blinking in the loop and tie the CS pin low, if the led doesn’t blink then it means the ISR is active pending transfers, did you stop using the legacy spi code on master and start using SPI transactions using MSBFIRST and MODE0?
 
also note that the way that this slave library was designed in order to allow continuous data response, the main loop will never run till after deassertion.

Hm then I won't be able to use the library for my project.
The coffee machine that I finally want to sniff (the communication between the teensys should only be a test) sends data permanently via SPI. I have to answer with the teensy permanently and in between I have to listen to an RFID module and call a function when the RFID token is on.
@tonton81 Do I see it correctly that I can't get any further with the TSPI_Slave Library here? Is your other SPI Slave Library SPI_MSTransfer suitable for this?
 
ideally on both libraries the transactions are finished upon deassertions, spi is fast enough so toggle between transactions. the hold low method was just a test to see if you get the ISR active or not when holding the pin low, but in a real world case with custom code you’ll be firing interrupts with every byte rather than once per transaction. with the toggling of the chipselect your loop can at least update the array before the next transaction. It also allows a synchronized transaction rather than concurrent flow of data that may be out of sync or inaccurate

SPI_MST doesn’t have issues with out of sync in responses for example as the data and crc are in circular reflow, but a new transaction doesn’t occur until a reassertion commences.
 
ideally on both libraries the transactions are finished upon deassertions, spi is fast enough so toggle between transactions. the hold low method was just a test to see if you get the ISR active or not when holding the pin low, but in a real world case with custom code you’ll be firing interrupts with every byte rather than once per transaction. with the toggling of the chipselect your loop can at least update the array before the next transaction. It also allows a synchronized transaction rather than concurrent flow of data that may be out of sync or inaccurate

SPI_MST doesn’t have issues with out of sync in responses for example as the data and crc are in circular reflow, but a new transaction doesn’t occur until a reassertion commences.

Thanks for the quick answer. Did this answer my question if I can still use your TSPI_Slave Library for my special case (without CS)?

Here is a screenshot of what the real data I want to read looks like:
MASTER
5D44A2CF-4C6D-48CF-9DD1-0BE60AE6A1DE.png

Answer from slave I like to give with the teensy:
2D10D546-BD83-4B5B-8CD9-11BDE2542C77.png

Would that be possible with your library?
 
yes but you still have to toggle after every request, and then your loop can still update the array in the callback. Obviously since the array is used from an ISR callback you should protect the array when changing values

still unconfirmed if you are not using spi transactions or protecting the pointer from going out of bounds since you are writing more than 2 bytes

I know you are seeking a serialized spi slave interface, but thats not the intention due to the complexity and loss of multi device access. It can be done but a protocol would have to be written and only one device can access it for writing. This is possible but not worth the effort to dedicate spi for a single device
 
yes but you still have to toggle after every request

What do I have to toggle and how? I can not control what the master sends. It does not use CS.

still unconfirmed if you are not using spi transactions or protecting the pointer from going out of bounds since you are writing more than 2 byte
In my test I am using SPI transactions, what the master in the coffee machine does I don‘t know.
Instead of a byte array I am using a state machine like in my first post for the slave.
 
I get the impression that you, JSON, are speaking a different language than we who try to help you.
You started a thread about SPI. Then, you are saying that you want establish communication with a SPI master while your Teensy should act as a slave. Then, finally, 2 pages later, you tell us that your so called SPI master device does not use CS. That means, it is NOT SPI! The transmission of clock and data might be very similar, but without a CS signal which goes low before a transaction is started and goes high after the transaction ended, a very crucial part of the SPI specification is missing because the Teensy will never know when all bytes of a packet are sent which would then trigger the interrupt. What you try to achieve is like inserting screws with a hammer instead of a screwdriver. Thus, you should not expect much support for such proprietary stuff. Better you start from scratch and write your own coffee maker library.
 
[SOLVED] Teensy 3.5 SPI Interrupt Routine on SPI Bus 1 or 2

Today I tried again with the TSPI_Slave Library to establish SPI communication between a Teensy 3.5 (Slave) and a Teensy 3.6 (Master).
It worked!! Thanks tonton81 for all the tips!

Unfortunately it only worked if I put the slave select to ground. Regarding my actual project (sniffing the SPI of a fully automatic coffee machine) I have a problem with that and have further questions. But I open a new thread to avoid mixing things up too much.
I'll post the link to the new thread here later.
 
Last edited:
Here comes the summary for all those who have a similar problem. To run a Teensy 3.5 in slave mode the TSPI_Slave Library from tonton81 is well suited.
To use the SPI Bus 1 of the Teensy like in my case you have to connect MISO of the Master to MOSI of the Slave (Pin 0) and MOSI of the Master to MISO of the Slave (Pin 1). The clock is connected to pin 32 of the slave. Since I don't want to use SS/CS in my case, pin 31 of the slave (Chip Select) is connected to ground. Thus the SPI communication is permanently possible.
In order for the library of tonton81 to work now, a small change must be made to the example of the library.
The while loop is replaced by an "if". Thus the program is not fixed in the function myFunc() due to the permanently grounded CS pin and is only called if data is sent via the SPI bus. When the communication is finished the program jumps back into the loop(). Here is the modified code:
Code:
#include "TSPISlave.h"
//0,1,31,32 SPI1
uint8_t miso = 1;
uint8_t mosi = 0;
uint8_t sck = 32;
uint8_t cs = 31;
uint8_t spimode = 8;

TSPISlave mySPI = TSPISlave(SPI1, miso, mosi, sck, cs, spimode);

void setup() {
  Serial.begin(115200);
  mySPI.onReceive(myFunc);
}

void loop() {
  delay(1000);
  Serial.println(millis());
}

void myFunc() {
  Serial.println("START: ");
 // uint8_t arr[2] = { 0x11, 0x22 }; // don’t need that in my case
 // uint8_t i = 0;
  if (mySPI.active()) { //that’s the important change while-> if
    if (mySPI.available()) {
      mySPI.pushr(0x00); //just return null
      Serial.print("VALUE: 0x");
      Serial.println(mySPI.popr(), HEX);
    }
  }
  Serial.println("END");
}

@tonton81 Thank you for your great library! It helped me a lot!!
 
Status
Not open for further replies.
Back
Top