im going to redesign the spi controller, the command headers will be 16bit instead of current 8bit with 16bit transfers
i already started a barebone slave setup ready for data input and got a led toggling on the slave (after valid crc check) in a tight 20ms loop followed by changing it in the IDE to 0ms gives the led a nice steady glow while CRC validations are still flooding debugging console. later on i will strip down the master end to a bare minimum as well for a redesign as well
after the master strip down, ill tackle a handler setup for the user as well as a new constructor for the master
probably before the weekend hopefully you can start trying stuff. i will also try to get the slave end as a library as well so the sketch can be dedicated to the user, and what i might do later on is add/make sure
bi-directional support for cross-SPI implementation
teensy 3.5/3.6 teensy3.5/3.6
SPI2 ————————————> SPI0
SPI0 <———————————— SPI2
this will hopefully be a master-master design using the same library, and allow each one to control each other, at crazy speeds!
PS:
heres an uploaded video of the 20ms and 0ms tight loops with CRC verifications flooding the slave debug console
https://www.youtube.com/watch?v=sog8Z6UPT8o
The camera doesnt do justice for the speed of the led, as we all know, but it's super fast, with the console going nuts with flooded CRC validated packets
The SPI buffer on the new spi controller code will be set to 1024 by default, the data packets will be same as the ESP project
0xAAAA, 0xBBBB, 0xCCCC, 0xCCCC, 0xCCCC, 0xCCCC, etc....... -> 0xDDDD
AAAA will be a 16 bit header
BBBB is length of command data payload
CCCC will be data, depending on the transfer handling of the function, it will be filled with either 8 or 16 bits, and handled same on other end
DDDD will be the checksum
theres 2 point check for end of length and end of buffer, when either is reached, the buffer pointer is reset and all further SPI0_POPR are dropped until next transaction.
The idea here will be when a command is sent that requires a response (return variable per say), it will start pumping 0xFFFF packets to get the SCK line pumping while the data is ignored at slave incomming end, the slave can push the data in the register when it finally gets it and the data will flow back to the master for capture, at which point, the line is deasserted and continued. So this gives the slave enough time to finish it's processing depending on the function called to return data, while the master helps it push the data out.
oh yeah! I just had a new idea of how im going to implement an async callback for the master end when a user sends data to a slave and doesnt want to wait, the callback data will be queued at the slave, eventually when events() hit (just like the ESP), events will check for a callback queue size, if there are queues, we wont tie up the SPI port to drop from an ISR into a handler, instead my idea is as follows:
1) The MASTER sends data to the slave, saying "Hey, whats the time!?"; and deasserts the line and continues the loop();
2) The Slave has the data ready, so it queues it up into a vector queue and continues it's own loop();
3) Master makes it's trip over the events() in loop, and requests a queue size, slave immediately responds "I have 3 items in queue!"; The master dumps the 3 remote queues into it's own local queue buffer and deasserts the line, giving the slave's SPI ISR some rest while it continues it's own loop(); Right after the line deasserts, the handlers are called immediately and start processing. If a handler contains a function in the scope of this spi_controller library, further callbacks in the Master's queue are stopped dequeing pending function completion, then on next round trip in loop, if no functions are pending, it processes local handlers in queue and checks again if any others exist. This should allow callbacks that will not tie up the SPI bus giving both teensies more freedom