it all depends on how long your interrupts are, and the speeds of the SPI obviously especially when pushing data. if the slave interrupt is not ready to receive because of another interrupt you may lose data. Your...
this library setups only one LPSPI as slave. Even if you managed to setup 2 or more slave on LPSPI you'd need to be able to manage the 2 ports simuletaneously, and if interrupts are involved, good luck
its one byte/word at a time, not grouped. if you want the slave to send more data you need to basically send dummy bytes/words to push the data out of the slave, so you need to handle that as needed
yes but the master end *should* work on any other arduinos, you'd have to test as it uses the standard SPI library for master. The slave end is only working for the Teensy 3.x/LC/T4.x end. The patch is if you still want...
SPI_MSTransfer_T4 is a 2-way daisy-chainable data transfer utility. It includes the slave and master headers and source files, with simple examples.
if you prefer to keep a teensy4.x as master using SPISlave_T4 i...
if you are using a T4.x master there is a slight bug in the DSE gpio bits, which is fixed in SPI_MSTransfer_T4. Other master controllers don't seem to have this issue. Also for your common ground don't use the GND pin...
what i always do (my own preference of course) is setup a scoped millis() near the action you want to do, so in the loop i would put:
void loop() {
static uint32_t coolant_timer = millis();
if ( millis() -...
you shouldn't need to strip mailboxes down to one using msg.seq = 1, it will only output to the absolute first mailbox. also you don't need events() in loop if you want direct firing interrupts, but that's optional. As...
the master 4.x need a patch for the DSE bits, check out the commits for SPI_MSTransfer_T4, this only affects the master, just make sure your ground is the one next to the 5v pin (not near pin 0)
Hardware only sends transmission once but only if it is successful. It will retry until a valid ACK occurs and then it can continue to next frame. Be sure a node is on the bus to ACK it and check the wiring to make sure...
i don't see POPR used in your last code, both of them must be used. if you dont care for POPR (receiving) then flush it at very least:
(void)mySPI.popr();
for the 4.x slave check if you're using the GND beside the 5v pin, and not the one beside pin 0
there is no buffer, this is a fixed register in the SPI hardware
POPR receives byte from bus master
PUSHR stores byte...
thats the master, have you tried the master slave examples as a start to make sure your wiring is okay? the examples do work so they will rule out if it's a software or hardware connection issue
do a mailboxStatus(), if it still stays there after you stop transmitting, verify your baudrate, terminations, transceiver connections. it will stay in the mailbox and software has no control over that, it sits there...