Go Down

Topic: TFT ILI9806 on ESP32 don't work (Read 746 times) previous topic - next topic

david_prentice

Yes,  if the arithmetic does not work,  the scroll does not happen  e.g. TOP+BAND+BOT must equal the GateScan.

It is not uncommon for controllers to go wrong in REV.    They sometimes need a kludge.    To get the GateScan to line up properly AND to keep the scroll arithmetic happy.

The important thing is that you KNOW it is physically 480x854.
People seldom use the REV rotations.    So it does not matter if there is a kludge.

reg(0xF7) = 0x80 gives a clear display.
I will kludge vertScroll() and setAddrWindow() arithmetic to cope with black bands.

It is my bedtime.

David.

Edit.  Crazy behaviour is probably because readID() got a different ID.   i.e. tft.begin(wrong_ID)
Please stick with a known PIN_LOW().   I want to get this working properly first.   Before we worry about performance.

indio99

Good night, and very thank you  :)
CodeTronic

david_prentice

I have updated the Branch on GitHub.

indio99

Hi.

Until now, I was not able to see testline(), and others as triangles or circles because it's crashed.

Now I can see the whole test with out fails.

I'm away from home, but tonight I'll try to make a report with the changes made.

Thank you very much
CodeTronic

david_prentice

I am doing something else at the moment.

Your 480x854 is 2.67x the pixels of my 320x480 displays.   I will try to get an ESP32  to crash by trebling the size of those Adafruit Tests.

The ESP8266 is a pain with WatchDog.   I have always found ESP32 kinder.

David.

indio99

CodeTronic

david_prentice

I am more confused.  
1. The Adafruit Tests appear to work.
2. The Adafruit Report is normally Green text on Black background with visible text messages.
3. Your Total is 11.22 sec.    My ESP32 takes 3.55 sec on a 320x480.  So I would expect you to take 9.48 sec.
4. Your Vertical Scroll is very fast.    Software Scroll is the same as mine.
5. The Red penguin screen looks as if it has a "missing" 96 pixels on the bottom of the screen (right on video)
6. Your previous Red screen looks like 64 pixels missing.
7. since the Band scroll is working,  my vertScroll() arithmetic kludge works.
8. the OFFSET definitely does not work.

If you make changes to the graphictest_kbv example,  please say so.   I am guessing that you have reduced the delays to make a shorter video.   An excellent strategy but it would be nice to be told.

I have updated the GitHub Branch.   Adjust the OFFSET_9806 to see what works.   Personally I would expect the value to be 10 i.e. to account for 854 vs 864 scanlines.
I have set it to 96 because of what the video looks like.   

David.

indio99

Oh, excuse me, have you right, I modidfied the delays, and other things, but the changes are not important, I think.

The total time of test can be affected by the pinLow and pinHigh, I'm in digitalWrite(), because with your change don't work for me. The screen don't start.

#define PIN_LOW(p, b)        (*(&p+2)) = (1<<(b&31))
#define PIN_HIGH(p, b)        (*(&p+1)) = (1<<(b&31))
CodeTronic

david_prentice

No problem.    It is often wise to reduce delays for a video.   I can stop and start a video.   In fact I tend to just view stopped frames when I want to study something.

I was amazed that that "p" macro worked at all without a lot of casts.   It does not surprise me that you had a problem.   The Expressif toolchain is very fussy about certain things.    
Yes,  it is safer to stick with digitalWrite() for the PIN_LOW() macro.    The ESP32 compiler does an incredible job in generating efficient code.

The most important task is to get the screen rendering correctly in XXX_REV rotations.
I presume that the Adafruit Report screen "oddity" is due to your edit.

David.

Go Up