PIN Layout for the Teensy3.6 SPI Busses 0,1,2 can It be done like this?

Status
Not open for further replies.
B

Bastiaan

Well-known member
Hello I was wondering, Pondering and are in need of some experience with the SPI busses, and Pin Layout teensy3.6.


I am thinking how to combine various SPI busses to use the LTC2440, and the AD5680 DAC 18bit, with a ST7735 Monitor. I would like to combine these components to show values on the screen ST7735.

however by desigining the board I would like to ask which Pins I can use for the Software SPI.
The problem is that I have to rethink a design without crisscrossing the whole pcb board, using a CNC Cirqoid CNC mill.

I would like to use the Three busses SPI0, SPI1, SPI2.

would the following configuration be appropriate or fast enough or do I get a conflict?

can I use for the SPI0 pins:
0,1,2,3
SPI1 Pins:
4,5,6,7
SPI2 Pins:
8,9,10,11

Or do I hook up everything to 4 pins, and Chip select the components?

would this be possible for these components AD5680, LTC2440 and ST7735?

many thanks for reading my post.

Best

Bastiaan
 
Last edited:
Would It be possible to use one bus and multiple Chip Selects?

CS_TFT =on pin 6;
MOSI_ALL =on pin 7;
MISO_ALL =on pin 8;
CS_LTC2440=on pin 9;
CS_AD5680 =on pin 10;
TFT_DC_ =on pin 26;
SCK_ALL =on pin 27;
CS_TFT=on pin 6;
CS_TFT=on pin 6;
CS_TFT=on pin 6;
CS_TFT=on pin 6;
 
Presumably if you are doing SPI in software (sometimes called bit-banging) you can use any pins you want. However performance is likely to be slow.

However, if you want to use the faster hardware SPI on the Teensy, you have to use fixed pins for at least MISO, MOSI, and SCK. On the 3.6, there are 3 hardware SPI buses:
  • The main SPI bus has MOSI on pin 11, MISO on pin 12, and SCK on pin 13. You can also use the alternate pins if you call the appropriate setup functions (alternate MOSI on pins 7 or 28, alternate MISO on pins 8 or 39, and alternate SCK on pins 14 or 27). The main SPI bus has 4 word FIFO (first in, first out) hardware queues to help speed things up.
  • The second SPI bus has MOSI on pin 0 (alternate on pin 21/A7 {edit June 14, 2018}), MISO on pin 1 (alternate on pin 5 {edit June 14, 2018}), and SCK on pin 32/A13 (alternate on pin 20/A6). The second SPI bus has a 1 word hardware FIFO queue.
  • The third SPI bus uses the solder pads underneath the Teensy, with MOSI on pin 44 (alternate pin 52), MISO on pin 45 (alternate 52) and SCK on pin 46 (alternate 53). I believe the third SPI bus also has a 1 word hardware FIFO queue.

Now for most devices, you can use any pin for CS (chip select). However there are some devices (notably displays like the ST7735) that have special optimizations if you use certain hardware pins for CS. Some devices also use a DC (data/command) pin, and you would need to select the DC pin also from the list of supported CS pins. The special hardware CS pins are:
  • For the first SPI bus: pins 9, 10 {edit June 14, 2018}, 15/A1, 20/A6, and 21/A7.
  • For the second SPI bus: pin 31/A12.
  • For the third SPI bus: pins 43 or 54.

Since the second SPI bus only has one hardware CS pin, it means you can't use it for ultra-fast operation on devices that need both CS and DC (like the ST7735).

Ideally, each of your SPI drivers should use SPI transactions. See the documentation for more details (note, it doesn't cover the second and third SPI ports on the 3.6):

If all of your SPI devices support SPI transactions, and you use the appropriate CS/DC pins for the devices with special optimizations, you should be able to put all of your SPI devices on one SPI bus.

Note, if you use libraries, they tend to only use the first SPI bus. You would have to edit the library to use SPI1 or SPI2. There are discussions to make this more user friendly (see KurtE's postings about SPIN), but so far, it can be hard to use the second or third SPI buses.
 
Last edited:
As Michael mentioned, there are three hardware SPI busses, which you can and probably should use if possible.

A few thoughts:

a) you can typically be able to use multiple devices on the same SPI buss. Especially if they have libraries that are well behaved and use the Begin/End transactions. Each device needs it's own chip select pin to tell it that the data is for them. For the majority of cases, the CS pin can be any digital pin. Only if the device has a driver that uses the hardware queue (pushr/popr) does it need to be one of the hardware CS pins for the particular buss.

b) The majority of drivers for devices that use SPI are hard coded to only work on SPI (buss 0). So in most cases you will need to modify the library to the buss you wish to use. I have done some work (SPIN library) to make a library for the Teensy which allows me to pass in which buss to use (Different SPIN objects) and I have modified some libraries to have a SPIN version... Works fine, but I would like to make this support more Native. So I am in process of trying to rework the SPI library to support the 3 SPI objects with one class (like Arduino M0 devices), such that maybe more libraries will be updated to support the different busses. But this may or may not get completed and then may or may not be accepted into Teensyduino....

c) As Michael mentioned, some drivers are setup to support the native SPI fifo queues of the T3.x processors. First was ili9341_t3 library. Some of these are setup to require 2 hardware CS pins. One for CS the other for DC. I have in my own stuff made versions that maybe only require one hardware CS pin (on the DC pin). This helped me be able to use ili9341 on SPI1 which only has one unique SPI hardware pin (unless you use pins associated with SDCard). This is in my ili9341_t3n library I found very little differences in performance as the CS pin pin typically was asserted before we output anything (at time of beginTransaction) and was un-asserted when we were going to end the transaction and again we waited until the queue was empty anyway...

d) I would probably breadboard your setup first before making hardware to see what works well

Kurt
 
Tx for the replies, Kurte and Michel Meissner,

that helped a lot in getting rid of uncertainties,
The Synchronizing the Busses sound pretty complicated...

What I could not figure out from both replies is that:
So using SPI0, SPI1,SPI2, Simultaniously Dont achieve more speed if the devices are hooked up on separate busses? Because of the FIFO0,FIFO1,FIFO2, different "word" processing?

I just tried the st7735, which works fine:) tx for that:) always happy with blinking tft screens:) now the rest.
Are there things to keep in mind with the hardware,
like resistors placement, voltage divider at the end of the buss for the SPI busses? I read some stuff about this, I am just uncertain if it is required or not.

Is a word 32 bytes in one go? Or does it send 32/4 over the words, then outputting it fifo fashion? That's probably a lot of data..

So a 32bit can be send directly if a cs is made high, make it low if data has arrived, use a other cs pin for putting on the screen, and use the ad5680 to do something afterwards

Sincerely yours Bastiaan
 
Last edited:
You are welcome,

Sorry I missed your follow on questions.

Does speeding up the stuff across the different SPI busses speed things up? The simple answer is it depends ;)

For the most part if you are using the standard library like SPI, the answer for the most part is no. Why?

Most of this code is setup to do things like: SPI.transfer(x) or at best SPI.transfer(buf, cnt).

The problem is these functions will not return until the operation is completed. So doing this on three busses does not change much.

However if you can setup to use the hardware through DMA, like Franks (or my prototype) ili9341 drivers have support for, then yes having these off on their own SPI buss can speed things up.

You also in theory could do your own SPI code, that for example if you had two sensors that you wanted to communicate with on two different busses. You could have special code that pushes things on both SPI queues (PUSHR), and monitors both return queues (POPR) and both of these queues working simultaneously.

The SPI queues, can handle 8 bit or 16 bit data output for each FIFO queue entry. So your choice on how to send. If you use the:
SPI.transfer(buf, cnt) method, the code will try to output using 16 bits at a time for queue entry. Again up to you on how you do this. But if you are sending from one SPI device to another a 32 bit value, you need to be careful with byte orders (are they the same on both sides?) if not you need to setup convention on how it is sent and one side may have to repack it up to be a proper 32 value.

Not sure what you are asking about CS pins. Some devices expect CS pin to either change or stay asserted depending on operations. Again not sure what you are needing.

Hope that helps
Kurt
 
Hey Kurt,

thanks for the reply, it allways depends. Ill try the code from the LTC2440 from Linear Technology in combination with the Saint smart GPU2 on SPI.
They offer a complete solution on SPI with a oscilloscope, which is exactly what I need, I just would like to read out the LTC2440 shoot the information in to the teensy3.6, and print it on the Saintsmart Scope, I would like to record Pulses from 30ms, at 50V+- differential. of course in a tradeoff between sacrficing speed against resolution.

http://forum.arduino.cc/index.php?topic=191230.0
is an example, which is much clearer and filtered. what I noticed as well is that the max speed of the internal oscillator is set to 9.24MHz, would it be more approriate to use a crystal oscillator?
 
Thanks for the helpful post! However, I think there is a typo in alternate pins listed by MichaelMeissner above, with alternate pins listed for MISO and MOSI swapped. According to the pinouts shown here, the correct alternative pins are:
MOSI1: alternative pin 21
MISO1: alternate pin 5

Assuming the pinouts linked above on PJRC site are correct?...
 
jonatmudd said:
Thanks for the helpful post! However, I think there is a typo in alternate pins listed by MichaelMeissner above, with alternate pins listed for MISO and MOSI swapped. According to the pinouts shown here, the correct alternative pins are:
MOSI1: alternative pin 21
MISO1: alternate pin 5

Assuming the pinouts linked above on PJRC site are correct?...
Click to expand...
Yes, I had a typo. Thanks for catching it. I fixed the post.

I also had the fast CS pins wrong (it should be 9, 10, 15/A1, 20/A6, and 21/A7). I also updated the post.
 
Status
Not open for further replies.
Back
Top