Any small LCD screen that works well with Teensy 4?

[zapta]

I would like to attach a small LCD or OLED screen to a Teensy 4. For example, this 1.8" SPI color screen (monochrome may also be ok).

https://www.aliexpress.com/item/3299...chweb201603_55

Any recommendation for graphics library and a small screen that work well with Teensy 4? I need to display text and a simple scrolling graph with a few updates per second at most.

[MichaelMeissner]

The main thread where various displays are discussed, including ones you mentioned is at (I tried to jump to a page where they were discussing the 240x240 display (2nd one in your list):

• https://forum.pjrc.com/threads/57015...l=1#post211150

I have that display and I was able to run that display (using the ST7789_t3 driver and the program they mentioned). Note that particular display does not have a chip select (CS) pin, so if you use it, you won't be able to put anything else on that particular SPI bus. There are other displays out there with a CS pin (Adafruit for instance makes 2 of the 240x240 displays in different sizes and the 320x240 display).

Note, I am out of town right now, and I won't be returning until Monday night, so I can't retest it with the official release.

I bought this particular display from Amazon:

• https://smile.amazon.com/gp/product/...?ie=UTF8&psc=1

Here are the Adafruit displays:

• https://www.adafruit.com/product/4313
• https://www.adafruit.com/product/3787

I have the small one, and I think I tested it on the T4, but I can't check until I get back.

Note, on the T4, you only have one fast CS pin to optimize these displays. One of the people in the thread above mentioned running two of the displays on two separate SPI buses. For the first SPI bus, the 'fast' CS pin is pin 10.

[ETMoody3]

Wow, 3$ from the Amazon vendor via slow boat.

Just sent for two. ( *always* buy a spare)

[zapta]

Thanks Michael, this is very useful information.

I don't need to run anything else with SPI so I presume that CS is not an issue for my application.

I just ordered a T4 here and two 1.8" 128x160 ST7735 from Aliexpress https://www.aliexpress.com/item/32992897033.html

A few more questions for you if you don't mind...

1. Are these the libraries I should use?
* https://github.com/PaulStoffregen/ST7735_t3
* https://github.com/adafruit/Adafruit-GFX-Library

2. I would like to use that screen in landscape mode. Do these libraries support screen rotation?

3. Does the Adafruit GFX library has the concept drawing to a buffer and then flushing it to the screen? If not, is flickering a concern? (I plan to do at most 3-5 updates a sec)

4. I need to sample an A/D continuously at ~5-10khz so this will probably be done in counter/timer interrupt. Do you know if the graphics library will interfere with that interrupts? (e.g. disabling it for long time).

5. Is arduino IDE a reasonable IDE for Teensy 4 projects? (I like it because of easy of installation).

[KurtE]

@zapta - Libraries - ST7735_t3 library is installed with Teensyduino. Not sure if we have released a new version of Teensduino since Paul took in my previous PR, which added support for running the ones without CS pins. I know there is still one outstanding PR for T4 (https://github.com/PaulStoffregen/ST7735_t3/pull/3)

Most of the still pending PR has to do with T4 when you do something like: tft = new ST7789_t3(...) where the object is created in the heap and issues associated with DMA and the like from this memory...

To the questions

1) I believe that there may soon be a new Teensyduino beta release of stuff that Paul was working on to better work with Serial monitor and the like. Not sure exactly when yet... But it will have both libraries in it...

2) The library has the functions setRotation so yes you can get all 4 orientations.

3) The ST7735_t3 library does have the concept of frame buffer, like I have in the ili9341_t3n library. You can turn it on and then all graphic primitives go to this memory instead of the screen. Then you can call tft.updateScreen() to update it from the frame buffer. There is an Asynchronous version tft.updateScreenAsync() which will do a DMA operation to update screen once and a way to turn it on for continuous, but that gets you back to flicker possibility.

Note: In many cases you can avoid flicker without using frame buffer, by carefully planning out your graphics, such that each pixel that is updating is only updated once...

4) Assuming you get your AToD working properly, the updating the display should not impact it... Of course if your AtoD code relies on your main loop to do it and your main loop is waiting for display to complete, that may be something to look at, but the update code should not be doing any disabling of interrupts.

5) Arduino IDE - It gets the job done. There are others who prefer to go to other IDEs to do things. Sometimes I do it all within sublimetext, othes use VisualStudio...

[zapta]

Thanks Kurte, this is very useful.

The LCDs should arrive in 2-3 weeks so I will sample whatever Teensduino will be available at that time and give it a try.

I think that the pending issues should not be show stoppers in my case since the LCD I ordered has CS and I don't use 'new' in embedded code ;-)

And thank you for all the great work of supporting these open source libraries.

[zapta]

I got the 1.8" TFT, followed the connections described in the Teensy ST7735_t3 example (I am using Teensy 3.2) and everything works just fine. That's was easy.

The only problem I encountered so far is a slight flicker when I update a small text field that is updated at about 5 times a sec. The field occupies exactly 4 fixed size character and is always on black background. Before I print the new text I fill the small rectangle with black and then print the text.

Is there a better way to update the screen with no flicker? For example double buffering? Or writing the text such that it will paint both the characters and the background? (I tried to call tft.setTextColor(textColor, backgroundColor) but it didn't make any difference and didn't paint the characters backgrounds).

Edit, even if I try to draw chars directly, the second color which is supposed to be the background doesn't seem to have any affect.

   tft.drawChar(50, 100, 'x', ST7735_RED, ST7735_WHITE, 4, 4);

[defragster]

…

Edit, even if I try to draw chars directly, the second color which is supposed to be the background doesn't seem to have any affect.

   tft.drawChar(50, 100, 'x', ST7735_RED, ST7735_WHITE, 4, 4);

Saw something similar, but perhaps not as in this case, so didn't look at this. But doing simple text out the background wasn't filling in for overwrite.

It did work when I did something like this first: setTextColor( ST7735_RED, ST7735_WHITE );

Indicated behavior may be an issue - this may just be a workaround … but nice to know if it helps.

[MichaelMeissner]

One other thing WRT to flicker is to make sure you use pull-up resistors for the CS and DC pins. On a Teensy 3.5 I had a bad case of screen corruption if I pushed my OLED screens too fast before I added the resistors.

[zapta]

It seems that the problem with not updating the background is related to comment here

https://github.com/adafruit/Adafruit..._GFX.cpp#L1136

This is a bad choice in my opinion. First it assumes that custom fonts are not monospace (wrong assumption in my case) and second even with variable length fonts, not updating the background is less intuitive than updating it (and the user always have the option of setting text color = background color to indicate no background change).

I made the changes to my copy of Adafruit_GFX.cpp and everything works well.

MichaelMeissner@, I will check the CS and DC on my T3.2 with an oscilloscope and see if they need to be improved. Thanks.

[KurtE]

It may depend on what version of library you are using and/or are you using default font or did you set a font?

That is the current version of st7735_t3 (as well as my current one with pending Pull Request) uses Adafruit_GFX to output the characters. Their code splits up into two parts.
One with default font which I believe might use the background color stuff, and then their custom font code which I don't believe uses it....

Now @mjs513 has a version of the library, that merged over the stuff that several of us did in my version of the ili9341_t3n library which does not use Adafruit_GFX and I implemented the opaque font cod, which I believe is in his version of the library, which I believe is up at: https://github.com/mjs513/ST7735_t3/...735_T4_rewrite

Note: hopefully we will do a Pull Request of this version to replace the current released one as it has a lot of great stuff in it... BUT there is a compatibility issue with Fonts. That is this version uses the fonts like we do for the ILI9341_t3 (_t3n) libraries, which is different than the Adafruit_GFX fonts...

As for flicker, the current code has some of my stuff from the above ili9341_t3n. So in particular, you can turn on a frame buffer, you do all of your graphic primitives into memory and then say update the screen, which does it all in one pass..

[MichaelMeissner]

MichaelMeissner@, I will check the CS and DC on my T3.2 with an oscilloscope and see if they need to be improved. Thanks.

The pull-up resistor issue is noted in this document:

• https://www.pjrc.com/better-spi-bus-design-in-3-steps/

[zapta]

Michael, when you experience the SPI issues, did you have more than one SPI devices connected to the same MISO/MOSI ?

In my case there is only one device, the display. I wonder if I even need to connect the CS.

[KurtE]

@zapta - you need to connect up CS pin (i.e. not leave it floating). You might get away connecting it to GND, but then it may or may not work. But there are some of these displays that internally connect up to GND, and we have gotten them to work, but you need to change to use I believe it is SPI_MODE2 (or was it SPI_MODE3)... There are examples in our current library that show this.

[MichaelMeissner]

Michael, when you experience the SPI issues, did you have more than one SPI devices connected to the same MISO/MOSI ?

In my case there is only one device, the display. I wonder if I even need to connect the CS.

Yes, I had two displays on the same bus, using the DMA optimizations for Teensy 3.x with the ST7735 (TFT 128x128) and SSD1351 (OLED 128x128) displays. But I imagine it is still good practice to have the pull-up resistor with a single device.