Using a display with the second SPI lane (Teensy 4.1)

G

Gabriel M

Member
I am working on a project with the Teensy 4.1 again, and I am using the first SPI lane to connect to another Teensy 4.0 board, but I need to connect my SPI display to it's own SPI lane, SPI1. The Teensy 4.0 connects to Teensy 4.1 pins 10, 11, 12, and 13, which are the standard pins for SPI0. I was wondering if anyone knows how I can connect my SPI display to SPI1 and also what pins, because on the pinout diagram, there are two MISO1 pins, and also two CS1 pins. If anyone is wondering, I am using specifically the Adafruit_GFX, Adafruit_ST7796S_kbv, and SPI libraries for my display. I know it works perfectly fine on an Arduino, but I used an Arduino for prototyping.
 
@Gabriel M: I am using a different display (RA8875), and since it is known not to always be well behaved with other devices on the same bus, I am using the SPI1 interface to connect it to my T4.1, so should be somewhat equivalent to your setup. My working setup uses the following:

Code: 
MOSI1 : D26
SCK1  : D27
CS1   : D38
MISO1 : D39

Whether the ST7796 driver allows you to specify the SPI1 interface is another matter . . . unfortunately, I have no experience with that.

Hope that helps . . .

Mark J Culross
KD5RXT
 
I'm messing about with the ST7796 driver, and it tries to infer the SPI bus in use from the SCK and MOSI pins specified in the constructor. I'd guess it should be fine if you use the "primary" pins (black on the pinout card), not sure about the "alternate" ones (in grey). Disclaimer - I haven't tried any of this!
 
kd5rxt-mark said:
@Gabriel M: I am using a different display (RA8875), and since it is known not to always be well behaved with other devices on the same bus, I am using the SPI1 interface to connect it to my T4.1, so should be somewhat equivalent to your setup. My working setup uses the following:

Code: 
MOSI1 : D26
SCK1  : D27
CS1   : D38
MISO1 : D39

Whether the ST7796 driver allows you to specify the SPI1 interface is another matter . . . unfortunately, I have no experience with that.

Hope that helps . . .

Mark J Culross
KD5RXT
Click to expand...
Hey, your pinout worked! I would like to say thank you for the help. I managed to get the Teensy to move the correct display data to SPI1, the second SPI lane.
 
h4yn0nnym0u5e said:
I'm messing about with the ST7796 driver, and it tries to infer the SPI bus in use from the SCK and MOSI pins specified in the constructor. I'd guess it should be fine if you use the "primary" pins (black on the pinout card), not sure about the "alternate" ones (in grey). Disclaimer - I haven't tried any of this!
Click to expand...
Yes, you are correct. I got my setup to work, but Adafruit libraries for ST77XX displays typically default to SPI0 (the primary SPI lane, pins 10, 11, 12, and 13) this is because this makes the driver universal for boards that have either one, or more SPI lanes, like an Arduino UNO or Teensy 4.1 board. You can use the alternate ones as well. I did use the alternate ones (the pins in grey) like MOSI1 and CS1 which are pins 38 and 39 and it worked without any code specifying to switch the SPI route.

You can see the code I have below:

Code: 
Adafruit_ST7796S_kbv display(&SPI1, TFT_DC, TFT_CS, TFT_RST);

The "&SPI1" part must be put in if you have multiple SPI lanes on your board, and you want to use a specific SPI lane other than SPI0, which is the default lane. So if you are wiring to SPI0, or just the default SPI pins on your board, whether it is an Arduino, ESP, Teensy, or whatever, then you can just write:

Code: 
Adafuit_ST7796 display(DC, CS, RST);

But if you want to wire your display to the second, or third SPI lane on your board (Let's say you are using a Teensy 4.1) then you would put the "&SPI1" before listing the display pins. Though this worked for my specific library, I am not 100% sure if this works for other adafruit display libraries. But I want to presume maybe it does. I can definitely help you on that if you want.
 
I started by aiming to break up the long SPI transactions into short chunks, so the display doesn’t hog the bus when it’s shared with other hardware needing regular access (audio being the known candidate and test case). That’s essentially done.

My current tinkering is to do the same for the asynchronous DMA-based updates from a frame buffer, plus make it possible to do those for an area less than the whole screen.

Not particularly needing help just yet, progress is only slow due to other calls on my time! I’ll report in when I’ve made useful updates, on the above thread.
 
You must log in or register to reply here.
Back
Top