Project: SPI_MSTransfer

Crazy. BTW stop showing off with your French - you are making me remember too far back to high school French. Believe it or some of words I still get some of it and can guess at the rest ok. :)
 
Hey, did you know you could piggy back 2x 3.2's, pins 2,11,12, and 14 line up for SPI0 master and SPI0 slave :p

same could be done with a 3.2/3.5/3.6 piggybacking a 3.5/3.6/3.2 for SPI0 and SPI1 ports

that could be beneficial for teensy shields hehe

with long headers, you could easily share SPI0 and SPI1 busses between 2 slimly stacked 3.5's or 3.6's which not only have bus connections directly linked, but power and ground sources as well

for about the size of a small chocolate bar:

IMG_5614.jpg

you could have 4 slaves stacked on top of a master lol :)

then again, after the 2nd slave, you'd need to start snipping some jumpers to run a wire to a different CS for each slave
 
Last edited:
you are definitely a gluten for punishment tonton81. :) I am sure someone is going to try it just for sake of doing it :)

Ok now for the good stuff. The good news is that you guys finally got me to solder up a T3.6 and start some testing with it. I flashed the master, same as used for the T3.5 to the T3.6. No changes made to LC - since it was already flashed.

More good news is that it is happily sending F&Fs and receiving the message from the slave without an issue just like in your youtube video. :)

I made absolutely no changes to the wiring, just removed the T3.5 and dropped in the T3.6. So I guess the problem is somewhere in the library code for the T3.5. I'm going to try the T3.5 again but maybe run it at 24 Mhz as a test? Should make any difference, but who knows

Mike
 
Yes, OK, You are right, on the T3.5 no communication with 3.2, did a swap
So tell me

The 3.5 worked with the LC but not the 3.2?
 
Ok. Here we go.

1. T3.5/T3.2 works fine no problem. So my T3.5 is fine, so nice try :) T3.5 at 168Mhz 3.2 at 120Mhz with 300000hz.

Now for some really interesting news. I got the T3.5/LC combination working without a problem. T3.5 at 168Mhz, LC at 48 Mhz, and now for the key parameter - GPIO2 transfers at 100,000 hz. Haven't tested any higher, but this speed works. Other than a few startup OT's since I plugged the master in before the slave it is happily chugging along.

Now, why the difference I don't know - found it out by accident - I tried the 3.6/LC at 400K and saw the same behavior (start stops), lowered it back down to 300K and all was good. So I decided to try that on the 3.5/LC combo.

Mike

EDIT:
but the LC worked?
Before I made the change to GPIO2 speed the T3.5/LC combo did not work for 2 way sends.
 
I'v used same sketches for

T3.6 -> LC
T3.6 -> 3.2
T3.5 -> 3.2

4MHz and 300KHz, I don't know why only you were affected, i wasnt ehhehehe

btw, t3.5 here at 120mhz, 3.2 at 96mhz :)

gpio2 transfers here are working at 300khz.....

just remember
gpio2, toggle, events must be 300khz, transfer can be 4mhz in f&F mode only
 
Only I am affected because I tested:

T3.5 -> LC

Your other combos worked for me too. Try that combo at 300k and let me know if it works :). Then its me.
 
Works if you change to 100k instead of 300k:

Works:
Code:
SPI_MSTransfer teensy_gpio2 = SPI_MSTransfer("Serial", SPI_MST_CS, &SPI_MST_BUS, 100000 );
Doesn't work:
Code:
SPI_MSTransfer teensy_gpio2 = SPI_MSTransfer("Serial", SPI_MST_CS, &SPI_MST_BUS, 300000 );

You see, Je ne suis pas fou, yes I had to look up crazy. :)

Mike
 
Mais je le fait ca, ca marche pas. C'est ton faute ! :p

EDIT, its gotta be my wiring, i threw the 3.6 back and nothing happening on lc hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
 
No its working now, hey wanna laugh, i think the IDE has caching issues, im swapping the versions around and it seems to be writing an older HEX to the LC than the library i swapped in, im gonna restart the IDE

no, what the heck

im rebooting. brb

ok now this is upsetting, its as if the LC is ignoring my upload, it looks like it went, but it didnt
 
Just as a FYI I have been using Ty Commander to monitor the serial output instead of the IDE monitors.

EDIT:
Try flashing with blink sketch first, then reload the slave sketch. I do that sometimes when the Teensies start acting funny - it like resets it.
 
It's not the monitor the issue, the monitor works, it shows me its running a slightly older library i flashed before the LC patch
It just taking the upload in one ear, and out the other...

EDIT, since this mess got me started, I went ahead to update to beta4 from beta3. It's working now lol

EDIT, ok confirmed 300khz works on 3.6 -> LC, 3.5 pauses, bringing 3.5 down to 100KHz gets rid of the pauses...

EDIT
T3.5 120mhz 100khz OK, 4mhz f&F
T3.5 168MHz 200khz OK, 4mhz f&F
T3.5 120mhz 200khz OK, 4mhz f&F
But your right, 200 would be max for a T3.5 to control a TLC, except the F&F's. Don't forget the DSPI interface on the kinetisL is a different animal. I can only conclude that the LC has issues with continuous traffic, especially with a single register harvesting input and output data, I would imagine the LC needs time to switch the register from in to out or back and requires more time to do so, one user reported on another forum that a similar chip needed 4x the delay just to work properly..., we're not using delays (much) except between SPI transfers, so we're lucky to get this far, i guess :p
 
Last edited:
It's not the monitor the issue, the monitor works, it shows me its running a slightly older library i flashed before the LC patch
That makes no sense. You should you got the right version in the library folder that its going to and not the older version? You could try deleting the existing hex files completely and then recompile fresh?
 
OK, Mike, take this as an example
Take your T3.5 master, connect it to a T LC.
All good? Now, remember where you edited the 5uS delay section? (remember I mentioned increasing delays?)
Change the Value to 25uS for both ::_transfer16 functions.
You will now see that 300KHz works without delays....

This, is proof, that the LC needs time to switch the 8bit register from read to write or write to read mode before the next byte shifts in.

EDIT, the max I can push with this is 300KHz now

at 10uS 300KHz is working fine, so instead of 5, we should make 10 default
 
Guess a little change didn't do anything but a big change 5-25 makes all the difference - will make the change and let you know in a few minutes.

EDIT:
Tried 25us and 10us. Both settings with 300KHz still not working for me. Goes in fits and stops. PS> didn't reflash the slave since only the master changed.

EDIT2: with 10us, and 250KHz works fine no issues. at 10us and 295KHz no good.
 
Last edited:
No its working now, hey wanna laugh, i think the IDE has caching issues, im swapping the versions around and it seems to be writing an older HEX to the LC than the library i swapped in, im gonna restart the IDE

no, what the heck

im rebooting. brb

ok now this is upsetting, its as if the LC is ignoring my upload, it looks like it went, but it didnt

That is the value in having this printing in setup - TIME changes on each compile to know it uploaded: Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);

Closing the IDE is all that is needed to disassociate any cached compiled code.
 
Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
Yeah that's pretty nifty - started leaving it in so I what I loaded and time.

Back to my problem with the T3.5/LC. I reflashed the slave and master and tried it again at 10us. No good. Only thing that works for me is changing the speed to 250KHz. Then it works fine.

You sure you at 300KHz on gpio2?

Here's something else I just noticed - the OT's are climbing:
Code:
F&F (OT=4562) OT_CALC==700  micros() _time==768
F&F (OT=4563) OT_CALC==700  micros() _time==766
F&F (OT=4564) OT_CALC==700  micros() _time==767
F&F (OT=4565) OT_CALC==700  micros() _time==768
 
yes, 300khz gpio2 using 10uS spi transfers, OT's are climbing because of the 10uS delays

20 dwords + ~ 4 overhead == 24 * 10uS gaps
 
Just don't know why I can't get to 300Khz, can only run up to 250KHz. Think I will add some 10k resistors to cs and MISO.

EDIT: To be honest I think I would keep the delay to 5us max and just reduce the gpio2 transfer to 250KHz. Does that make more sense.
 
Last edited:
Welp, I got all-around 4MHz working on LC. What? 4MHZ.....all.....around......events, leds, F&F's......

Mike, try now?

Code:
[ATTACH]13819._xfImport[/ATTACH]
 
Back
Top