Closed poky closed 2 years ago
See #774
I have ordered one of those displays but it will probably be a few weeks before it arrives. Maybe then I can figure out what is wrong. Until then I will not list the display as supported in the Readme.
The changes I made based on@freemanzwin here suggestions have not been tested unfortunately and @freemanzwin has not responded to the issue yet or the request for testing.
Still waiting for my display to arrive...
Still waiting for my display to arrive...
I have one arriving tomorrow. Will see what happens.
Stiil waiting for mine to arrive from China, suspect it may be lost in the post :-(
Package tracking indicates it arrived in the UK 8 days ago, so there is hope!
Could it be that the GC9A01 does not support reading from the screen? tft.readPixel seems to return 0 in any case.
Mine has arrived and I have got it working up to a point. The Orrery example leaves a trail of pixels so this indicates some issues writing to the screen. The same sketch works fine on other displays so this is something to do with the GC9A01 behaviour, it looks like it misses every other pixel line. I will need to study the data sheet and investigate further. Some things seem to work OK, others have corrupted graphics. It will be a while before I can investigate.
I have not been able to read from the screen, this is probably due to the IM(x) configuration pins being in a mode that does not allow SDA bidirectional reads. This is just a guess and I see no way of over-riding this to permit screen CGRAM reads.
Mine has arrived and I have got it working up to a point. The Orrery example leaves a trail of pixels so this indicates some issues writing to the screen. The same sketch works fine on other displays so this is something to do with the GC9A01 behaviour, it looks like it misses every other pixel line. I will need to study the data sheet and investigate further. Some things seem to work OK, others have corrupted graphics. It will be a while before I can investigate.
I have not been able to read from the screen, this is probably due to the IM(x) configuration pins being in a mode that does not allow SDA bidirectional reads. This is just a guess and I see no way of over-riding this to permit screen CGRAM reads.
Cool! Look forward to what else you find. Another thing I've spotted is that transparent sprites also seem to behave weirdly. I've also seen those display alternating lines and other weird glitches. I've yet to try an example with transparency, but it didn't seem like I was doing much different from those.
Edit: ah it seems the orrery example also uses transparent sprites so that might be the same issue.
This Chinese LCD module does not have MISO pin. So I don't think I can read CGRAM.
Some displays operate in bidirectional mode, where the MOSI line changes from input to output at the display during a read, typically the pin is then called SDA. The library supports this type of interface for ESP32 only, however I have tried this mode on the GC9A01 and it does not return sensible data. The GC9A01 can operate in bidirectional mode but this is controlled by hardware set pins that, as far as I can see, are not accessible on these displays.
Has any progress been made on this? I tried the animated dial example and the needle overwrites the background image.
drawXBitmap example now works with GC9A01.
Hi Bodmer, To open this for a similar question, I am using matouch_esp32_s3_round which used ESP32S3+GC9A01, that can't show drawXBitmap example. and also do you have a solution for it to show JPG? Thanks. Summer
Hi, thanks for the great library & driver! I have some issues running the drawXBitmap example, it only shows the blue lines jumping in different locations, was wondering how to debug, any thoughts will be appreciated!
_Originally posted by @poky in https://github.com/Bodmer/TFT_eSPI/issues/774#issuecomment-747488090_