Project: SPI_MSTransfer

Hello Paul & all,
I purchased and appreciate hundreds of TEENSY 3.2 for professional use, and at present, delivery delays from TENSY 3.2 suppliers are exploding. (about 15 April !).
But TEENSY 4 and 4.1 are largely in stock, not sold. Why ?
I think I have an explanation : Although the TEENSY 4 and 4.1 have very interesting speed power, they lack compatibility with previous models.
Mainly concerning the 8 bits parallel Input-Outputs ports, who no longer exists in TEENSY 4.X.
personnally, I purchased only 1 4.0, and don't intend to purchase more, only for this reason. It's really a pity.
I don't want to use SPI complex and unusefull InOut process, which introduces large EMI risks for very high speed serial Input Output.
I mentionned this lack in several posts, without any positive result.
It was so easy to respect the previous pin functions. Remember that the pins used for unusefull extra memories could have been easily used for 2 parallel ports.

Second remark : I don't understand why PJRC don't design a professional video board, as the Techtoys HDMI board, unfortunetely unavailable now, or the Gameduino, which runs hardly with a 4.0 without standard touchscreen input. There should be a huge market for such boards. With available components.
Best regards,
Pascal Leray

Well you can still use parallel ports on the Teens 4. Personnaly never tried it but you might be interested in reading this thread: https://forum.pjrc.com/threads/57698-Parallel-IO-is-it-possible?p=216501&viewfull=1#post216501. You might be interested in this thread as well - https://forum.pjrc.com/threads/6822...-using-FlexIO?highlight=parallel+port+display
 
tonton81 said:

Well you know that I just couldn't resist so ... have some good news and some bad news.

Hooking up a T3.5 as Master and a T4.1 as slave I am duplicating what you showed
Code:
millis: 10541
BEEF F7 F8 F9 DEAD  --> Length: 5 --> PacketID: 514E
millis: 11542
BEEF F7 F8 F9 DEAD  --> Length: 5 --> PacketID: 6ADA
millis: 12543
BEEF F7 F8 F9 DEAD  --> Length: 5 --> PacketID: 1E2F
and on master T3.5
Code:
39682
State: 0

  Detected slaves: 
    Slave 1 --> ID: 0x1234
    Mode: Standalone

But if I try going from a T4.x to a T4.x all I get is this on the master:
Code:
  Detected slaves: 

    No slaves detected, check connections.

Think this is going back to the issue I was having with just testing SPISlave_T4? Just guessing here.
 
try swapping the MISO/MOSI wires, im using a LC as master, didnt have a 3rd t4 on bench for master, however the master uses the SPI class so it is a wiring issue im sure
 
try swapping the MISO/MOSI wires

One of the first things I tried but didn't work - will try again just as a double check.

UPDATE: Tried MISO-MOSI as well as MISO-MISO, 10-10, 13-13 and gnd to gnd. Still not working
 
Last edited:
try to add delay(5) at end of de_assert() of master tpp (like in t3 mst), when i ran my mcp23s17 code it was unstable without it, possibly the t4 is too fast with the toggles or not strong enough to pull pin between frames?

if the data is corrupt, slavedetection will still report no slaves attached

i just wonder why your t3.5 and my LC master work fine, but a t4 master doesn't, because if it aint connections, maybe it's something the way t4 handles transfer16 frames in SPI library?
 
try to add delay(5) at end of de_assert() of master tpp (like in t3 mst), when i ran my mcp23s17 code it was unstable without it, possibly the t4 is too fast with the toggles or not strong enough to pull pin between frames?

if the data is corrupt, slavedetection will still report no slaves attached

i just wonder why your t3.5 and my LC master work fine, but a t4 master doesn't, because if it aint connections, maybe it's something the way t4 handles transfer16 frames in SPI library?

Will give it a try. Again was seeing the same behavior with the SPISlave but there are differences and I did have to add in a 1us delay on deassert to get it to act as a slave so that might be the fix

It could
 
come to think about it, when i made the t4 tspislave library, i was still using a t3 as a sender

Think you should try it with 2 t4s - think the problem is that the callback (_spihandler) is never getting set at least in the SPISlave library. I thing
 
have to try with the new MST as that seems to have the data transfers and callbacks correct, just something wrong in the SPI on master
 
Ok was trying to do a bit more debugging. From the T4 and T3.5 master traces it appears for the slaveDetect both are sending out the correct request but for the response the slave (t4 in both cases) are responding differently. So I put in a few debug statements into the slave:
Code:
SPI_MSTransfer_T4_FUNC void SPI_MSTransfer_T4_OPT::SPI_MSTransfer_SLAVE_ISR() {
  static uint16_t data[SPI_MST_DATA_BUFFER_MAX];
  memset(data, 0, sizeof(uint16_t)*SPI_MST_DATA_BUFFER_MAX);
  uint16_t buffer_pos = 0, len = 0, checksum = 0;
  bool detectOnce = 1;

  SLAVE_PORT_ADDR;

  SPI_WAIT_STATE
    data[buffer_pos] = SLAVE_RDR;
	[COLOR="#FF0000"]Serial.println(data[0], HEX);[/COLOR]
    if ( (data[0] != 0xDEAD) && (data[0] != 0xBEEF) ) {
      SLAVE_TDR = data[buffer_pos];
      buffer_pos = 0;
      continue;
    }
    else if ( data[0] == 0xBEEF ) { /* slave detection */
	  [COLOR="#FF0000"]Serial.println("Slave Detection");[/COLOR]
In the case of the T4.1(Master) and T4 (Slave) the T4 is always reading 0xFFFF, not BEEF as its suppose to - but at least the ISR is getting called :)
 
Hmm, in the pic below, the LC master was at center, I popped it out and put another T4.0 there to be as master.
20220305_014718(1).jpg

At first I got like you, nothing much going on. But, as soon as I connected GND (between 3.3V and 5V pins) to each node (previously I used the one beside pin 0 (i left that still connected)), theres success?
20220305_015728(1).jpg

Note: nothing was changed in current code that is also on github, no delays were added either...

In the end, it is just picky on connections.....
Video:
https://youtu.be/EtKpD7hbhSo

it's weird how 1 ground pin is different for functional operation, considering the usb grounds are also common off same PC. Seems picky to me :)

If i leave the GND beside pin 0 connected to them all, but disconnect the GND between 3.3V and 5V pin, the data stops transferring. When I reconnect that wire, it resumes...
 
Last edited:
No that's completely to be expected - ideally you have a ground return running alongside every logic signal wire.
This is standard practice for high-speed logic, often you'll see every 3rd pin being a ground in ribbon cables and
similar to allow this. Many hobby boards have too few ground pins than is ideal (because it limits the total number
of useful signals).

At high speeds currents find the least-inductance route back, and if there isn't one you effectively have a loop antenna.
 
@tonton81

Ok I reset up so I am using 2 T4.0s:
Code:
MISO -> MOSI
MOSI -> MISO
pin 10 -> pin 10
CLK -> CLK
GND -> GND between 3.3v and 5v

IMG-0610.jpg

I rang out the connections just to be on safe side as well. Loaded up the MASTER on the T4 on the left and slave on the right. Both boards blink but:
Code:
621084
State: 0

  Detected slaves: 
    No slaves detected, check connections.

Not sure what else to try.

PS I also tried hooking up a Micromod with a T4.1 with no luck.
 
i dont see a gnd wire for one next to pin 0 as well, tried swapping miso/mosi pins as well? in my setup i never changed anything when i swapped LC to T4.0, just added 2 jumper wires for GND between 3.3V and 5v.
 
No that's completely to be expected - ideally you have a ground return running alongside every logic signal wire.
This is standard practice for high-speed logic, often you'll see every 3rd pin being a ground in ribbon cables and
similar to allow this. Many hobby boards have too few ground pins than is ideal (because it limits the total number
of useful signals).

At high speeds currents find the least-inductance route back, and if there isn't one you effectively have a loop antenna.

it works fine on T3.x/LC, a drop in T4 reacts differently?
 
i dont see a gnd wire for one next to pin 0 as well, tried swapping miso/mosi pins as well? in my setup i never changed anything when i swapped LC to T4.0, just added 2 jumper wires for GND between 3.3V and 5v.

That was the original configuration I tried without luck - the picture was after I was trying different connections. Also tried swapping pins without any luck.

Not sure what else to try. Running using the github version - you sure that the latest version?

EDIT: I did swap out one T4 with a T4.1 just in case but still no luck.
 
Last edited:
Problem with 2m cable

Hi,

I'm currently working on a projet where I wish to use SPI between two Teensy 3.5. I want to use a 6 cores cable (Vin, Gnd, MISO, MOSI, SCK, CS) of at least 2m. When I test it with short indivual jumper it works. But when I'm using a 2m cable, it doesn't work. I don't receive any signal at the end of the line. There is no short-cirucit in my cable. Do you have any sugestion what can I do ?
 
Hi,

I'm currently working on a projet where I wish to use SPI between two Teensy 3.5. I want to use a 6 cores cable (Vin, Gnd, MISO, MOSI, SCK, CS) of at least 2m. When I test it with short indivual jumper it works. But when I'm using a 2m cable, it doesn't work. I don't receive any signal at the end of the line. There is no short-cirucit in my cable. Do you have any sugestion what can I do ?

I am not an expert in SPI and never really tried SPI at high speeds over large distances - usually only a few inches. Doing a web search showed this: https://electronics.stackexchange.com/questions/163468/spi-max-distance which has a few recommendations including lowering the clock down to 100hz, there are other recommendations that are probably more difficult to implement - that link has a few of them.

Sure others can give you a more techincal explanation.
 
I did file comparisons with github and my files and they are identical, so it's definately connection issue somewhere

Also wanna point out, if I ONLY use the GND pin (between 3.3V and 5V pin) to FIRST slave ONLY, the 2nd slave works fine when receiving too.
If I disconnect that wire from first slave, both slaves stop receiving. So slave -> slave works but not T4 master without that wire, but master -> slave -> slave T3/LC work fine without that wire... I'm not a hardware guru so I cannot explain this phenomena :)
 
I am almost thinking about distracting myself from my other distractions and try it out...

Which sketch/libraries would I need to distract myself with?
 
I am almost thinking about distracting myself from my other distractions and try it out...

Which sketch/libraries would I need to distract myself with?

Examples on github, will work as is on a T3/LC master and 1 or more T4 slaves (daisy chained). Dropping in a T4 to replace the T4/LC stops functionality for everyone (except me if I add 1 more GND jumper from the 3.3V/5V pins side of T4)

Also wanna point out, if I ONLY use the GND pin (between 3.3V and 5V pin) to FIRST slave ONLY, the 2nd slave works fine when receiving too. both slaves dont have that jumper either. So if 2 slaves can talk fine without the additional ground, i have no clue what to say when only the T4 master requires it :)

If I disconnect that wire from first slave, both slaves stop receiving. So slave -> slave works but not T4 master without that wire, but master -> slave -> slave T3/LC work fine without that wire... I'm not a hardware guru so I cannot explain this phenomena

https://github.com/tonton81/SPI_MSTransfer_T4/tree/main/examples
 
Hi,

I'm currently working on a projet where I wish to use SPI between two Teensy 3.5. I want to use a 6 cores cable (Vin, Gnd, MISO, MOSI, SCK, CS) of at least 2m. When I test it with short indivual jumper it works. But when I'm using a 2m cable, it doesn't work. I don't receive any signal at the end of the line. There is no short-cirucit in my cable. Do you have any sugestion what can I do ?
I would do the same job using Uart communication. If you want duplex (out and back at the same time) use two serial ports on each Teensy.
T1 RX1 to T2 TX1
T1 TX1 to T2 RX1
T2 RX2 to T1 TX2
T2 TX2 to T1 RX2.
Needs the same amount of cable cores if including Vin.
Since Transmission and Reception are done in the background there should be no problem with data collisions.
 
2m? most likely reflections in the cable, inline termination can help with that, and reducing SPI speeds, or like BriComp suggested using Serial
 
Back
Top