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.

[HV-NL]

I just checked an ESP8266 with an '1.8 SPI 128x160' TFT module. That one seems to work OK in all directions. When switching directions this unit does not have to be powered-off, those modifications take place directly. Perhaps the ESP8266 library is more mature, and initialisation is more complete than the ESP32 library that is currently in use.

Does the +180 settings rotate the content as expected? Yes, both 'normal' and +180 now work as expected on the TTGO-T

[drone777]

ESP32 0.96 ST7735 80x160 rotation works just after submiting changes.

[tonhuisman]

Perhaps the ESP8266 library is more mature, and initialisation is more complete than the ESP32 library that is currently in use.

No, the ESP8266 only has 1 SPI option (on/off), where the new ESP32 user-defined settings now allow for much more flexibility, but seem to require at least a hardware reset before the changed settings are actually applied. As is already noted on the Hardware page, but may need to be worded a bit more explicit (I'll change that). Simply enabling/disabling, the only available option for ESP8266, is a much 'cheaper' operation.

[tonhuisman]

HV-NL, can you set the rotation Normal, and try the st77xx,rot,1 command, to confirm my suspicion on a certain feature of the library?

[HV-NL]

st7789,rot,01 OK (but no effect visible in the display)

I tried 0 - 3 (other values give 'Command unknown'). All result in 'OK', but no visible effect at all

[tonhuisman]

After that you will have to also issue a taskrun,<taskname> command to re-display the standard content. That Rotate command will only set things up for follow-up commands, it doesn't necessarily know the current content, so can't resend it automatically.

[HV-NL]

st7789,rot,01 taskrun,display_240_135

[tonhuisman]

Hm, close but no cigar.

[tonhuisman]

I've been bug fixing (and waiting a short while for such module 😄), so now the rotation related issues have been resolved. Tested using 135x240, 240x240 and 240x320 ST7789 displays.

Here is the ESP32 build that includes the User-defined SPI GPIO settings:

(Updated, see below)

[HV-NL]

I did some tests, but the results are not yet as I expected. Rotation 'normal' and rotation '+180°' look fine, but rotation '+90°' and rotation '+270°' give unexpected results. (I use the default 'truncate exceeding message' during my tests)

I did my tests with some long and some shorter lines:

This is initially shown on the 135x240 display (looks fine):

But when I start with rotation 90, then (after a reset, so starting with an empty screen) all lines are partially truncated, e.g. "line 04 line 04 line 0" i.s.o. "line 04 line 04 line 04 line 04"

Next test: no reset, but use a command to rotate. I start with rotation 'normal' or '90°', so the screen is filled normally. When I next submit the command "st7789,rot,1", followed by "taskrun,display_240_135" I see text in 2 directions (because the lines are truncated I partially still see the original contents)

[tonhuisman]

Hm, that sounds exactly like the behavior before I fixed those rotation bugs, so either I uploaded the wrong build zip, or your flash update failed 🤔 I've fixed more bugs today, so a new build is available. Because of the specific needs of this hardware I'm including the User-defined SPI settings feature (ESP32 only) here:

(Updated, see below)

I've flashed it on my test-unit, and the initial display, on +90 degrees, looks like this: (initial also means the IP address is still 0.0.0.0, and Sunrise/sunset 0:00)

(I really don't like that the backlight pin is connected to GPIO 4, same as the on-board WiFi led (blue light on left bottom) 😞)

This is my Content: (nb: Text print Mode is set to Truncate exceeding message, and background color is navy)

Edit: Issued these commands: st77xx,clear then st77xx,rot,0 and taskrun,1 (it's on my 1st device), giving this result:

[HV-NL]

I was testing with version Aug 31 2021 21:12:22

You are initialising the display yourself, due to the first line "~txc,white,blue~~txs,3~ESPEASY". In my tests I did not instruct the display to use any other color or size than default.

I just did a quick test with the latest version. Initially I got exactly the same (truncated) lines as before (using my test configuration as described previously). Then I entered your text in line 1, 2 and 3. That was BINGO: now the lines were no longer truncated.

So I tried a mix of my lines and your lines (i.e. re-initialise at some moment (line 2), and after that line no trucation occurs any more)

This is my new test configuration:

%ip% line 01 line 01 line 01 line 01
~txc,blue,white~~txs,2~ST7789 ST7789 ST7789
~txc,white,navy~~txs,1~%ip% line 03 line 03 line 03
line 04 line 04 line 04 line 04 line 04
abcdfefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
line 06 line 06 line 06 line 06 line 06  
line 07 line 07 line 07 line 07 line 07 

Please look to the first line: that line is still trucated. Line 2 and all others are OK (i.e. not truncated), seemingly due to the re-initialisation that has occurred in line 2 "~txc,blue,white~~txs,2~ST7789 ST7789 ST7789"

[tonhuisman]

It took a bit of time, but I found the bug, and fixed it. Thanks for pointing it out! As usual, any assumption (I) made is wrong 😄 (The text size wasn't recalculated when changing the rotation, but the txs,2 command does that in the example. Using txs,1 in line 1 would have also 'fixed' it.)

A new build is available (ESP32 including the User-defined SPI pins feature): And for ESP8266 the regular Github actions build: (Updated, see below)

[TD-er]

Just curious, how difficult is it to (optionally) make large fonts with high resolution? It could also be a subset of a full character set if it makes the fonts unusable large.

I just bought this bench multimeter and I like the way how it represents values and settings: So maybe we can make menu page helpers later to allow for similar instrumental setups.

Just as an inspiration, not to copy/clone it.

[tonhuisman]

Yes, that's looking quite nice. (and inspiring) The standard font 'scaling' is a multiplication factor, so currently larger font sizes are quite 'blocky', no interpolation at all is done. The extra fonts (to be enabled in a custom build) add quite some size to the .bin file, but could also be workable on a MAX build, I think. The font conversion site here can take any true-type font and convert it, but most usable are mono-spaced fonts. I'll convert & add a few more, (somewhat) larger fonts, just for fun.

[TD-er]

Can you also use (small) bitmaps? Just trying to gather some ideas in my head.

Just thinking out loud, I am thinking of some state handler concept to allow automations. A menu with user interaction is one of those. So we can have some button which -when pressed- changes a state in this state manager and when changing a state it can send a number of commands. It can of course also be done in rules, but that's prone to errors and a lot of work when extending the state machine. Not only button presses, but also a rotary encoder, etc.

For Nextion displays, you run these on the display self, but I guess it would be very useful for other task automations. Some state can have its own "member" values, like strings what to display on what position on a display. (e.g. a "page" on the Framed OLED plugin)

[tonhuisman]

Bitmaps are supported by AdafruitGFX, but they are in an specific format, so I could add something like <trigger>,spb,<nr>[,fgcolor[,bgcolor]] (spb = show predefined bitmap, I want to reserve bmp for actual bmp file support I might add in a separate PR once this is merged). It would be a compile-time option, I guess, as not everyone will need that feature, and it probably won't fit well in the 'size challenged builds'. We only have to find a usable set of those predefined bitmaps 😉.

Edit: And I did add support for 'buttons' in the XPT2048 touchscreen plugin (P099), but all of the drawing, and most of the handling, have to be done in rules, currently.

[HV-NL]

It took a bit of time, but I found the bug, and fixed it. Thanks for pointing it out! As usual, any assumption (I) made is wrong 😄 (The text size wasn't recalculated when changing the rotation, but the txs,2 command does that in the example. Using txs,1 in line 1 would have also 'fixed' it.)

Check! Now my lines are shown as I expected! Thanks!

[tonhuisman]

how difficult is it to (optionally) make large fonts with high resolution?

I downloaded a font called Amerika sans (from a free fonts site, chose it because it's round and curvy) and converted it in 16pt size into a AdafruitGFX compatible font (.h file). (Had to implement a font-specific vertical offset option, but that was due anyway.) Then put it on the screen (font scaling is 1, just like the default font showing the IP-address in the 3rd line), and the resolution is quite nice. This is on a 2" 240x320px display:

Bigger font sizes are possible, 18 or 20pt would still work out ok, but as we can't scale below a factor 1, it might get too large to be useful. And this font adds 4.2kB to the .bin file.

[TD-er]

Well 4k for a special purpose build is not too bad. The fonts for the Framed OLED plugin are also quite large.

So now we need to find a good looking font which does have monospaced numbers (decimal dots can have different size) for showing live updating measurement data and we can make a nice looking instrument.

But this can be done in a later PR :)

[tonhuisman]

This looks like a nice, fixed width, font: https://www.1001freefonts.com/white-rabbit.font I already have it included in 8pt and 12pt, but adding it in 16pt (maybe 18pt) and 20pt sounds reasonable.

[TD-er]

Yep looks nice :) It has a touch of retro and still doesn't look too '80s. ALso it has a dash through the 0, which is nice.

[tonhuisman]

The User-define SPI pins feature has been merged, so that is now available in all ESP32 builds.

Here are the updated builds: ESPEasy_display_ESP32_4M316k.zip ESPEasy_display_ESP8266_4M1M.zip ESPEasy_max_ESP32_16M1M.zip (Includes all fonts, but requires an ESP32 with 16MB flash!)

Attention If you have used a pre-release ESP32 build before, and have configured User-defined SPI pins, then first thing to do is select the Hardware tab and re-enable the User-defined SPI setting again (GPIO pins should still be correct), or the ESP will crash when trying to display the Devices list, as the settings-value for this option has changed from previous builds. Attention

[Stromer66]

is it possible to change fonts in ESP8266 4M1M and ST7735? i try ~font,freesans~easy but no success.

this plugin is very good! thanks!

[tonhuisman]

I've created a custom ESP8266 4M1M build and included all available fonts, for you to test, as all fonts won't currently fit in the Display builds (they are only included in the MAX builds, by default, but you'll need an ESP32 with 16MB Flash for that) ESP_Easy_mega_20211207_custom_ESP8266_4M1M.zip

And also a pdf of the documentation: (Updated: 2022-03-20) Display - ST77xx TFT — ESP Easy 2.1-beta1 documentation.pdf

[Stromer66]

Hi Ton,

thanks for your fast reply. in this build the fonts work, but if i use a different font as default in combination by the interval setting, the displayed value will not cleared. if i coose default font the value displayed correctly.

[tonhuisman]

I have seen this behavior when omitting the background color from the command (or using a text sub-command that doesn't have (background) color arguments). Changing the used sub-command could solve that. When using predefined content in the device configuration, you can change the "Text print Mode" option to "Clear then truncate exceeding message", from the default "Truncate exceeding message".

[tonhuisman]

I may need to have a look at the way the extra fonts are generated, may have something to do with some kind of 'transparency' in the fonts.

[tonhuisman]

Keeping documentation for P116 updated in this comment