Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AdafruitGFX fillscreen(), drawFastVLine(), drawFastHLine() working only partially (ESP32) #2711

Closed
profjmer opened this issue Jan 14, 2024 · 6 comments · Fixed by #2712
Closed
Labels

Comments

@profjmer
Copy link

Sample: ScreenTFT_ILI9340-ILI9341
In that sample, fillscreen only works with color 0, all other colors draw only a very short line of the color chosen.
This issue happens also with functions drawFastVLine(...) drawFastHLine(...)
Drawing rectangles is also affected.
Is it my setup ? Any body able to reproduce this behavior ?

@mikee47
Copy link
Contributor

mikee47 commented Jan 14, 2024

I've checked fillScreen(ILI9341_PURPLE) on my rp2040 board and no problems. Is your circuit connected using jumpers? If so, try reducing the clock speed (e.g. tft.begin(8000000);) see if that makes a difference. From experience, this is often the cause of display issues. Soldered connections are best.

@profjmer
Copy link
Author

I have a pcb with the TFT board plugged on headers.
I can load a bmp full screen of red dotss (220x340) then clear it with a fillscreen(0) and it will clear the screen, any other color will also clear the screen (all black) and then add a little line of the color chosen at the beginning of the screen.
I have an application that worked on a esp8266 that i try to port to esp32. I can not use the old Adafruit_GFX lib and the new one has this problem.
I tried with a very low freq 1M, without success.
Is there another TFT library in SMING that can be used for ILI9341/ILI9488 ?

@mikee47
Copy link
Contributor

mikee47 commented Jan 15, 2024

Are you using the ILI9488? If so, please note that it only supports 18-bit (3-byte) colours whereas the ILI9341 uses 16-bit (2-byte). This may explain the colour problems.

If you want to try another library, see https://sming.readthedocs.io/en/latest/_inc/Sming/Libraries/Graphics/index.html. I use this with an ILI9341 2.8" display, but it has a pretty good feature set and you can test/develop directly on Host without any hardware. I haven't tried it on the ILI9488 but should only need a few tweaks to get that working. (See feature/ili9488 branch.)

@profjmer
Copy link
Author

I am using ILI9341 and here is a picture of the latest test that I have done.
drawLine

fillscreen, drawFastLine use drawline and drawline can't draw straight lines (horizontal or vertical)

Four lines have been drawn, two vertical and two horizontal.
Only the lines that do not have the same x or same y coordinate are normally drawn.
Those you have the same coordinate x or y draw only a partial line.
I did not dig further but i guess that there is something wrong with this function.

@profjmer
Copy link
Author

Here is the code for the lines
tft.drawLine(100,0,101,320,ILI9341_RED);
tft.drawLine(90,0,90,320,ILI9341_YELLOW);

	tft.drawLine(0,100,240,101,ILI9341_GREEN);
	tft.drawLine(0,120,240,120,ILI9341_BLUE);

@mikee47
Copy link
Contributor

mikee47 commented Jan 15, 2024

Hooked up an ESP32 and can confirm your results! Easy fix by amending the Adafruit_SPITFT::writeColor method. Delete lines 1037-1177 inclusive. Then run make Adafruit_GFX-build.

@mikee47 mikee47 added the Bug label Jan 15, 2024
@mikee47 mikee47 changed the title AdafruitGFX fillscreen(...) drawFastVLine drawFastHLine() working only partially AdafruitGFX fillscreen(...) drawFastVLine drawFastHLine() working only partially (ESP32) Jan 15, 2024
@mikee47 mikee47 changed the title AdafruitGFX fillscreen(...) drawFastVLine drawFastHLine() working only partially (ESP32) AdafruitGFX fillscreen(), drawFastVLine(), drawFastHLine() working only partially (ESP32) Jan 15, 2024
slaff pushed a commit that referenced this issue Jan 16, 2024
Fixes #2711

The problem occurs with a code path for ESP32 which buffers up to 32 pixels at a time for transfer. However, the first call to 'writePixels' clears the buffer to black (0 - empty response data). If the fill colour is black no abnormal operation is observed, but any other colour and at most 32 pixels get filled with the requested colour.

The benefit of these optimisations is minimal so the library is patched to simplify code path for all architectures.
slaff pushed a commit that referenced this issue Jan 19, 2024
Fixes #2711

The problem occurs with a code path for ESP32 which buffers up to 32 pixels at a time for transfer. However, the first call to 'writePixels' clears the buffer to black (0 - empty response data). If the fill colour is black no abnormal operation is observed, but any other colour and at most 32 pixels get filled with the requested colour.

The benefit of these optimisations is minimal so the library is patched to simplify code path for all architectures.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants