Project: SPI_MSTransfer

Ok - started the process of updating the library. Looks like this
Code:
      while ( !(GPIOD_PDIR & 0x01) ) { // wait here until MASTER confirms F&F receipt
        if ( SPI0_SR & 0xF0 ) {
          SPI0_PUSHR_SLAVE = 0xBABE;
          if ( SPI0_POPR == 0xD0D0 ) break;
        }
      }
      SPI0_SR |= SPI_SR_RFDF; return;
should be changed to
Code:
	  while ( SPI0.active() ) {
		if (SPI0.available()) {
		  SPI0.pushr(0xBABE0);
		  if ( SPI0.popr() == 0xD0D0 ) break; ;
		}
	  }

Man forgot how intricate the library is.
 
I always like the ability to send packet data over SPI or getting data from other I2C devices etc. Most of my robot projects are on hold and I have been mixing and matching T3s and T4's. Thing with me you don't miss it until you need it. To me it was like EasyTransfer for serial/i2c but using SPI. Adds additional options. Might help with sending data to the slave device as well - At least for me I think there is a use but that's just me. :)

PS> Forgot how much fun FLexCan is as well - was a while since I played with it but remembered quickly - I did get Can232 kind of working with FD as well in the other thread.

EDIT: the approach I was taking was just to see if it would work without too much rewriting of the basic library.
 
It was very well designed for fast transfers and data integrity verify IIRC?

T_4.x speed will be as fast or faster than T_3.x can do - and more than a UART or other connect method.

... hi tonton81 :)
 
Ok - got most of the lib updated, I think to use SPISlave_T4. I did disable I2C for now on the T4 since have to go through it more to convert from i2c_t3 to just wire. Right now almost everything is compiling except I am not sure what to do with the watchdog timer. I can use your WDT_T4 library but not sure how to set it up in this context.

Any suggestions? I don't really see where the function watchdog(value is ever called) ?

Mike
 
After some mis-steps I finally got a T4 sending data to a T3.5 just using TVmaster on T4 and TVslave on the T3.6. Now the challenge is getting slave mode working on the T4 and not sure I can do it with the SPISlave_t4 library as it stands now. So now in the process of reading up on the slave mode for the T4 and looking at other examples :)

After that have to work on I2C.

@tonton81 - really neat how you got everything tied together in the library.

Cheers.
 
due to your interest, i decided to work on a new SPI_MSTransfer_T4, that also supports daisy chaining, so 1 CS for all modules. This will be interesting to play with, considering i am putting node IDs in the stream .

Should work standalone or daisy chained, hopefully it comes out well :)

right now i have both nodes identifying their own traffic, i have 2x T4 slaves daisy chained to a teensyLC sender, so im kinda juggling between 3 IDE windows and serial monitors :)

i dont know if it's possible or not, i might or might not be able to make it run data consecutively within the same assertion, just something to think about while it's still in blank stage of progress, that and daisy chained node detections :)
 
Last edited:
due to your interest, i decided to work on a new SPI_MSTransfer_T4, that also supports daisy chaining, so 1 CS for all modules. This will be interesting to play with, considering i am putting node IDs in the stream .

Should work standalone or daisy chained, hopefully it comes out well :)

right now i have both nodes identifying their own traffic, i have 2x T4 slaves daisy chained to a teensyLC sender, so im kinda juggling between 3 IDE windows and serial monitors :)

Sounds like you are having fun with this again like when we were doing uNav - you should try using TyCommander - easier to watch all the serial monitors as opposed to using the IDEs. Was actually very satisfying to watch the T3 blinking from the T4.

What I am kind of envisioning to use a T3x as a sensor hub or servo controller or a motor controller that can be controlled by a T4.x.

Sorry haven't been more involved with stuff but been sidetracked with other T4 stuff so getting back into it and remembering everything :)
 
What I am kind of envisioning to use a T3x as a sensor hub or servo controller or a motor controller that can be controlled by a T4.x.

The master code should be able to work on any teensy, only the slave requires special handling

Also note T4 slave has different handling than T3.x, the GPIO cannot be monitored in slave mode like T3.x, so a register is used instead to identify the end of the slave frame, when the line deasserts.
 
Last edited:
Pretty much. Noticed there are a few differences though:
1. SPI delays can't be zero otherwise you have problems so I set them to 1us and worked fine
2. On the T4.x there are no alt pins for SPI but you do have for SPI1 on the T4.1 SPI2 - you can use but.... As for the Micromod - really didn't look yet :)
3. No I2C_t3 support so right now not supporting it.

In my test I used SPI on a T4

Otherwise yep as a master the code is pretty much the same.

Yep - noticed the differences between the two when going through the slave code but really just starting to look at it - probably tomorrow - getting late for me now.
 
Just added slave detection: (detectSlaves())

If no slaves are connected:
Code:
  Detected slaves: 

    No slaves detected, check connections.

if one slave is connected on the chipselect:
Code:
  Detected slaves: 

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

if 2 or more slaves are connected to same CS in daisy chain mode:
Code:
  Detected slaves: 

    Slave 1 --> ID: 0x1234
    Slave 2 --> ID: 0x4567
    Mode: Daisy-Chained

So now the slaves, mode, and IDs are reported to help setup your slaves or if you forget their ID :)
 
Just added slave detection: (detectSlaves())

If no slaves are connected:
Code:
  Detected slaves: 

    No slaves detected, check connections.

if one slave is connected on the chipselect:
Code:
  Detected slaves: 

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

if 2 or more slaves are connected to same CS in daisy chain mode:
Code:
  Detected slaves: 

    Slave 1 --> ID: 0x1234
    Slave 2 --> ID: 0x4567
    Mode: Daisy-Chained

So now the slaves, mode, and IDs are reported to help setup your slaves or if you forget their ID :)

Great idea. And you know of course we will forget the slave IDs :)

Still can't get TSPI working by the way so put it away.
 
Nice Update Tony, wow - started 4 years ago!

yup and first time spi slave daisy chaining data transfer protocol on teensy :)

new code much cleaner now, master has it's own class file now. after I add gpio support (read/write/pinmode) i will post it on github, more features will not be added until we find some bugs through abusive testing:)
 
yup and first time spi slave daisy chaining data transfer protocol on teensy :)

new code much cleaner now, master has it's own class file now. after I add gpio support (read/write/pinmode) i will post it on github, more features will not be added until we find some bugs through abusive testing:)

Always doing firsts with spi transfer and add to that flexcan. And with the addition of being able to daisy chain definitely a first
 
Anyone up for some fun?
https://github.com/tonton81/SPI_MSTransfer_T4
:)

pinMode, digitalWrite, digitalRead added...

the slave's ISR wait states are centralized to a #define as well, so we can change them in a central location in case we backport T3.x models later on
Code:
#define SPI_WAIT_STATE \
    while ( !(SLAVE_SR & (1UL << 9)) ) { /* FCF: Frame Complete Flag, set when PCS deasserts */ \
      if ( !(SLAVE_FSR & 0x1F0000) ) continue; /* wait for received data */ \
      if ( (SLAVE_SR & (1UL << 8)) ) { /* WCF set */
#define SPI_ENDWAIT_STATE \
      } \
    }


..........


        SPI_WAIT_STATE
          (void)SLAVE_RDR;
          SLAVE_TDR = 0xA5A5;
        SPI_ENDWAIT_STATE


digitalRead/Write demo
https://youtu.be/24OTgqfHaOo
 
Last edited:
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
 
Video board: there may be a huge market but Paul's extremely busy. I also suspect he's not able to bypass chip-shortages any more than anyone else - designing a new
board with currently available components is not going to guarantee those components are available when it comes to mass-production time anyway.

I suspect parallel I/O is possible for the T4 (if there's not a library now, someone is likely to provide one - remember the previous generations of Teensy
took time to ramp up their library support too).
 
Anyone up for some fun?
https://github.com/tonton81/SPI_MSTransfer_T4
:)

pinMode, digitalWrite, digitalRead added...

the slave's ISR wait states are centralized to a #define as well, so we can change them in a central location in case we backport T3.x models later on
Code:
#define SPI_WAIT_STATE \
    while ( !(SLAVE_SR & (1UL << 9)) ) { /* FCF: Frame Complete Flag, set when PCS deasserts */ \
      if ( !(SLAVE_FSR & 0x1F0000) ) continue; /* wait for received data */ \
      if ( (SLAVE_SR & (1UL << 8)) ) { /* WCF set */
#define SPI_ENDWAIT_STATE \
      } \
    }


..........


        SPI_WAIT_STATE
          (void)SLAVE_RDR;
          SLAVE_TDR = 0xA5A5;
        SPI_ENDWAIT_STATE


digitalRead/Write demo
https://youtu.be/24OTgqfHaOo

You always know I am up for some fun but still neead to get coffee first and wake up :)
 
Back
Top