ESP32&mega-20220427 possible P095 broken tft commands support.

[sobolkz]

Hi all! Due to updating my old project for Air Quality Sensor I'm trying to create new one with ESP32 and Color TFT 2.4 ILI9341 Wemos shield. First one was maked at mega-20220328 version - look's good and work. But when I was upgrade firmware to latest mega-20220427 display issue was expected. Due to my way display was used with native "tftXXX" commands and it's update information with 4 screens each 10 seconds by cycle. As I see new firmware include new version of P095 plugin with new functionality, but this functionality looks buggy instead old one - native plugin "tftXXX" commands isn't working now. But, as I see in log - all was good, "rules" code work as designed. "ili9341" type of new plugin was also tested- static text can be displayed. Is it possible to fix this issue?

[tonhuisman]

What kind of commands are not working as expected? (examples please) All functionality has been preserved (and extended), but the biggest 'change' is that the command parsing has been implemented using the more strict parseString() function, that requires to use quotes around strings that have spaces or commas, to have them handled as a single value. In the plugin there is the possibility of selecting the command-name to be used, including tft (default, and automatically tftcmd where required).

[sobolkz]

Any command, for example tftcmd,clear,green as provided in P095 plugin guide. Also - there is no "Espeasy" message at screen after booting instead old versions of firmware. P.S. - quotas also can't be recognized in new version: Command unknown: "tftcmd,clear,green" instead OK for tftcmd,clear,green independent of versions.

[tonhuisman]

Any command, for example tftcmd,clear,green as provided in P095 plugin guide.

That's quite weird,as it has been tested extensively. NB: If you have changed the command from tft to ili9341, then these plugin-specific commands (not generic AdafruitGFX_helper commands) also need to be changed to ili9341cmd, as is explained in the documentation for P116 (ST77xx), but that isn't yet included in the P095 (ILI9341) documentation, as it is in the pending PR #3903, adding support for more ILI93xx based TFT displays.

Also - there is no "Espeasy" message at screen after booting instead old versions of firmware. P.S. - quotas also can't be recognized in new version: Command unknown: "tftcmd,clear,green" instead OK for tftcmd,clear,green independent of versions.

The splash message is not enabled by default, and is a compile-time option, so can not be enabled via settings. I left it out of the standard build to save a few bytes of .bin size, and as it will be overwritten quite soon, f.e. when having Lines setup in the configuration or from Rules, it doesn't seem that useful. It can be made a configuration option if required/desired, but why would you need it to be enabled?

[sobolkz]

Ok, let's speak about tft command scope instead ili9341. Is it correct, that native tftcmd,clear,green should work without any additional quotas and symbols? I have another problem with deep sleep (I think it's WiFi connection issues), that can be fixed in future builds, but new builds look's bad due to display interoperability.

[sobolkz]

Also, backlight GPIO plugin support was checked - as described in manual command like tftcmd,off with configured GPIO should switch off backlight, but really it shouldn't - backlight level can be controlled in % by PWM but can't be totally switched on\off. It's look like SW issue instead HW.

[tonhuisman]

let's speak about tft command scope instead ili9341. Is it correct, that native tftcmd,clear,green should work without any additional quotas and symbols?

Correct, as in this case each argument does not contain any commas or spaces, no quotes are needed. As stated before, the documentation is not fully up to date yet, so when the Write Command Trigger is set to ili9341, the command to use here would be ili9341cmd,clear,green. To add to the confusion, the clear subcommand is also implemented in the AdagruitGFX_helper module, meaning you can also use tft,clear,green or ili9341,clear,green, depending on the setting for Write Command Trigger 😃

I have another problem with deep sleep (I think it's WiFi connection issues),

Please elaborate? The plugin has a setting to wake the display on receiving text. When turning that checkbox off, combined with the Display Timeout option, it will only 'wake up' when the Display button is used (assuming you have that configured, and also a Display Timeout > 0 seconds is set). It is possible to use a sensor to wake the display, either via hardware connection (PIR sensor?) or a distance sensor via Rules.

backlight level can be controlled in % by PWM but can't be totally switched on\off. It's look like SW issue instead HW.

Backlight control is implemented using PWM, and unfortunately PWM on ESP32 (only) is broken in the 20220427 release, but has been fixed since. This has not been released yet, though. You can download from the Actions tab a more recent PR build to have that fix, or build your own .bin based on current state of affairs on the mega branch.

[sobolkz]

Correct, as in this case each argument does not contain any commas or spaces, no quotes are needed. As stated before, the documentation is not fully up to date yet, so when the Write Command Trigger is set to ili9341, the command to use here would be ili9341cmd,clear,green. To add to the confusion, the clear subcommand is also implemented in the AdagruitGFX_helper module, meaning you can also use tft,clear,green or ili9341,clear,green, depending on the setting for Write Command Trigger 😃

Hmmm, else if type of plugin was checked correctly neiter ili9341cmd,clear,green nor tftcmd,clear,green wasn't successful - screen absolutely clean and white instead green as requested.

Please elaborate? The plugin has a setting to wake the display on receiving text. When turning that checkbox off, combined with the Display Timeout option, it will only 'wake up' when the Display button is used (assuming you have that configured, and also a Display Timeout > 0 seconds is set). It is possible to use a sensor to wake the display, either via hardware connection (PIR sensor?) or a distance sensor via Rules. It's about your

as is explained in the documentation for P116 (ST77xx),

P116 documentation contains this:

Switch the display off. If the Backlight is connected and configured, that will also be turned off.

"Diplay Timeout" is little bit different setting.

Another hmmm :-)

Backlight control is implemented using PWM, and unfortunately PWM on ESP32 (only) is broken in the 20220427 release, but has been fixed since. This has not been released yet, though.

As I can see - PWM is working for me in any release. I can control backlight level also in 20220427 release. Old versions - by Rules or Commands, 20220427 release - by plugin settings.

[tonhuisman]

Backlight control is implemented using PWM, and unfortunately PWM on ESP32 (only) is broken in the 20220427 release, but has been fixed since. This has not been released yet, though.

As I can see - PWM is working for me in any release. I can control backlight level also in 20220427 release. Old versions - by Rules or Commands, 20220427 release - by plugin settings.

Hm, I may have mixed up the dates, then it didn't work right after the 20220427 release when the Platform IDF 4.4 was merged, but that has been fixed, as said.

neiter ili9341cmd,clear,green nor tftcmd,clear,green wasn't successful

I'm still troubled with this finding, what can you see in the log (either serial log or weblog) after you submit that command, does it state OK or another message?

[sobolkz]

I'm still troubled with this finding, what can you see in the log (either serial log or weblog) after you submit that command, does it state OK or another message?

In the Tools-Commands window I can see OK as result of ili9341cmd,clear,green command for ili9341 type and tftcmd,clear,green for tft type in plugin. Also I can see another results like "Command unknown:" for example if unsported trigger was used. Same result for any other supported commands. BUT there is no visual changes after command was processed with OK as result.

[tonhuisman]

@sobolkz I have done some investigation, and found a possible cause. I have also developed an extension on P095, adding several ILI934x and ILI948x displays to this plugin. During that coding I have probably fixed a few bugs that where in the regular code, I just can't remember the exact details as that has been some months ago. I have started a build for that pull request, but there is some issue causing the build to fail, so you can't downl;oad an updated build from there. I can upload a local build here for you to test, what exact build (.bin filename) are you using? Or when creating a custom build, what plugins (P-numbers if possible) are the minimum you need?

Edit: Or download the last successful build for the extended P095 features from here (download the Binaries.zip file, that has a .zip file per build configuration)

[sobolkz]

Edit: Or download the last successful build for the extended P095 features from here (download the Binaries.zip file, that has a .zip file per build configuration)

No results. I can only say, that now display turning off backlight after booting instead previous full backlight level. And GPIO,32,1 can't turn it on back. Also backlight turning on if device was deleted from configuration and board was rebooted.

[tonhuisman]

If you revert to the 20220328 release of ESPEasy, you started off with, does the display then work again?

[sobolkz]

Yes. I can see splashscreen and almost work as needed. One another moment - GPIO32 line connection in my scheme isn't pulled down by resistor, therefore due to electromagnetic pickups from the finger a can "control" backlight by finger at cable. But you test version doesn't do this. For example because GPIO32 pulled down in code, try to check it.

[tonhuisman]

and almost work as needed.

Please elaborate on what doesn't work as expected?

I can't say anything about GPIO32 on your board not working as intended, can you try to connect another GPIO pin? (not GPIO 34..39 as they are input-only). The software doesn't pull it up or down, other than control it via PWM to control brightness.

[sobolkz]

Let's abstract from the problem of backlight control. I can connect display's PIN to high. It doesn't important. Important, that if I was upgrading board to you test version I can't see nothing on display as minimum because new functions was added in plugin. Maybe it's backlight control problem, maybe some block code,which cause faults in exchange between board and display. I can record video and demonstrate difference between old releases and new one with you additions.

[tonhuisman]

The code has mostly been tested on ESP8266, as that's where my ILI9341 display is connected to. In around 10 hours from now I'll connect the board to an ESP32, to see if it is working as intended. I'll also try to use GPIO32 for backlight, assuming my board has that pin available externally.

Looking at this comment, it is working on ESP32 for other users. The later comments are about using the Roboto font, and that has been added only a few days ago, based on the latest ESPEasy builds with up to date Arduino framework. I've made a custom ESP32 build available for download in one of the comments that you can try as well.

[sobolkz]

I can test it on D1 mini pro to, but it little bit difficult due to connection. I'm using native Lolin boards with TFT cable instead PIN headers. And, by default GPIO32 doesn't connected at display board to PIN header for D1 boards. It should be soldered separately. So, I think main target is to locate problem in code. Is it help if I'll check plugin by static text for "lines" inside instead of dynamic text in Rules?

[tonhuisman]

Any additional testing here is helpful, as the plugin is working OK for me and others.

[sobolkz]

At this time I can say, that test version working good for me. Full update (.factory file) was successfully fix the issue. I will check more completely and inform you.

[sobolkz]

All look's good. But I have a question about new functionality of P095. As I can see there is lot of improvements for better and easiest operations with TFT displays. Due to added backgroung and foregroung colors manipulation - is it possible to disable it for work with tft commands? Now, then my code is working I'm see, that some parts of image looks like as described in plugin and not as transferred in tftXXX command. For example - custon backgroung and text color was changed around text for some sensor's data to plugin's settings (black backgroung and white text).

[tonhuisman]

I don't fully understand what you mean, can you show a photo of how it looks, a screenshot of the 'Lines' part of your device configuration, and any rules, or commands, you use to show the data on the display?

[TD-er]

I think it keeps on using the last set background color. So when you then update some text in another area of the screen it will use the last set background. Not tested myself, but that's what I got from his description.

[tonhuisman]

This is the list of supported commands (skip the first st77xxCmd subcommands, these are plugin-specific, but similar commands exist for tftCmd).

Using the tft,txc,<foreColor[,<backgroundColor>] command sets the foreground and optionally the background color, that will be used in f.e. the txt and txp subcommands. When using the txtfull subcommand, the foreground and background colors can optionally be specified, and if not provided, the previously set colors will be used, using a 'transparent' background, unless an explicit background color is specified.

[sobolkz]

Ton, my mistake! Code should be updated because:

command parsing has been implemented using the more strict parseString() function, that requires to use quotes around strings that have spaces or commas, to have them handled as a single value.

I'll do it soon.

[sobolkz]

@tonhuisman, new code- new strange messages :-) There is code from rules

on Rules#Timer=5 do

tftcmd,clear,black tftcmd,rot,3 tft,txtfull,0,20,3,WHITE,Date: tft,txtfull,100,20,3,GREEN,%sysday_0%:%sysmonth_0%:%sysyear% tft,txtfull,0,60,3,WHITE,Time: tft,txtfull,100,60,3,GREEN,%systm_hm% tft,txtfull,0,100,3,WHITE,Sunrise: tft,txtfull,150,100,3,GREEN,%sunrise% tft,txtfull,0,140,3,WHITE,Sunset: tft,txtfull,135,140,3,GREEN,%sunset% tft,txtfull,0,180,3,WHITE,Battery: tft,txtfull,150,180,3,GREEN,[VBAT#Batt]" V" timerSet,2,10 endon

There is log output

57239: :0 0 57241: :1 140 57245: :2 3 57247: :3 WHITE 57249: :4 Sunset: 57250: :5 57251: AdaGFX: command: tft argCount: 5:tft,txtfull,0,140,3,WHITE,Sunset: 57252: invalidCoordinates: X:0/240 Y:140/320 57261: ReplacementString SunTime: %sunset% offset: 0 57265: RuleDebug: 000: tft,txtfull,135,140,3,GREEN,20:13 57267: ACT : tft,txtfull,135,140,3,GREEN,20:13 57271: Command: tft 57273: tft,txtfull,135,140,3,GREEN,20:13 57275: Par1: 396 Par2: 135 Par3: 140 Par4: 3 Par5: 3 57279: AdaGFX: parse result: 'tft,txtfull,135,140,3,GREEN,20:13' 57281: :0 135 57283: :1 140 57286: :2 3 57287: :3 GREEN 57289: :4 20:13 57289: :5 57290: AdaGFX: command: tft argCount: 5:tft,txtfull,135,140,3,GREEN,20:13 57292: invalidCoordinates: X:135/240 Y:140/320 57298: RuleDebug: 000: tft,txtfull,0,180,3,WHITE,Battery: 57300: ACT : tft,txtfull,0,180,3,WHITE,Battery: 57304: Command: tft 57306: tft,txtfull,0,180,3,WHITE,Battery: 57307: Par1: 400 Par2: 0 Par3: 180 Par4: 3 Par5: 3 57312: AdaGFX: parse result: 'tft,txtfull,0,180,3,WHITE,Battery:' 57314: :0 0 57316: :1 180 57318: :2 3 57319: :3 WHITE 57322: :4 Battery: 57323: :5 57325: AdaGFX: command: tft argCount: 5:tft,txtfull,0,180,3,WHITE,Battery: 57327: invalidCoordinates: X:0/240 Y:180/320 57334: Read settings: TaskSettings index: 0 57351: Read settings: TaskSettings index: 1 57372: DEBUG DEV: Parsed String='tft,txtfull,150,180,3,GREEN,4.21' 57375: Read settings: TaskSettings index: 31 57388: RuleDebug: 000: tft,txtfull,150,180,3,GREEN,4.21' V' 57390: ACT : tft,txtfull,150,180,3,GREEN,4.21' V' 57394: Command: tft 57395: tft,txtfull,150,180,3,GREEN,4.21' V' 57398: Par1: 483 Par2: 150 Par3: 180 Par4: 3 Par5: 3 57402: AdaGFX: parse result: 'tft,txtfull,150,180,3,GREEN,4.21' V'' 57404: :0 150 57406: :1 180 57408: :2 3 57410: :3 GREEN 57410: :4 4.21' V' 57411: :5 57412: AdaGFX: command: tft argCount: 5:tft,txtfull,150,180,3,GREEN,4.21' V' 57413: invalidCoordinates: X:150/240 Y:180/320

Why "invalidCoordinates" if Text Coordinates in col/row: isn't checked: And offset was checked:

[tonhuisman]

You seem to have the loglevel set to DEBUG_DEV, and that implies you can expect a lot of log output that (probably) doesn't make sense to you, unless you are working on the code. In this situation, invalidCoordinates is the function that does the coordinate-argument checking, and it logs the provided/max values at DEBUG level. This is not an error message. Please do not log at DEBUG (or more verbose) level if you are not in development or debug mode. If you are developing, then you can check the code to see why it is writing that log.

[sobolkz]

Ah, OK, thx!

[sobolkz]

So, it seems, that you version are working as designed. I can use it?

[tonhuisman]

I'm currently working on a fix related to updating content in-place, so maybe wait a few days for that to settle. I'll add it to an open PR, that adds support for more hardware types of ILI9xxx displays (#3903)

[sobolkz]

By the way - another problem was in waking up from deep sleep, it's gone in test release.

[TD-er]

By the way - another problem was in waking up from deep sleep, it's gone in test release.

Yeah, we're not only adding new bugs on every new build ;)

[tonhuisman]

I've fixed some of the issues mentioned (related to not correctly overwriting text even when using a specific background color), so you could get the latest source from the PR linked just above this message. Or download a complete build from the Github Actions page for that PR-build.

[sobolkz]

@tonhuisman, @TD-er perfect. All works as planned. I'll work with this PR-build and wait new release.

[sobolkz]

@tonhuisman, by the way, is it possible to add information about supported characters list for default font into plugin documentation? Look's like some special characters doesn't supported. For example {u} and {D} can be displayed at ILI9341 but {^3} can't.

[tonhuisman]

Except for the default fonts (default, sevenseg18, sevenseg24 and freesans) I have used fonts from a free font site, and converted those to the supported format using a website dedicated to that. I'm not sure if that site does not convert all characters available, or that the fonts just don't have these special characters. I'll do some investigation.

Edit: Added links.

[sobolkz]

Except for the default fonts (default, sevenseg18, sevenseg24 and freesans) I have used fonts from a free font site, and converted those to the supported format using a website dedicated to that. I'm not sure if that site does not convert all characters available, or that the fonts just don't have these special characters. I'll do some investigation.

As I understand default fonts in ESPEasy doesn't have this characters. But if we are speaking about website dedicated to that it has:

[TD-er]

Thanks, bookmarked it for future use :) Maybe we should also link to it in the documentation.

[tonhuisman]

It will be shown there, but the Adafruit fontconvert tool by default only handles characters from ` (space) up to~` (tilde), see this line of the tool (can be overridden from the command-line, but the website doesn't support 'fancy features' like that 😃). Including those high ASCII characters will more than double the size of the data used by the font, so that's also a factor to consider.

---

OT: That font site is owned by 'the original hacker' Rop Gonggrijp (of Hack-Tic magazine and XS4ALL fame), originally from NL, currently living in Berlin, Germany (or so it seems).

[TD-er]

Ah, the one that played chess on a voting machine, about 15(??) years ago. A true hero!

[sobolkz]

It will be shown there, but the Adafruit fontconvert tool by default only handles characters from ` (space) up to~` (tilde), see this line of the tool (can be overridden from the command-line, but the website doesn't support 'fancy features' like that 😃). Including those high ASCII characters will more than double the size of the data used by the font, so that's also a factor to consider.

I think documentation and "System variables" list should be updated due to this limitation. Or special characters, mostly used in plugins like mg\m3 listed in "System variables" added to default fonts ;-) My internal perfectionist are crying because he can't see something like m%c2%b3, which can be used as decribed in documentation.

[tonhuisman]

My internal perfectionist are crying

I have a similar guy too 😉, but technical limitations are blocking the further pursuit of this:

• The font converter doesn't currently handle ASCII characters > 127 (0x7F), so the result is unknown
• The converted font is a table, where the current character, with an offset, is the index pointer, making the data more than twice the size of the current font. Most builds won't permit that kind of bin size increase
• The current conversions for special characters is based on the (different) fonts for OLED and LCD2004 displays, so the mapping is only partial. This I ~can~will fix, but has to be looked into.

Using the <trigger>,asciitable command you can view what characters are supported, for the default font it looks like this:

(WT32-SC01 display)

But as you can see, the ³ character isn't even there 😞 And for other fonts, the default table-offset of 0x80 will show empty, as the data isn't available.

[sobolkz]

• The current conversions for special characters is based on the (different) fonts for OLED and LCD2004 displays, so the mapping is only partial. This I ~can~will fix, but has to be looked into.

Yep, he are crying because old revision of my sensor was based on SSD1306 and the ³ character was looking perfect. New one is colored, therefore I can shut him up 😃

[tonhuisman]

A blunt trick could be that instead of the superscript 1 and 3, I can insert a regular 1 or 3, so there isn't any void there 😜

[sobolkz]

A blunt trick could be that instead of the superscript 1 and 3, I can insert a regular 1 or 3, so there isn't any void there 😜

Almost done 😉

[tonhuisman]

This is what I've got now:

The ALT: line has this: {^1} {^3} {3_4} {x} (alternative character used, symbol not available in font) The OK: line has this: {^2} {1_4} {1_2} {..} {E} {D} {<<} {>>} {u} {Y} {P} {c} (supported symbols) The Flex: line has this: {0xE3A89E9FE7FA} (new feature, using the {0x prefix and } postfix, groups of 2 hex digits can select any character in the font, separators allowed: ,.:;- space, comma, dot, colon, semicolon, dash) Edit: hex values separator support added.

[sobolkz]

Ton, as I understand you commits doesn't included into mega-20220616? Another issue with 16MB flash was fixed, but display seems to be not working at last release. I rolled back to your test release for mega 16M8M flash.

[tonhuisman]

The PR isn't merged into mega yet, having too many big changes in a release can be rather disturbing.

[sobolkz]

@tonhuisman, focusing at point with size of full characters scope - is it possible to add fonts with all characters into max build for ESP32 16M8M? Or it's very limited and specific task for you time?

[tonhuisman]

is it possible to add fonts with all characters

As I said before, technically it is possible (though limited to ascii values 129..255), but not very easy to do, as the font-converter tool (linked above) does not 'officially' support that. And doing the conversion by hand is, at least for me, very time-consuming...

Have been thinking of an alternative way, that would allow to 'write' any graphic shape, independent of font, to the display, but haven't decided on (or coded) that yet.

[TD-er]

You could add something like bitmaps which then can be uploaded to the file system with a prefix name and the hex code of the character in the filename. This will for sure not be the fastest in execution, but it is the most flexible. Also it places the burden of converting the characters to those who need them.

I have designed my own fonts for my MSX back in the 80's and I know how much work it is. This was done with pen and paper, then converting it from binary to BASIC code by hand, typing it in etc. And then you also had to "rotate" it to be able to print it as the printer head was addressed vertically while the font was horizontally defined in the frame buffer.