ST7789_t3 (part of ST7735 library) support for displays without CS pin

Hello, I tried using the latest update from github (the t4 rewrite branch). I currently have a Teensy 4 and a ST7789 screen wired up. I have tried both the CS and no CS configs, with the only other change being switching pin SCK to 14 instead of 13. So far I get no picture with the uncanny eye example (I get the backlight though). Can I confirm that SDA is MOSI according to this pinout? https://facelesstech.files.wordpress.com/2019/01/13_pinout.jpg
Maybe I'm missing something else, but I'm pretty excited to get this running!
 
Yes SDA goes to MOSI.

You will need to do some reconfiguration for your display though. The 7789 example is set up to use SPI and SPI1 as well as a 240x240 displat. If you are using only SPI with CS pins specified you will make sure you comment out:
#define ST77XX_ON_SPI_SPI1
and then in the config file adjust these lines for your display:
Code:
#else
  //CS  DC MOSI SCK RST WINK ROT INIT
   {0,  2,  26, 27,  3, -1,  0, INITR_144GREENTAB }, // RIGHT EYE display-select and wink pins, no rotation
   {10, 9,  11, 13,  8, -1,  0, INITR_144GREENTAB }, // LEFT EYE display-select and wink pins, no rotation
#endif
Think you get the idea - let us know if you run into problems
 
Thanks for the reply! I commented out the #define ST77XX_ON_SPI_SPI1 in the main sketch, and updated both pin 13s on the config to be pin 14. I'm still not getting any picture on the screen, although this is the first sketch I'm running since I got my Teensy 4. I have no light on the Teensy when initially plugged in, but when programming, I press the button on the Teensy and get a dim red light. From what I can tell, it appears to be uploading the code right. Also if it's important, I got all the ground and LED Cathode connected together for ground. I also have the power and LED anode paired together in the 3v pin.
 
Can you post a link to the exact display you are using and maybe a schematic/photo of your wiring to the T4. Have to remember that the T4 is not 5v tolerant. The adafruit display I have uses 3.3v and does not have a LED pin

Also I would try running the graphictest.ino sketch first before trying it with uncanny eyes.
 
I've been using these:https://www.aliexpress.com/item/329...rchweb0_0,searchweb201602_,searchweb201603_52
I've gotten them to work with a raspberry pi before, although this is my first time trying them on other hardware. I don't have anything wired to 5v, except the USB cable powering the teensy. I'll see if I can get a good picture of my wiring shortly.
Edit:
fG21AXS.jpg

GycBS70.jpg

For clarity's sake, wiring is, pins:
1,2,5,6,12 - Ground - Black
3,4 - 3.3v - Red
7 - D/C - White
8 - CS - Blue
9 - SCL - Green
10 - SDA - Yellow
11 - Reset - Orange
 
Last edited:
I believe they're the same as the adafruit ones, just without the board they connect to. This site seems to have a bit more on the wiring, but I usually just google ST7789 pinout to reference. https://facelesstech.wordpress.com/2019/01/27/1-3-screen-with-raspberry-pi/
I've updated my last post with pictures and wiring.
(On a side note, is there a way to handle the pictures better? spoiler tags didn't seem to work and the code tag made the section very thin)
 
Ok - lets start with your wiring:

Code:
Display - Pin Desc  - T4 (what you have)  - T4 what should be
1,2,5,6,12    - Ground    - Black    -  no problem
3,4               - 3.3v        - Red       - no problem
7                   - D/C       - White     - Pin 9       ---  ok this can be any digital pin
8                   - CS         - Blue       - Pin 10    ----  ok this is typical for CS pin
9                   [COLOR="#FF0000"]- SCL       - Green     - Pin 14    ---- SPI CLOCK IS ON PIN 13 not pin 14[/COLOR]
10                  - SDA       - Yellow   - Pin 11   -  Pin 11 so this is ok.
11                  - Reset     - Orange  - Pin 8     -  Pin 8 typical and what I am using

Also use a volt meter just to check your wiring to make sure you don't have any shorts.

So would say at a minimum you need to fix your clock wire. But I am a little concerned that the red light is on dim when you load the sketch. Just as check load the blink sketch and make sure the T4 blinks after rewiring and checking connections especially gnds and 3.3v lines.

Next I would run the graphicstest sketch to make sure wiring is correct.

Hope this helps
 
Are you sure you have enough power on the 3.3 volt line? That display may require more power than the Teensy can provide. You may need an external power supply.
 
I switched the SCLK pin to 13, the UncannyEyes example still did not work (after correcting config to use pin 13 again). However, I ran the scrolltest, and got garbled pixels (every pixel was a random color) This was not animated. The only change I made to the sketch was to switch the screen size to 240x240 (I think it uses ST7789 by default too). I'm sure the screen has enough power, it's a pretty low powered screen, though I tried powering the teensy with a wall port and got the same results. After a few power cycles, the "random" pixels appear to be consistant with what colors are where, giving me the same image each time.

Edit: also forgot to add, I tested for continuity from the ribon cable on the screen to the ports on the teensy, everything seems to be wired good without data pins shorting.

Edit2: got it to work! didn't realize the serial window needed to be up. (commented the while(!Serial) out to bypass this). Thanks for your help!
 
Scrolltest has issues with the ST7789 probably should delete that function but hoping to figure out how to readpixels from the display. Please try and run the graphicstest.ino sketch.

EDIT: did you check that you don't have any solder bridges - in the photo it looked like maybe you did?
 
the only bridges i have were for connecting the multiple grounds and the led to the 3v input. is there a separate folder for the graphics test? the only one i seen was for the ILI screen, not the ST ones. though the scroll test did seem to work flawlessly from what i could tell
 
the only bridges i have were for connecting the multiple grounds and the led to the 3v input. is there a separate folder for the graphics test? the only one i seen was for the ILI screen, not the ST ones. though the scroll test did seem to work flawlessly from what i could tell

Sorry - when I posted my question there were no edits in you post #261.

So - glad you got it working :)
 
I was doing some runs of uncanny eyes this morning on a Teensy 4.0 using the 240x240 Adafruit displays, one on SPI0 using the default 10 CS pin, and the second display on SPI1 using the default 0 pin for CS1. I'll post numbers later, once I've done tests of the various configurations I've run (Teensy 3.2 on 128x128 TFT displays, Teensy 3.5 on 128x128 OLED displays, Teensy 4.0 on 240x240 TFT IPS displays, Adafruit Hallowing M0 on a single 128x128 display, Adafruit Hallowing M4 on a single 240x240 display, Adafruit Monster M4SK on a pair of 240x240 displays).

I was thinking about adding the audio shield to get the SD drive (which also uses pin 10). So I moved the CS pin from pin 10 to pin 22 to see what the degradation would be, and I was surprised that there was no degradation in using something other than pin 10. I had async updates on and I was using the ST7735_t3 library from the 1.48 release. Does that mean with the T4, that unlike the T3 series, we don't need to pick CS and D/C from favored pins?

Has anybody actually run another SPI device along with the monitor? Do you need to insert the appropriate beginTransaction endTransaction calls in key places in the monitor code? Or do I have to turn off the async support? Obviously if you are sharing the SPI bus, you need good pull-up resistors on the CS/DC pins. Also obviously, you can't use the no-CS pin cheapo displays on a shared SPI bus.
 
Last edited:
Timings for different uncanny eyes

This morning I decided to do timing runs for all of the uncanny eye variants I have setup. Note, these don't necessarily have the same options compiled it, and they are using somewhat different base sources. The only weird thing is the Teensy 4.0 with 1 eye is reporting 15-16fps, while 2 eyes tends to be 30-32 fps.

The T3.2 and T3.5 use the traditional approach of 1 SPI bus with 2 displays on it. I haven't tried using the second SPI bus on the 3.5.

I found I could not use the T3.2 with the original sources and have the display show up, but I used my hacked up sources setting the SPI bus to 24Mhz.

For the Teensy 4.0, I did define USE_ASYNC_UPDATES, and I see from the serial monitor that is using the frame buffer for both displays. I am using the ST7735_t3 from the Teensydunio 1.48 release. I am using 2 separate SPI buses.

Code:
Teensy 3.2,   MK20DX256VLH7, M4, cpu  96Mhz, spi 24Mhz, TFT,  128x128, ST7735,  2 eyes: 85fps
Teensy 3.2,   MK20DX256VLH7, M4, cpu  96Mhz, spi 24Mhz, TFT,  128x128, ST7735,  1 eye:  85fps
Teensy 3.5,   MK64FX512,     M4, cpu 120Mhz, spi 18Mhz, OLED, 128x128, SSD1351, 2 eyes: 56fps
Teensy 3.5,   MK64FX512,     M4, cpu 120Mhz, spi 18Mhz, OLED, 128x128, SSD1351, 1 eye:  56fps
Teensy 4.0,   i.MX RT 1062,  M7, cpu 600Mhz, spi 48Mhz, TFT,  240x240, ST7789,  2 eyes: 30-32fps
Teensy 4.0,   i.MX RT 1062,  M7, cpu 600Mhz, spi 48Mhz, TFT,  240x240, ST7789,  1 eye:  15-16fps
Hallowing M0, ATSAMD21G18,   M0, cpu  48Mhz, spi 12Mhz, TFT,  128x128, ST7735,  1 eye:  22fps
Hallowing M4, ATSAMD51G18,   M4, cpu 120Mhz, spi 50Mhz, TFT,  240x240, ST7789,  1 eye:  27-31fps
Monster M4SK, ATSAMD51G19,   M4, cpu 120Mhz, spi 50Mhz, TFT,  240x240, ST7789,  2 eyes: 20-29fps
 
@KurtE

Was looking at the diffs between my version and Paul's version since my ST7735 lib seems to be 7 commits behind the master (figure they should be close to be even). I did notice a couple of things with DMA that is making me wonder if the master may be missing a update. Simple comparison:

My lib has in the st7735.cpp file
Code:
#if defined(__MK66FX1M0__)  
 DMASetting   ST7735_t3::_dmasettings[3][4]; 
#endif 

#if defined(__IMXRT1062__)  // Teensy 4.x 
// On T4 Setup the buffers to be used one per SPI buss...  
// This way we make sure it is hopefully in uncached memory 
ST7735DMA_Data ST7735_t3::_dma_data[3];   // one structure for each SPI buss...  
#endif
but the master does not have this? Is this right and the master needs to be updated?
 
@mjs513 - Yep - I run into that at times as well. Sometimes it is because I am not 100% synced up with Paul...

That is when I use my sledgehammer approach to sync... For example in my home directory I have some scripts:
Example to sync up cores
Code:
d:
cd d:\GitHub\Cores
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master --force
cd %home%
c:
But again this is sledgehammer. That is if you have anything changed and not either git pushed or git stash or ...
Regardless of your current branch, this will wipe them out!

I ran into a similar issue yesterday when editing master file imxrt.h, it showed another structure changed... So before I uploaded it, I edited my copy to remove those changes...

Now potentially the other GIT issue is that your branch was probably created before those last changes went into master. So GIT is comparing your code to where your branch was "BASED"
I know GIT has the ability to REBASE, but I have never mastered it.

My typical REBASE is again the sledgehammer. I copy away my new stuff to some save folder (example on my desktop).
I use the first sledge hammer above.

After that completes, I create a new branch, which I copy in my changed stuff, and then check the changes, push that one up.... And delete my previous working version... But I know there should be a cleaner way...
 
KurtE said:
My typical REBASE is again the sledgehammer. I copy away my new stuff to some save folder (example on my desktop).
I use the first sledge hammer above.

After that completes, I create a new branch, which I copy in my changed stuff, and then check the changes, push that one up.... And delete my previous working version... But I know there should be a cleaner way...
Yep - think the sledgehammer will be the way to go for me - to be honest think its cleaner (or easier for me to understand whats going on. That will be the project for when I get back from my errands.
 
@KurtE - ok - did the "sledgehammer" on the 7735_t3 update PR and now it is looking good with no conflicts.
 
@KurtE
Figured I would resurrect this thread at this point since I am now testing with 1.49Beta#3.

Using one of our ST7789 1.3 n 240x240 with no CS pin ran through all the examples with no issue. All examples were run with the default SPI Clock in the library for the 7789.

Also ran you st7789 gauge example from that you posted in the other with no issues and I didn't notice any issues with the framebuffer.

The one thing I noticed is that in most of the examples we really show the format for an example with no CS pin except one of the uncannyeyes sketch. Maybe we need to add some stuff to the readme like for the 9488 and 9341.

BTW: We did allow changing the clock in the ILI9488 library I noticed.
 
@mjs513 - Good to hear. (are you now running the beta 1.3 SPI code/core or do you have some additional changes?)

Side note: I just hacked up hook up to my RA8875 board, and was able to get one to run, with several jumpers.

Found a couple of problems in board and one bad solder joint (missed soldering pin 13 :eek: ) Now deciding if I will just make minor update to have a working one.

Or maybe make it to maybe work with T4, T3.6 and guesses at T4.1...
 
@KurtE
Running beta3 SPI code. No changes were necessary.

Cool you got it working with your RA8875 board. Yeah my first breakout board has a few jumpers on it as well so seems about normal. Going to have to make it work with all teensys :)
 
Back
Top