prenticedavid / MCUFRIEND_kbv

MCUFRIEND_kbv Library for Uno 2.4, 2.8, 3.5, 3.6, 3.95 inch mcufriend Shields
Other
357 stars 177 forks source link

Weird bahavior using SAMD51 based Arduino boards #151

Closed coyt closed 3 years ago

coyt commented 4 years ago

I have some old eBay 3.5" TFTs that I believe are HX8357-D controller based from the output of LCD_ID_readreg


reg(0x0000) C0 C0 ID: ILI9320, ILI9325, ILI9335, ... reg(0x0004) 00 00 80 00 Manufacturer ID reg(0x0009) 00 00 61 00 00 Status Register


They respond with "ID=0x99" when I run "diagnose_TFT_support.ino"

Now, without even thinking about it, I started trying to test these displays attached to an Adafruit Grand Central M4 Express which uses the SAMD51 chip - with all code default in "diagnose_TFT_support.ino". The displays worked but have weird drawing imperfections / artifacts (random lines and dots) - text is being displayed - but the colors are completely off.

I played with the settings thinking the controller chip might be wrong or something for a while, but I couldn't get correct behavior no matter what I tried. Then I decided to try an actual Arduino Zero board - the default "diagnose_TFT_support.ino" worked perfectly with correct colors and proper display operation.

Looks like there's some issue with the use of the SAMD51 device - maybe in the register magic per device type I'm seeing in mcufriend_special.h?

Any chance this could be looked at?

prenticedavid commented 4 years ago

You do not need a SPECIAL.

From mcufriend_shield.h

//####################################### GRAND CENTRAL M4 ############################
#elif defined(__SAMD51P20A__)      //regular UNO shield on GRAND CENTRAL M4
//LCD pins   |D7  |D6  |D5  |D4  |D3  |D2  |D1 |D0  | |RD |WR |RS |CS |RST|
//SAMD51 pin |PD21|PD20|PC21|PC20|PC19|PC18|PB2|PB18| |PA2|PA5|PB3|PC0|PC1|
#define WRITE_DELAY { WR_ACTIVE4; }
#define IDLE_DELAY  { WR_IDLE2; }
#define READ_DELAY  { RD_ACTIVE8;}

Increase the delay macros e.g. 8, 4, 16 See if that solves the problem. Then reduce delays until you get glitches.

I would expect the HX8357-D to work fast. If you have any older controllers like SPFD5408 or ILI9325 it would be good to see their behaviour.

David.

coyt commented 4 years ago

David,

Thanks for the quick response! I just tried to double each delay - much better result! My display is now drawing colors properly, however there are still some weird artifacts being drawn - only on certain colors - BLUE and GREEN for example. See pics below:

signal-2020-08-02-100555_002 signal-2020-08-02-100555_001

I also tried reducing the delays - as you probably expect - the display stopped working completely. The issue definitely seems to be related to these timing values.

It doesn't look like the macros are defined for any values beyond 8,4,16 so I can't increase them further. Anything else I should try to get rid of the weird artifacts?

I have one other 2.8tft I can try later on the Grand Central - I think it has a completely different controller chip which I can't recall at the moment.

Thanks! - Coyt

prenticedavid commented 4 years ago

I don't see anything much from the photo colours. Black ID text, white lines, white colour text, blue background. But the ID text looks a bit blue. The White looks a bit blue.

We can probably improve the colour gradations with a different GAMMA.

Yes, you can alter the delays e.g. = 4+2+4+1 = 11 `

define WRITE_DELAY { WR_ACTIVE4; WR_ACTIVE2; WR_ACTIVE4; WR_ACTIVE; }

`

I don't have a Grand Central but it should be something like 8, 3, 16 I don't have a 0x99 HX8357 but I do have the 0x9090 HX8357.

I suggest that you experiment with the delays. You will see write glitches in the Adafruit Tests. Read glitches in SOFTWARE SCROLL.

Then observe the colour grades in the Penguin Screens. enable SUPPORT_8357D_GAMMA in MCUFRIEND_kbv.cpp

David.

coyt commented 4 years ago

Ok I'll play around a bit more with those settings.

The main issue I'm referring to is the "little specs" on the screen. For example, in my picture with the Green background, there are a bunch of random pixels that are a completely different color green - sorta like something is getting corrupt when being written to.

In the picture of the blue background - you can see a line down the middle that is random as well as some random off-blue streaking near the bottom.

Those are not artifacts of my camera - they are actually more noticeable in person.

prenticedavid commented 4 years ago

Ah-ha. The random specks are bad.

Since the Shield mates with the Grand Central headers I would expect reliable signals.

What kind of glitches do you see in the Adafruit Tests in graphictest_kbv.ino ? You might need to add a bigger delay to runtests()

David.