I2C, SPI, ESP webSockets controller for teensy

Status
Not open for further replies.
tonton81 said:
Before I did the pinMode function, I used it to create a random generated 100 byte array validated by CRC to slave, and return an array back, of same size and validation, without running remote functions as a test
Results: ?

4MHz 100 bytes -> slave & slave -> master 100 random bytes, CRC both ways, we're at 1270 micros
fire and forget array from master -> slave == 794 micros!
Click to expand...

Would be interesting to see what 24 MHz does to those 4 MHz times - 100 byte packet is a good test.

The current code where I was hoping to see improvement takes about 1.5 to 1.7 ms to float format USB output and leaves data pushing out the USB port after that.

If 24 MHz SPI can do a block transfer in 400 to 500 uS - it would be a real gain. As noted 'Master' is now feeding a PC on USB doing plotting. So that could be moved to the Slave USB where the Slave can use all its time to format the output and the Master could afford to double+ the output rate and still have more free time just by using one extra CS wire for SPI over the UART Serial now used for debug.

If the Master code were using DMA for the block transfer it wouldn't even hold up the Master that long. Using DMA may work better on Fire&Forget messages than the ACK messages?
 
yeah but i have no clue how to use dma, the test was with the ack receipt for guarenteed delivery before the forget part (which was waiting for response)
 
d: 133
p: 39

d == digitalread&write
pinmode == 39micros

8MHZ









d: 85
p: 28
24MHz




and fire & forget @ 24mhz 100byte array test ==> 384 micros --> digitalread&write combined toggling shows 85 micros!

SPISettings at 50MHZ for fire&forget of 100byte confirmed acknowledged receipt of array ==> 356 micros --> digitalread&write combined toggling shows 78 micros!
 
Last edited:
Friend of the Forum KurtE might be intrigued enough to offer guidance on DMA setup for the F&F messages when code gets posted. Or seeing your code and his work on the SparkFun Display he did may let me hack it up (for him to fix if it fails).

Numbers suggest 50-60 byte transfer will be perhaps 300-400 uS at 24 MHz which is good. And if the setup for DMA makes F&F truly F&F it would return to the code in <50 uS.
 
the dma would handle the acknowledgement receipt?
Yeah I think it's better we get better eyes on this while it's still in a newish state before adding more functions, trying to learn dma is out of my code knowledge :p
60 bytes looks like 228uS at 24MHz according to serial monitor

I should open a new thread and change the library name since it's technically a new project, and ill post the baseline library there, which currently has digitalread/digitalwrite/pinmode implemented for now.
later on i can work on cleaning up useless code, and redoing the constructors (perhaps add the MHz in the constructor rather than defining it internally.

and final decisions on a name?

(btw, licencing, documentation, etc is not there as you know, does it matter if there isn't? its not like this will run on a non-teensy board anyways :)
 
Final decision is yours - I'm horrible with names. My 'best' suggestion perhaps SPI_MSTransfer. The goal of the library is Master Slave Transfer - what the slave does with it is open.

Indeed start a new thread. If you get it stable with your current base that will be awesome.

If a DMA method can make it async that will be an addition that won't change the core code. Indeed - DMA would be easiest with NO ACK - that is why I suggested it for F&F usage. The DMA seems pretty robust though I'm not sure it is designed to write from one array and read from another with a single instance - and then the code would need to return to Verify ACK versus NAK for resend. But I know it can work on 75 KByte 320x240 pixel ILI9341 full screen or on the smaller SparkFun TeensyView OLED 128x32 because of FrankB and KurtE.
 
Nice :). I can post on my GitHub if you don't have one - or if you do I can manage updates if you have one and we both get write access,
 
Status
Not open for further replies.
Back
Top