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

Okay - I wondered how sometimes files are newer than 'lastest commit' … I see that now files show 2 hours.

Anyhow I just got what was there and I see backlighting signs of life - but no display after compile and some sermon notes: init, 49, done.

in GraphicsTest … Changes:
Code:
#define TFT_SCLK 13  // SCLK can also use pin 14 // SCL
#define TFT_MOSI 11  // MOSI can also use pin 7 // SDA
[B][U]#define TFT_CS   -1 //10  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23[/U][/B]
#define TFT_DC    9  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_RST   8  // RST can use any pin
#define SD_CS     4  // CS for SD card, can use any pin

// For 1.54" TFT with ST7789
[B][U]ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);[/U][/B]

and :: tft.init(240, 240); // initialize a ST7789 chip, 240x240 pixels

Then wires to labels match those T4 pin #'s? … no signs of life - other than the light behind the blacked tft layer.

I have 1.3 Inch IPS Hd Tft St7789 Drive Ic 240 x 240 :: > Not 1.54, 1.44 or 1.8" TFT
 
with the CS challenged displays, you need to change the init call, to be something like: tft.init(240, 240, SPI_MODE2);

That is there is the optional SPI mode and for some reason these work better at Mode 2...
 
Example: with the st7735 example the 128x128 one could enable the frame buffer support: 128x128x2= 32768 which is < 64K memory so that would fit...
Even the 128x160*2 would fit 40960... But obviously not the st7789 ones...
So not sure if it would ever make sense to enable it?
Oops - it works ;) (GH updated ;) )
 
Awesome work KurtE!

with the CS challenged displays, you need to change the init call, to be something like: tft.init(240, 240, SPI_MODE2);

That is there is the optional SPI mode and for some reason these work better at Mode 2...

THAT DID IT !!!!

And mine sits wires/silkscreen rightways up and this corrects :: tft.setRotation(2);

Looks great - under magnification … 1.3 inches is rather small area for 53,760 dots even nice clear ones.

Works with :: ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_RST);
or :: ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
 
Speedtest running at 13.93 FPS -

Here it is with edits making the NO_CS 1.3" work here:View attachment SpeedTest.ino

opps : line #228 is copy paste leftover

<edit>: Display has BLK:Backlight pin - I left disconnected. Connected to 3.3V seems the same - Amazon page says 'floating' is normal and 'LOW' is off
Working voltage: 3.3V
GND:power ground
VCC:3.3-5.0V(DC)
SCL :SPI clock line
SDA :SPI data line
RES :Reset interface
DC :SPI data/command selection
BLK :Backlight control,default floating,low level off

<Edit2> - moving to pinnable T4 on DIY breakout so I can run the MultiSerial# test and print to display - and do FreqCnt. Shifted two pins and it works:
#define TFT_DC 10 //9 // but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_RST 12 //8 // RST can use any pin
 
Last edited:
I just tried prior settings changing SCLK from 13 to 14 and using the long form of : ST7789_t3 tft = ST7789_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

I lost visible display?

Wanted to use FrqCnt on LED_BUILTIN to measure loop speed. Merging sketches and the LED breaks display …

Moved to #15 for toggle to get FreqCnt - very close to counted frequency.

<added>
@KurtE - The tft.print and tft.printf are nice - with it filling background color - no need to clear text. And tft.setTextWrap(true); works for wrapping!
Using long pinned T4 on DIY breakout … Sketch starts with GraphicsTest {shorted delay()'s} - then instead of MediaButton loop() doing a 5 Serial# port pass through and doing a pin#15 toggle for FreqCnt, also the colorFade bar from SpeedTest.ino each data pass.
> Adds tft lag and messes with timing so having to adjust and clean stuff up that 'passed okay before' - better now
> And because lines can get shorter I do a fillRect() - after the string end - so some chars flash. Just shorted passed/printed Serial print text and got rid of that
> magnifying glass is very handy - - way too needed :(

But very nice to have FreqCnt print on display in one spot - not scroll by at one line of other text every 5ms … updated to 3ms and working with tft on 1 sec update when new FreqCnt.avail.

Using lots of pins 10 for Serial#, 2 for FreqCnt,, 4 for tft ST7789, 3,3V, GND ... turned off anaologWrite() to #2 so pins 8 left +GND&5V.

Got loop() cnt's to drop to about 127K with 2ms repeat - but only making 479 passes/sec with time slippage needed for limited tft updates.
Got loop() cycles back up over 7Million by reducing the 3 pixel wide colorFade bar update rate
T4 is amazing with USB output - checked the other day when PC was getting wacky with so much to display and stopping it from Teensy didn't speed up the Teensy loop() cnt.

This is with reduced yield() calls 1/100 loops() - plus 5 last minute calls before showing what was received - the ~16 Serial# chars transfer in under 100us. Will let it run next few hours and put a note on T4_Beta thread

Again tft ST7789 240x240 1.3" is very usable @KurtE
 
Last edited:
@KurtE - knew you weren't to be able to resist not incorporating FB/Async :). Maybe need to be a note in the example for the NO_CS pin tft.init - probably would have forgot that myself

@defragster - nice you got everything running with the display - the 2" 240x320 is even nicer than the 1.3".
 
@KurtE - knew you weren't to be able to resist not incorporating FB/Async :). Maybe need to be a note in the example for the NO_CS pin tft.init - probably would have forgot that myself

@defragster - nice you got everything running with the display - the 2" 240x320 is even nicer than the 1.3".

Very nice KurtE got the code where it is! If only the KeDei had been as easy and rewarding when done.

I saw the TAB_TYPE changed the Mode - but not to MODE2 - I recall seeing that go by - but not in context when I was figured even double + double checking the wires and other commented switches must be the problem.

Yikes - higher resolution yet? I don't recall seeing that one - this one for $4 is worth finding my glasses or a magnifier - that one would take both. What was the link? An Adafruit? I'd like to find a similar OLED that would have outdoor viewability. Though this one with out the extra touch laminate layers will be better than those with them.

ONE NOTE - this one is not feeling warm to touch at all - actually closer to room temp than body temp it feels cool and has been powered some time - unlike the KeDei that had the hot spot running from 5V. The color and contrast is good - not overblown with LED like the KeDei

137 mA to power : DIY Breakout (LED etc), 1.3" TFT, and the T4 running the sketch - onboard LED #13 with 5 Serial#'s at 5Mbaud.

What is the color depth? 2 bytes/pixel - 16 bit?

Just opened lib folder - I see SPI speed at :: #define ST7735_SPICLOCK 24000000

Bumping that to 48M dropped 400us off the 950 us update on the screen update with new 1 sec FreqCnt down to 566. Added another 30,000 loop() cycles/sec and pushed Serial# string transfers up a few as well with less time slippage on longer updates. Going to 64M made no added difference. Again - awesome to have perf/output numbers in a fixed screen location - not scrollingSPEW - and not really need SerMon at all. Looks like about 15 vertical lines of about 20 chars with tft.setTextSize(2)?

Any reason not to have at least the T4 use :: #define ST7735_SPICLOCK 48000000 and 32M on most other T_3.x's? I have only tested on T4.


This is something for the Beta T4 thread - a couple times after Upload USB Serial to TyComm has gone offline - with tft active and running? Quite possibly PC USB and TyComm tired of so much fast SPEW. Push Button Upload again and it comes back - anyone else seeing this? Using TyComm for SerMon as the IDE seemed Faulty - so Button to upload as I disabled TyComm upload to test PJRC stuff. Still had to restart the IDE as it was even failing on compile - with 9 sketches open and a bazillion recompiles.

If multiple Serial# and TFT and FreqCnt seems like fun - here is the sketch:
View attachment gt7789SerFrC.ino
~line 464 added spaces when smaller numbers display:
Code:
if ( gotFreqC ) {
				tft.setCursor(10, 168);
				tft.printf( "xus=%u  ",lastXfer - firstXfer );
				tft.setCursor(120, 168);
				tft.printf( "HZ:%u ", passHz );
			}
It is not pretty - two sketches in one - refined only to function, same notes as before when posted for Serial crossover and Array of Serial# pointer and 'ACTIVE_SER'.
 
@KurtE - knew you weren't to be able to resist not incorporating FB/Async :). Maybe need to be a note in the example for the NO_CS pin tft.init - probably would have forgot that myself

@defragster - nice you got everything running with the display - the 2" 240x320 is even nicer than the 1.3".
I pushed up an edit of the graphictest with some additional/modified comments. Tell me what you think.

Yes could not resist ;) But did not take much to do, it is using the same code as T3.5 does for SPI object. I remember 3.5 had DMA scatter/gather issues, which this one avoids, by outputting the display in a couple of dma operations, which interrupt between instead of trying to link DMA things... I don't remember if 3.2 had the same issue or not, but did have some of the issues, like losing the upper word of PUSHR register, so you have to hack CTAR0 to be 16 bit writes and you have to convert CS pin to be IO pin and not controlled by upper word....

And on the examples side, I am thinking about cleaning up (a little) my ST7735_t3_multiple example (included if you wish to play)
Which so far I have hooked up 2, but will try 3 (one on each buss) that run most of the graphic test areas without much delay between and use the Frame buffer and
updateDisplayAsnych....View attachment ST7735_t3_multiple-190728a.zip

Mainly need to cleanup the comments like the previous one...
 
@KurtE

I pushed up an edit of the graphictest with some additional/modified comments. Tell me what you think
Just took a look and the changes look good for the different displays - a lot clearer.

Have a bunch of errands to do but took a quick look at the attached sketch think the initialization process is going to get confusing for multiple displays. Anyway some of that can be moved to a library? For instance:
Code:
ST7735_t3 * tfts[] =
{
#if 0
//  & tft,
  & tft1
#else
  & tft

#if SPI_INTERFACES_COUNT > 1
  , & tft1

#if SPI_INTERFACES_COUNT > 2
  , & tft2
#endif
#endif
#endif

};

uint8_t tft_which_test[] =
{
  0, 0, 0
};

uint32_t last_test_start_time[] =
{
  0, 0, 0
};

uint32_t next_test_start_time[] =
{
  0, 0, 0
};
Other stuff as well but at least maybe you can start thinking about it. Promise I am going to play later - oh - looks like you can have different resolution displays as well. :)
 
@mjs513 - Thanks,

Note: I just pushed up a version of the multiples with lots more comments and the like, I probably need to retest the T4 stuff,
But I just ran it on: T3.6 with two displays on it, plus T3.2 with one display, plus T-LC with two displays.

In the case of T-LC it disables the Asynch support so each display updates as the other sits... But it at least gives examples of pins for both busses.
 
Think I will pass on that one - way too small for me ;) Maybe....

Probably me too, BUT ;)

a) Need to integrate the init code differences in and have a way to test...

b) I am thinking maybe on my T4 Robot controller board, maybe add a connector that has the pinout of several of these smaller displays, and I can maybe choose to have one on board... For a lot of these projects having a small display that maybe just shows a few things, maybe just right. Could run these off of the SDCARD connection of T4, and have both the display and use their SD card.

Maybe might also have alternative connections for CS challenged displays...

Just a thoughts now... More likely they well end up in my display and sensors box :D

EDIT: I did the edits to hopefully allow these smaller displays to work. Displays should arrive Wed, will probably pick up Thursday.

May check in before then if someone else wishes to test it out.
 
Last edited:
@KurtE

First - I downloaded your latest lib and ran the multiple sensor sketch with the 7789 240x320 on SPI and the 240x240 on SPI.

First pass the 240x320 only used about the first rows of pixels but the 240x240 worked fine - I did do a setrotation(2) on the 240x240 since it has different rotation than the 320 display.

Second pass I disabled the framebuffer and the 240x320 came to life and displayed whole screen no problem and yes the 240x240 display worked as well. Looks like there may be a problem with the framebuffer for the 240x320 ST7789 display.

Now back to errands. :)

No comment on the robot controller board = you are going to get me distracted :)
 
@mjs513 - Which Teensy did you test to 320x240 on for the Async?

You might try the the simple test that I have setup to try FB...View attachment st7735_t3_simpletest_FB-190728a.zip

It is setup to be able to try different SPI busses like the other...

If you hit <CR> it will do cycle through the rotations.

but: the interesting test is to see if Asynch works:
a<cr>

Which should show same screen but different background color.

Also then:
c<cr> goes through several screens async...

As for distractions :lol:

Edit: I am pretty sure I know what is going on... 320x240x2=153600/2=76800 > 64K
as I am currently setup for chaining two DMA transfers, so need to in this case have 3 dmaSettings...

But time to enjoy Sunday Brunch and ...
 
@KurtE

Sorry - just got a chance to get back to this. I am using the T4B2 board

Ok - first tried the sketch on the 240x240 display on SPI1 and it worked as you described. Hit 'a' got a yellow background, hit 'c' screen background goes through a couple of screen color backgrounds.

Now, the bad news for the 240x320 when I hit 'a' I it only shows yellow on the top few rows of the display - maybe 240x4. When I hit 'c' it draws red-yellow-blue bars at the bottom of the screen (looks like 240x80).

Edit - just saw your edit - hope you are enjoying your Sunday. Nice lazy day here as well :)
 
Yep - enjoyed nice fresh home made pasta in cold salad, nice bottle of wine ...

Just pushed up change that hopefully fixes DMA for 240x320 display. Would be great if you by chance could test it on a few displays/boards.

Like on T4 and 3.6.... If really brave try out on 3.5, maybe on both SPI and SPI1 or 2... But that is only if you are brave :D

I tried a few things on T4, T3.6 3.2 and LC ... on this round
 
Got the 'AM' new ST7789 lib - works the same - only have the 1.3" 240x240 - so testing it with 'normal' user code and seeing it work properly and well - only on T4 - except the NICE localized 'Spew in a Spot' prints seem attractive - but really take time.

Seems I need new github zip and to start the ASYNC code up to test that and have less overhead.

doing :: #define ST7735_SPICLOCK 48000000
and :: #define DISABLE_ST77XX_FRAMEBUFFER

Faster SPI clock looks good and significantly faster.

I do have a second st7789 - and two POGO pins - what do I need for that beside pins #26/MOSI1 and #27/SCK1 ?
LIKE THIS ? >> ST7789_t3 tft2 = ST7789_t3(TFT_CS==-1, TFT_DC==3, TFT_MOSI==26, TFT_SCLK==27, TFT_RST==4);
> This DIY with T4 has no SDIO pins connected

Robot Base board with Display: That is what I noted the other day for mjs513 - put i2c pins for a simple OLED - one of these in color same cost and not much bigger though 4 not 2 pins - either would be handy for feedback. Got that free Azure Sphere board and it has i2c pins for such a display - though GND/VCC swapped from my older units - ordered new that have it in the 'i2c grove Order' also used on the TinyPICO shield.
 
Cool glad you enjoyed the pasta - haven't made homemade pasta in years :)

Any on T4 still not working same behavior as before for the 240x320

On T3.5 even worse - yes I am a glutton for punishment:
1. DELETED. See edit
2. 240x320 - only tried it on SPI. Rotation works but nothing for asynch or framebuffer.

EDIT: My bad forgot to change the pin number for DC on the 240x240 for SPI1. Just retested and works fine on SPI1 = deleted note 1.
 
Darn!

You might try turning on the debug printing:
near the top of st7735_t3.cpp is the line: //#define DEBUG_ASYNC_UPDATE

(uncomment and it should print out the generated dma setting structures, which might give me some clues, especially on T4 and 3.6...

I did not change anything with 3.5, as I thought it might handle it... There is also two completely different sets of code on 3.5 for SPI and SPI1/2...

Also I think I screwed up: st7735_t3.cpp line 1367: if (COUNT_WORDS_WRITE >= 65536) {
change 65536 to 32768


On T3.5 next thing I would probably try is to edit the line in header st7735_t3 about line 401, the T3.2 has a copy of this, which probably need to worry about as it does not have enough memory for these displays anyway...

and change: uint16_t _dma_count_remaining;

to uint32_t and see if that helps.
 
Morning @Kurte

Made the changes you suggested in previous post.

On the T4 Async seems to now work no issue. See below. After I hit 'a' you can see the dump below. I then did screen rotation to make sure it still was working and then I hit 'c' for framebuffer, while it worked to change the screen colors the sketch froze after it completed, i.e., screen rotation no longer worked.

Code:
hello!CS:10 DC:9 MOSI:11 SCLK:13 RST:8
ST7789_t3::init mode: 0
init CS:10 DC:9 MOSI:11 SCLK:13 RST:8
 Row Start:0  Col Start: 0
Set Rotation: 0 width: 240 height: 320
Hit any key to continue
20002400 400e9020:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
20002340 20002360:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
20002380 200023a0:SA:2020c820 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023e0 CS:10 BI:6400
200023c0 200023e0:SA:20219020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:20002360 CS:1a BI:6400
After Async Update
Async completed 69
Set Rotation: 1 width: 320 height: 240
Hit any key to continue
Set Rotation: 2 width: 240 height: 320
Hit any key to continue
Set Rotation: 3 width: 320 height: 240
Hit any key to continue
Set Rotation: 0 width: 240 height: 320
Hit any key to continue
Start Continuous update test
20002400 400e9020:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
20002340 20002360:SA:20200020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023a0 CS:10 BI:6400
20002380 200023a0:SA:2020c820 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:200023e0 CS:10 BI:6400
200023c0 200023e0:SA:20219020 SO:2 AT:101 NB:2 SL:-51200 DA:403a0064 DO: 0 CI:6400 DL:20002360 CS:12 BI:6400
After updateScreenAsync
Finished all frames
After call to endUpdateAsync

Ok, now on to a T3.5. Good news - it works perfectly.
Code:
DMA dump TX:0 RX:1
1fff12b0 40009000:SA:1fff1762 SO:2 AT:101 NB:2 SL:0 DA:4002c034 DO: 0 CI:63ff DL:0 CS:8 BI:63ff
1fff12b8 40009020:SA:4002c038 SO:0 AT:101 NB:2 SL:0 DA:1fff12d8 DO: 0 CI:6400 DL:0 CS:a BI:6400
After Async Update
Async completed 67
Set Rotation: 3 width: 320 height: 240
Hit any key to continue
Start Continuous update test
DMA dump TX:0 RX:1
1fff12b0 40009000:SA:1fff1762 SO:2 AT:101 NB:2 SL:0 DA:4002c034 DO: 0 CI:63ff DL:0 CS:8 BI:63ff
1fff12b8 40009020:SA:4002c038 SO:0 AT:101 NB:2 SL:0 DA:1fff12d8 DO: 0 CI:6400 DL:0 CS:a BI:6400
After updateScreenAsync
Frame count: 7
Finished all frames
After call to endUpdateAsync
Test completed

The T3.6 does exactly the same thing as the T4. Async works but after executing framebuffer with 'c' the sketch freezes:
Code:
hello!CS:10 DC:9 MOSI:11 SCLK:13 RST:8
ST7789_t3::init mode: 0
init CS:10 DC:9 MOSI:11 SCLK:13 RST:8
 Row Start:0  Col Start: 0
Set Rotation: 0 width: 240 height: 320
Hit any key to continue
DMA dump TCDs 1
1fff1400 40009020:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:10 BI:63ff
1fff1300 1fff1320:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:10 BI:63ff
1fff1340 1fff1360:SA:1fffe0c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff13a0 CS:10 BI:6400
1fff1380 1fff13a0:SA:2000a8c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff1320 CS:1a BI:6400
1fff13c0 1fff13e0:SA:1fff18c0 SO:2 AT:101 NB:2 SL:-2 DA:4002c034 DO: 0 CI:1 DL:1fff1320 CS:10 BI:1
After Async Update
Async completed 67
Set Rotation: 1 width: 320 height: 240
Hit any key to continue
Set Rotation: 2 width: 240 height: 320
Hit any key to continue
Set Rotation: 3 width: 320 height: 240
Hit any key to continue
Set Rotation: 0 width: 240 height: 320
Hit any key to continue
Start Continuous update test
DMA dump TCDs 1
1fff1400 40009020:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:90 BI:63ff
1fff1300 1fff1320:SA:1fff18c2 SO:2 AT:101 NB:2 SL:-51198 DA:4002c034 DO: 0 CI:63ff DL:1fff1360 CS:10 BI:63ff
1fff1340 1fff1360:SA:1fffe0c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff13a0 CS:10 BI:6400
1fff1380 1fff13a0:SA:2000a8c0 SO:2 AT:101 NB:2 SL:-51200 DA:4002c034 DO: 0 CI:6400 DL:1fff13e0 CS:10 BI:6400
1fff13c0 1fff13e0:SA:1fff18c0 SO:2 AT:101 NB:2 SL:-2 DA:4002c034 DO: 0 CI:1 DL:1fff1320 CS:12 BI:1
After updateScreenAsync
Frame count: 7
Finished all frames
After call to endUpdateAsync
 
@mjs513 - Thanks,

The information says that the main DMA stuff was working, but that I forgot to update the endUpdateAsync function, that the item in the chain that needed to be disabled, may be different.

Which I now updated to:
Code:
void ST7735_t3::endUpdateAsync() {
	// make sure it is on
	#ifdef ENABLE_ST77XX_FRAMEBUFFER
	if (_dma_state & ST77XX_DMA_CONT) {
		_dma_state &= ~ST77XX_DMA_CONT; // Turn of the continueous mode
#if defined(__MK66FX1M0__) 
		_dmasettings[_cnt_dma_settings].disableOnCompletion();
#elif defined(__IMXRT1052__) || defined(__IMXRT1062__)  // Teensy 4.x
		_dmasettings[_cnt_dma_settings-1].disableOnCompletion();
#endif
	}
	#endif
}
I pushed these change up to github, now to keep fingers crossed
 
@KurtE

Glad it was a simple fix. I just tested on a T3.6 and the T4. Got some good news and some minor bad news.

The good news is that it works, asynch and framebuffer on both boards.

The bad news is on the T4. On the T3.6 framebuffer shows a nice smooth transition between changing the screen colors. However, on the T4 when the screen updates there are blotches of the previous color on the screen as the screen updates but they go away once update is complete.
 
Back
Top