Arduino_GFX v1.4.7 issue with NT35510 display driver

[PeteB27]

Hoping someone might spot something I've overlooked regarding the latest v1.4.7 library.

I've been using TFT LCD NT35510 driver (16 bit parallel) with your Arduino_GFX v1.3.7 and the Adafruit_GFX fonts library since mid 2023.
The code build with v1.3.7 was throwing up lots of warnings, with lots of PINK color redefinitions, but I was putting up with the code build warnings since it otherwise worked.

I've now tried your new Arduino_GFX v1.4.7. No build warnings (lovely), but runtime output to the display was a shocker with X,Y placement issues, characters getting "torn" and even simple string placements like "1.2345" getting placed in weird locations on the display.
The Adafruit font set has a nice assortment of fonts that I prefer.

I thus tried back-stepping through your previous Arduino_GFX releases; v1.4.6 was also no good, but found that v1.4.5 seems to be ok; fonts appear good and code compiles without warnings, so that's what I'm staying with at this stage.

In investigating v1.4.7 in case I might be doing something wrong, I've tried with display rotated and not rotated but I see the same problematic behaviour with v1.4.7 (and v1.4.6) exists.

Please see display and sample code examples att. Both displays are built with the same ino file code but with Arduino_GFX v1.4.5 vs v1.4.7 output behaviour where with v1.4.7, various x/y offsets are apparent, characters can have obscure Y offsets, character spacing changes, the string "Medium" ends up with scattered "e", "i" & "m" characters (and the other 3 characters are missing).
The long 14 digit floating number only has 4 characters painted, all scattered.

Platform: Arduino MEGA2560
Compiler: IDE 1.8.19
Display : NT35510 400x800 TFT

Sample fonts are (see code)

For what it's worth, code build log uses libraries::
Using library GFX_Library_for_Arduino at version 1.4.5
Using library SPI at version 1.0
Using library Wire at version 1.0
Using library Adafruit_GFX_Library at version 1.11.7
Using library Adafruit_BusIO at version 1.14.1

Display photos att.
Arduino_GFX v1.4.5.jpg when using Arduino_GFX library version 1.4.5
Arduino_GFX v1.4.7.jpg when using Arduino_GFX library version 1.4.7

Code: see att Demo20240718.ino

Demo20240718.zip

[moononournation]

Yes, Adafruit have some updates on font data structure, please use latest font files.

[PeteB27]

Libraries now updated but the only font that came out ok on the display were "classic", (NULL font) and the very small TomThumb font.
Everything else was a total mess with strings scattered all over the place. See todays new screen shot.

Using library GFX_Library_for_Arduino at version 1.4.7
Using library Adafruit_GFX_Library at version 1.11.9
Using library Adafruit_BusIO at version 1.16.1

I did try unwinding the GFX_Library_for_Arduino back to v1.4.5 and everything returned to normal and good on the display.

[moononournation]

you should update the font file instead, not the adafruit library.

[PeteB27]

Apologies if I still misunderstand.
I find the Fonts folder files were updated with the 1.11.7->1.11.9 update, yet I'm not seeing any changes within the files:
Adafruit_GFX_Library\Fonts .h files updated 11-Oct-2023 for v1.11.9
Adafruit_GFX_Library\Fonts .h files updated 19-July-2023 for v1.11.7

Are the updated font files you refer on the master path or one of the various branches?

In https://github.com/adafruit/Adafruit-GFX-Library/tree/master/Fonts , the master files there also appear to be identical to the .h font files I already have.

I presume you are not referring to the asian? fonts within the GFX_Library_for_Arduino\src\font folder?

Thanks

[moononournation]

is it ok if running HelloWorldGfxfont example?

[PeteB27]

HelloWorldGfxfont built with minor changes to accomodate the NT35510 16 bit addressing.

What I'm not seeing is "Hello World!" in any string form; the characters are (again) scattered all over the place.

[moononournation]

If HelloWorldGfxfont not work, then it should not related to font files. Wild guess the 16-bit parallel pins have some connection issue. Double check each connection by a multimeter.

[PeteB27]

HelloWorldGfxfont works fine when using v1.4.5 library, all nice text and well behaved.
I also tried with v1.4.6 but same bad output as v1.4.7.
Also, a 2nd (new hardware) NT35510+MEGA combination also misbehaves on v1.4.7 so I don't think it's a parallel data line issue.
I'll try and do a code diff between 1.4.5 and 1.4.6 and see if I can spot the issue or NT35510 compatibility.
I see a passed boolean "clip" was added but it appears clip is always set true so code behaviour should be the same as 1.4.5 in this area.
At worst, I'll just stay on v1.4.5 for now; it works nicely for me.
Thanks for your help, cheers

[moononournation]

I don't know why AVR MCU have this issue, you may try the master work around.

[PeteB27]

I seem to have success (with HelloWorldGfxfont project) with v1.4.6.
I did a files compare between v1.4.5 and v1.4.6 (since I found the v1.4.6 was where the issue first appeared).
In Arduino_GFX.cpp, there are two main things; the removal of (uint8_t) in several key areas
DrawGraycaleBitmap and (more relevant), drawChar() and write(). write() also has a mix of uint8_t and uint16_t types that look as if they have been flipped around since v1.4.5.
I see pgm_read_byte() has been replaced by pgm_read_word() in some places within write()

But, I think I've possibly found the epicentre of the issue, issue within Arduino_GFX.cpp ;
code lines 2015,2016 in drawChar():
int8_t xo = pgm_read_sbyte(&glyph->xOffset),
yo = pgm_read_sbyte(&glyph->yOffset);
changing these two lines to use pgm_read_byte instead of pgm_read_sbyte produces a better outcome for text output but the display area 800x400 isn't being fully utilized, seems to stop about 400x400 pixel screen area.

So, also in write()
Lines 2268-2269, 2275 needed attention. With these changes, I now see the full 800x400 pixels of the NT35510 are being used.

The two attachments show the code changes for success with NT35510 + Arduino MEGA.
LHS view is the modified v1.4.6 code, RHS is the release v1.4.6 code.

Note: I chose v1.4.6 and not v1.4.7 as I found the issue first appeared with the v1.4.6 code release.
My next task is to see if I can replicate these changes on v1.4.7. Please let me know if this 1.4.7 trial is of interest.

[PeteB27]

Hi moononournation, I've had good results for the past week using a further refined Arduino_GFX.cpp that conditionally also handles AVR (or at least, the MEGA board) while honouring the ATTINY changes (and should also honour the v1.4.6/v1.4.7 changes) .
If you're interested, I can post here my final suggestion.
Cheers, PeteB27