Feature request color display

[s0170071]

I have a couple of ST7735 displays https://www.arduino.cc/en/Guide/TFT They are cheap and SPI. Thought they may be added to the framed display plugin.

[TD-er]

Hmm, SPI and ESPeasy is quite a new combination I guess. Never seen any plugin using SPI.

I also have a SPI epaper display which still has to be supported.

Thing with color displays is that the required memory for the frame buffer will increase a lot compared to 1 bit per pixel displays.

[s0170071]

I looked at the library. The interface is encapsulated nicely. Just in case I happen to get bored a lot I'll do it...

[TD-er]

Please also have a look at these repo's: https://github.com/squix78?tab=repositories This is from the author of the OLED library. It looks like he is making some generic display library for all kinds of displays to connect to the ESP8266.

He abandoned the OLED-SSD1306 library (no PRs merged for over a year) and I took all suggestions and PRs from that github and collected them in the update of the library I created a few days ago.

[realwax]

+1 on this. Would be a charm having support for ST7735S out of the box. instead of being bound to the smaller 0.6 display. Thank you!

[tonhuisman]

@s0170071 @realwax @drone777 If you are interested, here are .bin files with support for these displays:

(Updated, see below)

(ST7735: 128x128, 128x160, 80x128, ST7789 240x320, 240x240, 240x280, all connected via SPI)

[realwax]

@tonhuisman Thank you!

[tonhuisman]

Please report your findings, good or bad, there will soon be updates with new features and improvements 😃

[tonhuisman]

Did some bugfixing and added a few features, re-organized device settings somewhat. Updated builds are available, and also documentation:

(Updated, see below)

[realwax]

@tonhuisman Thank you for your efforts! I tested today with a Wemos D1 mini and Wemos TFT Shield 1.4" Everthing is working like a charm. Connected it via MQTT to iobroker. Colors, textspacing, textpos, drawing rectangles, ... all working! The only strange thing I encountered was when sending tftcmd,off it clears screen and bg color it goes white and not off. I cannot dim it, too. But I think it's related to the TFT shield as it states in the link TFT_LED NC - which means not connected i guess - if TFT_LED is meant to be the backlight. I guess I need a different display to enable that feature. What do you think? And again - thank you for integrating it! :)

[tonhuisman]

Great that it's working (mostly) as expected 👍 Is the backlight dimming working at all for your board, so if you set it to 30% the display gets dimmed, compared to when set to 100%? The NC most likely means it is not connected, indeed, so I don't think the backlight dimming can work without adding extra wiring.

I have been working on the code for 2 more days already, and have done a lot of improvements, especially to the clear command 😉 I'll publish an updated build probably late(r) today (CEST) or tomorrow.

I own a few of these displays, 1x ST7735 (128x160) and 1x ST7789 (240x240), and where the ST7789 doesn't have a CS connection, the display and the BLK connection is working like a charm, but the ST7735, having both CS and BLK connections, the backlight is not working at all when anything is connected to that pin (and display contrast/readability is really poor because of that). I suspect it has to do with the 'Chinese quality' of these devices, as I ordered them straight from Aliexpress 😅

[realwax]

As you said. Back light is not working at all. Change affects nothing. I connected the TFT_CS to D4. TFT_LED which I thought should be the back light to D0 and configured it. But on the shield as it says NC there is a need to solder or connect. The schematic should show it but I not used to understand what they mean here. https://www.wemos.cc/en/latest/_static/files/sch_tft1.4_v1.0.0.pdf There is a bottom solder point https://www.wemos.cc/en/latest/_static/d1_shields/tft_1.44_v1.0.0_2_16x16.jpg where i guess it needs to be connected. The middle point to one of the outers https://www.wemos.cc/en/latest/_static/d1_shields/tft_1.44_v1.0.0_2_16x16.jpg

But as you said - poor build ;)

[tonhuisman]

Looking closely at that picture, it seems that TFT_CS = D4, TFT_DC = D3 and TFT_RST = RST (hardware reset pin from ESP), so TFT_LED can't be soldered to D3 or D4, remaining only D0 or D8 for use (without major surgery). If you connect that center island to either D0 or D8 islands next to it, and configure in ESPeasy, it will probably work.

[realwax]

I soldered it to D8 as I messed up D0. There seems to a kind of transparent coating on the board. But it does not make any difference. Maybe my solder wasn't working or this sneaky little bas... doesn't support it - that's why NC. Anyhow thanks for pointing me towards the right direction. I don't want to spoil this thread here with a hardware issue. I posted this thread to a YT video with an immediate reaction welcoming your implementation. So maybe more testers ;) Have a nice day :)

[TD-er]

D8 is pulled to GND (or else the ESP will not boot)

See Best pins to use on ESP8266

[realwax]

D8 is pulled to GND (or else the ESP will not boot)

See Best pins to use on ESP8266

@TD-er Thank you.

[tonhuisman]

I've added a few features, fixed a handful of bugs and did some other improvements, so here are new builds for testing.

(Updated, see below) (Documentation will be updated later, but the previous docs are still mostly correct)

Latest feature is that there is inline processing of subcommands added to the default template, by using {:txs,4:} ~txs,4~ for changing the font scaling (executed before displaying the line, so no multiple font scaling per line), and the likes, resulting in this kind of display on my test-unit (ST7789 240x240px display):

[tonhuisman]

The previous sample was a bit 'single-color', so I upgraded it to show some (maybe a little chauvinistic 🎏 😜) colors:

I've also changed the template delimiters from {: and :} to ~ and ~, that's why the second line shows a few ~ characters, just to test that ~txs,2~~ %ip% ~ still is working as intended 😄 ('Sun' means %sunrise% in this context, and the background-blue (navy) is still the same, but the image is taken from a somewhat different angle, demonstrating the 'quality' / viewing angle of the display, and evening vs day lighting conditions 🤔)

[realwax]

The previous sample was a bit 'single-color', so I upgraded it to show some (maybe a little chauvinistic 🎏 😜) colors:

I've also changed the template delimiters from {: and :} to ~ and ~, that's why the second line shows a few ~ characters, just to test that ~txs,2~~ %ip% ~ still is working as intended 😄 ('Sun' means %sunrise% in this context, and the background-blue (navy) is still the same, but the image is taken from a somewhat different angle, demonstrating the 'quality' / viewing angle of the display, and evening vs day lighting conditions 🤔) Looking good!

I ordered myself a 2" ST7789 240x320 and will reflash on Monday and test. :)

[realwax]

Hey @tonhuisman, I got my 2" display but I got issues. It's ahttps://www.waveshare.com/wiki/2inch_LCD_Module. It's connected correctly but it stays dark when I choose the correct ST7789 240x320. For testing I switched to 240x240 and 240x280. Both work but distorted. I attach a picture. But as said when choosing the right option - it's not possible to display anything. Thank you for your help/fix.

Cheers Wolfgang 280 mode 240 mode

320 mode :(

[tonhuisman]

I've now changed initialization to also set the resolution for 240x320, as was already done for 240x240 and 240x280, maybe that improves stuff. Also fixed a color-parsing bug when using white.

Please try these new downloads:

(Updated downloads available below)

[realwax]

@tonhuisman Thank you very much! That did the trick. Display is now working! - [[[side note: back light level setting work on both displays. I redid the soldering and fixed it. now choosing 3,3v or 5v makes a difference in basic illumination. ]]]

[HV-NL]

I do own a LilyGo TTGO-T (ESP32 with built-in 240x135 1.14" TFT screen, driven by a ST7789. (http://www.lilygo.cn/prod_view.aspx?TypeId=50033&Id=1126&FId=t3:50033:3) However 240x135 is currently not in the display list..... Is it possible to also add this resolution?

[tonhuisman]

However 240x135 is currently not in the display list...

I'll add that resolution, those LilyGo ESP's are quite popular, it seems.

[tonhuisman]

I do own a LilyGo TTGO-T (ESP32 with built-in 240x135 1.14" TFT screen, driven by a ST7789. (http://www.lilygo.cn/prod_view.aspx?TypeId=50033&Id=1126&FId=t3:50033:3) However 240x135 is currently not in the display list..... Is it possible to also add this resolution?

I've added that resolution, @HV-NL please test and report your findings here. Also investigated if other resolutions are used, but I didn't find any that aren't supported yet.

New downloads:

ESPEasy_display_ESP32_4M316k.zip ESPEasy_display_ESP8266_4M1M.zip

Edit: Updated documentation: Display - ST7735_ST7789 TFT — ESP Easy 2.1-beta1 documentation.pdf

[HV-NL]

I tried to test, but no luck! When configuring TTGO-T I cannot select the proper SPI settings on the hardware page:

MISO = N.C.
MOSI = 19
CLK  = 18

[tonhuisman]

Ah, it's currently not possible in ESPEasy to select different from the H-SPI/V-SPI settings. Have to investigate how that can be solved though, as this is hidden somewhere deep down in the dungeons of the (SPI) code 🤔

[tonhuisman]

I cannot select the proper SPI settings on the hardware page:

Have you tried to confirm it really didn't work with the VSPI option on the Hardware page? It may be a case of poor labeling, as happens rather often with China-based hardware 😞

[drone777]

This config works in arduino sketch:

Name	Pin
TFT_MISO	N/A
TFT_MOSI	19
TFT_SCLK	18
TFT_CS	5
TFT_DC	23
TFT_RST	26
TFT_BL	27

On ESPEasy test firmware backlight works.

[tonhuisman]

Hmm, also looked at some other LilyGo modules, like the ones that come with a camera, and they use even different SPI pins, and I've also seen different pin assignments for different hardware revisions of some of these modules, so it is quite a mess there.

@TD-er Should we go for a 3rd SPI option for ESP32 where these 3 SPI pins can be 'freely' configured, similarly to the I2C pins? Re-wiring these modules doesn't seem like a feasible option, AFAICS.

[HV-NL]

I cannot select the proper SPI settings on the hardware page:

Have you tried to confirm it really didn't work with the VSPI option on the Hardware page? It may be a case of poor labeling, as happens rather often with China-based hardware 😞

Yes, I tried. Only the backlight is working, the display stays totally black. No luck.

[tonhuisman]

I've started a trial on adding that extra SPI option, for manually selecting the SPI CLK/MISO/MOSI pins, that would probably be the best alternative.

[TD-er]

Yep, that is probably a good option to make it configurable. ESP32 can map almost any pin to almost any function.

We should define a SPI bus in the hardware tab, like we do with I2C. (I guess that's what you meant too?) That does make more sense I guess, as we "only" have 2 SPI busses on ESP32.

[tonhuisman]

I've got this far:

Initially, I had it set for HSPI:

Then I selected User-defined SPI from the Init SPI combo: (the GPIO selectors are un-hidden like the Serial selector for serial devices 😉) and set the pins according to the table above.

Next step is to wire stuff correctly and test (don't own that LilyGo ESP model 😃)

[TD-er]

This is for ESP32 only I guess, and you probably need it twice. One for HSPI and one for VSPI. And not sure if needed, but I can imagine a SPI plugin should have a selector which SPI bus to use? Not sure if there is a limitation on what pins will be used (or even what SPI bus) for the internal flash and PSRAM (optional) and SD-card (optional)

[tonhuisman]

Yes, only the ESP32 allows to change the SPI pins, and is able to have multiple SPI busses (2, or 3 with some extra effort). (Technically ESP8266 has 2 SPI busses, but the 'other' bus is fixed assigned to read/write Flash storage, and doesn't seem to have the 'overlap' feature of ESP32 FSPI bus). But if we want to have multiple (read: dual) SPI busses, that would probably require an overhaul of all SPI plugins and libraries, as most are written for ESP8266, that only 'knows' of the default SPI object, and use that directly, where a proper implementation would require the to-be-used SPI object to be passed in at initialization. That seems like a (too) big task for now, and should probably be postponed (or not even attempted because of the estimated amount of work). Not sure if the VSPI user-defined configuration should be made available separately, if we keep the current single SPI bus setup, as both VSPI and HSPI (the default) seem to have the same flexibility in pin assignment (AFAICS). A usable option would be to give those 3 pins a double duty, either HSPI or VSPI, by adding a VSPI user-defined option in the combo.

[TD-er]

Nope, we allow to set the pins of a specific SPI bus and then the plugins that need it just address that bus. Just like we do with I2C. I guess there are plugins which have settings for pins, but that needs to be a selection for a bus nr (just like with the serial ports) and not bothered with the pins. Only pin that's plugin specific is the CS pin.

[tonhuisman]

Ok, but that still would require quite some work if we want to introduce another SPI bus, I guess, as there currently is only 1 global SPIClass object, aptly named SPI, and not yet a second one (that could probably be named SPI2). And it would need an attribute in DeviceStruct to enable the use of that second bus, for plugins that have been adjusted to enable the use of SPI2. And then some 'infrastructural' changes, like the pin selectors, showing the pins used for SPI2 etc.

[TD-er]

Maybe the Arduino layer already has some option for this? If not, then just make the "SPI" bus use the predefined pins from the HW tab.

Also not sure if this should be part of this PR for the displays though. Maybe you can make a single test build for those boards, but I think adapting the SPI changes should be a separate commit from the display support. We can of course wait with a new build till both are ready, but I think it will make things complicated if we include a "global" change like this part of of the "display" feature.

[tonhuisman]

adapting the SPI changes should be a separate commit

That's what I had planned already, I will make a local build including these features for testing these specific ESP boards. Once it's working as intended I'll create the SPI-related PR.

[tonhuisman]

I've made changes so a User-defined SPI pin configuration is possible, see Hardware tab, (only available for ESP32 because of hardware limitations), to support the LilyGo ESP32 boards. To activate changed SPI settings, it is strongly advised to perform a hardware reset.

Here are the display builds including the P116 ST7735/ST7789 plugin.

ESP_Easy_mega_20210826_display_ESP32_4M316k.zip ESP_Easy_mega_20210826_display_ESP8266_4M1M.zip

Please report your findings, positive and negative, here.

[HV-NL]

No luck on TTGO-T. Screen stays totally dark, even when I configure black letters on a white background

MISO = 34 (in fact N.C., but this is to prevent the error message on top of the screen)
MOSI = 19
CLK  = 18

[tonhuisman]

I've tested exactly the pin configuration as listed by drone777, only using a 240x240 display configured for 240x135px, and it worked as intended (though it will then only update the top 240x135 area, of course). You have reset the unit after changing the SPI settings, I assume? (Removing the power for 30 seconds, then re-applying, may help too.)

And you have to either enter some text in the Lines 1..14 fields (should be enough to get at least something on those 13.5 lines available), or send it via the Tools page, f.e. using st77xx,txt,"Hello World".

[HV-NL]

Yes: the 30 seconds power-off did the trick. Now the screen is showing my lines. I already had rebooted several times, but it looks like that was not sufficient. To power-off completely did the trick!

Rotation does not work as expected yet.

normal        : partly usable screen, otherwise noise
+ 90 degrees  : showing lines 1..13
+180  degrees : partly usable screen, otherwise noise
+270 degrees  : text on opposite side of the screen, showing lines 1 .. 13

I tried both 'write command trigger' = tft as well as st7789

I just tried 'normal' (without a reboot or hardware reset). Now I see the last 4 characters of my IP address somewhere in the middle of the screen. Looks like an initialisation problem

The image below is using rotation 'normal'. The contents of the first lines is:

line 1: "%ip% line 1 line 1 line 1 line 1" (192.168.11.86, only showing '1.86')
line 2: "line 2 is extra lang omdat die anders niet getoond wordt"

[drone777]

Got working when embedded battery discharged. Means simple reboot did not help to change parameters.

CLK: GPIO-18 MISO (unused, bet must set somthing): (GPIO-4) MOSI: GPIO-19 CS: GPIO-5 GPIO-23 GPIO-26

TFT display model: ST7735 80 x 160px Write Command trigger: st7735

Display button works too.

[drone777]

Started playing with back/fore-ground colors. Found colors inverted (white->black, red->cyan, green->yellow).

[tonhuisman]

drone777:

Started playing with back/fore-ground colors. Found colors inverted (white->black, red->cyan, green->yellow).

That's a bit strange, as both these chip families use RGB565 colors, and on the ST7789 I've used so far the colors look as they are named (and I'm not color-blind 😉). It sounds like some wiring error, or you've found a model that's set up for BGR565 (that also seems to be available, though I haven't found any yet)

HV-NL:

Looks like an initialisation problem

Most likely the display is connected as 135x240 instead of 240x135, as I have assumed. I've made a build with those parameters swapped, can you please test again?

(Updated, see below)

[HV-NL]

Most likely the display is connected as 135x240 instead of 240x135, as I have assumed. I've made a build with those parameters swapped, can you please test again?

Yes, good guess! Now the TTGO-T display is OK

[tonhuisman]

Great 👍

[HV-NL]

TTGO-T seems to be a 'strange' display. Using '+ 90 degrees' now gives the reverse effect :-(

[tonhuisman]

Hm, looks like I may have to order one myself to really fix that. I've seen some wonky initialization code in the library used, I'll have a closer look at that soon. Or the library wasn't tested properly with this type of display yet.

Does the +180 settings rotate the content as expected?