Is a screen fill the only way to clear the screen with the MCUFriend TFT library?
It seems a slow way to clear the screen?
If I want to continually update some text on the screen, do I have to draw a black rectangle over it, each time before re-writing in order to clear the previous display text?
The adafruit OLED library has a clearDisplay function which clears the screen buffer. I know it has less pixels to do on a 128x64 but it seems a much quicker way to clear old data?
Most controllers are unintelligent. e.g. ILI9341 or SSD1306
You have to write a specific colour to each pixel.
RA8875 is intelligent. You can give a high-level graphics command and the hardware does it for you.
tft.fillScreen(TFT_BLACK);
is pretty quick.
Unless you choose to run a Uno parallel shield on a Mega, I am surprised that you can even observe the screen being cleared.
Yes, it is always wise to think first. Only update text or graphics when they actually change.
Yes, FreeFonts are always transparent. Calculate the necessary rectangle. Draw the background. Write the text.
The "system 5x7" font can be drawn in "rubout" mode i.e. text + background. Call tft.setTextColor(foreground_colour, background_colour);
It defaults to "transparent" mode when you use tft.setTextColor(foreground_colour);
David.
david_prentice:
Most controllers are unintelligent. e.g. ILI9341 or SSD1306
You have to write a specific colour to each pixel.
RA8875 is intelligent. You can give a high-level graphics command and the hardware does it for you.
tft.fillScreen(TFT_BLACK);
is pretty quick.
Unless you choose to run a Uno parallel shield on a Mega, I am surprised that you can even observe the screen being cleared.
Yes, it is always wise to think first. Only update text or graphics when they actually change.
Yes, FreeFonts are always transparent. Calculate the necessary rectangle. Draw the background. Write the text.
The "system 5x7" font can be drawn in "rubout" mode i.e. text + background. Call tft.setTextColor(foreground_colour, background_colour);
It defaults to "transparent" mode when you use tft.setTextColor(foreground_colour);
David.
Thanks David.
Can you explain "Unless you choose to run a Uno parallel shield on a Mega" ?
I am using a Mega2650. The shield is a clone of some sort, but I assume it is using a parallel interface.
Is there some speed disadvantage to this?
OK, just found a post on here about the port pin allocation and pinout being for UNO's and not Megas.
I have yet to find a TFT board specifically laid out for a Mega, so will look at re-wiring.
Post a link to the actual screen that you have bought. e.g. Ebay sale
Or post a photo of the pcb
David.
From your photo:
The Red pcb does not have a LDO regulator. ID = 0x9325
The Orange pcb does have a LDO regulator. ID = 0x0000
Please can you run the diagnose_TFT_controller sketch and the LCD_ID_readreg sketch.
Copy-paste from Serial Terminal to your message (in a CODE window).
I am sure that we can get one if not both screens working.
Yes, the shields fit on a Mega. They run the library code. They will be SLOWER than a Uno. But at least they should work.
David.
david_prentice:
From your photo:
The Red pcb does not have a LDO regulator. ID = 0x9325
The Orange pcb does have a LDO regulator. ID = 0x0000
Please can you run the diagnose_TFT_controller sketch and the LCD_ID_readreg sketch.
Copy-paste from Serial Terminal to your message (in a CODE window).
I am sure that we can get one if not both screens working.
Yes, the shields fit on a Mega. They run the library code. They will be SLOWER than a Uno. But at least they should work.
David.
Hi David, sorry if I mislead you, but both screens work fine, just a bit slow... which I have now discovered, is due to the Mega port assignment where many if the pins are spread over serveral ports...
You should not get ID = 0x0000.
If you have an SPFD5408 controller the ID = 0x5408
If you want it to go faster on a Mega, make an adapter from a Protoshield. Route the data bus to PORTA (digital 22-29 on the DIGITAL header)
It is cheaper and easier to just buy a Display that is a Mega-style shield.
However most of these are write-only. You have to guess the controller and you can not read the GRAM memory.
David.
Hi David,
Once I rewire, what do I need to change to make the library use Port A for the data pins on a Mega?
Cheers,
Richard.
From mcufriend_how_to.txt:
17. If you do not have a standard Uno Shield, you can add a SPECIAL to the mcufriend_special.h
Edit mcufriend_shield.h: #define USE_SPECIAL
Edit mcufriend_special.h: e.g. #define USE_MEGA_16BIT_SHIELD
If your "special" is write-only, the library can not read the ID. It always returns 0xD3D3
In your case it would be USE_MEGA_8BIT_PROTOSHIELD
Since you are using the regular control pins (A0 .. A4) your hardware mod will still be able to read the ID.
David.
richardtheboffin:
Hi David,
Once I rewire, what do I need to change to make the library use Port A for the data pins on a Mega?
Cheers,
Richard.
I am guessing at include mcufriend_special.h an uncomment USE_MEGA_8BIT_PROTOSHIELD
Thanks David, you beat me to it! 
OK, not getting any joy with rewired shield...
I have wired D0-D7 to PA0-PA7 (22 to 29) noting that the pins on the shield are labelled from top right:
J2:
D2
D3
D4
D5
D6
D7
J1:
D0
D1
I have uncommented #define USE_SPECIAL in utilitiy\mcufriend_shield.h
and uncommented #define USE_MEGA_8BIT_PROTOSHIELD in utility\mcufriend_special.h
Do I need to move these into the main mcufriend_kbv folder or add includes for them in the main sketch?
Does anythnig in mcufriend_kbv.h need changing?
Anything I am missing?
And LCD_ID_readreg reports this:
Read Registers on MCUFRIEND UNO shield
controllers either read as single 16-bit
e.g. the ID is at readReg(0)
or as a sequence of 8-bit values
in special locations (first is dummy)
reg(0x0000) 93 05 ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 00 00 Manufacturer ID
reg(0x0009) 00 00 00 00 00 Status Register
reg(0x000A) 00 00 Get Power Mode
reg(0x000C) 00 00 Get Pixel Format
reg(0x0061) 20 20 RDID1 HX8347-G
reg(0x0062) 20 20 RDID2 HX8347-G
reg(0x0063) 20 20 RDID3 HX8347-G
reg(0x0064) 20 20 RDID1 HX8347-A
reg(0x0065) 20 20 RDID2 HX8347-A
reg(0x0066) 20 20 RDID3 HX8347-A
reg(0x0067) 20 20 RDID Himax HX8347-A
reg(0x0070) 20 20 Panel Himax HX8347-A
reg(0x00A1) 20 20 20 20 20 RD_DDB SSD1963
reg(0x00B0) 20 20 RGB Interface Signal Control
reg(0x00B4) 20 20 Inversion Control
reg(0x00B6) 20 20 20 20 20 Display Control
reg(0x00B7) 2C 20 Entry Mode Set
reg(0x00BF) 20 20 20 20 20 20 ILI9481, HX8357-B
reg(0x00C0) 00 00 00 00 00 00 00 00 00 Panel Control
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA
reg(0x00CC) 00 00 Panel Control
reg(0x00D0) 00 00 00 Power Control
reg(0x00D2) 00 00 00 00 00 NVM Read
reg(0x00D3) 00 00 00 00 ILI9341, ILI9488
reg(0x00D4) 00 00 00 00 Novatek ID
reg(0x00DA) 00 00 RDID1
reg(0x00DB) 00 00 RDID2
reg(0x00DC) 00 00 RDID3
reg(0x00E0) 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 GAMMA-P
reg(0x00E1) 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 GAMMA-N
reg(0x00EF) 20 20 20 20 20 20 ILI9327
reg(0x00F2) 20 20 20 20 20 20 20 20 20 20 20 20 Adjust Control 2
reg(0x00F6) 20 20 20 20 Interface Control
With these pin settings:
#define LCD_RST A4
#define LCD_CS A3
#define LCD_RS A2
#define LCD_WR A1
#define LCD_RD A0
#define LCD_D0 22 //8
#define LCD_D1 23 //9
#define LCD_D2 24 //2
#define LCD_D3 25 //3
#define LCD_D4 26 //4
#define LCD_D5 27 //5
#define LCD_D6 28 //6
#define LCD_D7 29 //7
Found a dry joint...
So now the correct ID:
Read Registers on MCUFRIEND UNO shield
controllers either read as single 16-bit
e.g. the ID is at readReg(0)
or as a sequence of 8-bit values
in special locations (first is dummy)
reg(0x0000) 93 25 ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 00 00 Manufacturer ID
reg(0x0009) 00 00 00 00 00 Status Register
reg(0x000A) 00 00 Get Power Mode
reg(0x000C) 00 00 Get Pixel Format
reg(0x0061) 00 00 RDID1 HX8347-G
reg(0x0062) 00 00 RDID2 HX8347-G
reg(0x0063) 00 00 RDID3 HX8347-G
reg(0x0064) 00 00 RDID1 HX8347-A
reg(0x0065) 00 00 RDID2 HX8347-A
reg(0x0066) 00 00 RDID3 HX8347-A
reg(0x0067) 00 00 RDID Himax HX8347-A
reg(0x0070) 00 00 Panel Himax HX8347-A
reg(0x00A1) 00 00 00 00 00 RD_DDB SSD1963
reg(0x00B0) 00 00 RGB Interface Signal Control
reg(0x00B4) 00 00 Inversion Control
reg(0x00B6) 00 00 00 00 00 Display Control
reg(0x00B7) 00 00 Entry Mode Set
reg(0x00BF) 00 00 00 00 00 00 ILI9481, HX8357-B
reg(0x00C0) 00 00 00 00 00 00 00 00 00 Panel Control
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA
reg(0x00CC) 00 00 Panel Control
reg(0x00D0) 00 00 00 Power Control
reg(0x00D2) 00 00 00 00 00 NVM Read
reg(0x00D3) 00 00 00 00 ILI9341, ILI9488
reg(0x00D4) 00 00 00 00 Novatek ID
reg(0x00DA) 00 00 RDID1
reg(0x00DB) 00 00 RDID2
reg(0x00DC) 00 00 RDID3
reg(0x00E0) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-P
reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 GAMMA-N
reg(0x00EF) 00 00 00 00 00 00 ILI9327
reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2
reg(0x00F6) 00 00 00 00 Interface Control
Yes, that fixed it!
Just for info:
fillscreen(); has gone from 339ms down to 69ms, so a very good improvement. Still not lightening fast, but a lot better.
Thanks again David!
Your wiring and defines look correct.
I would expect to see:
reg(0x0000) 93 25 ID: ILI9320, ILI9325, ILI9335, ...
I would be suspicious of LCD_D5 since you got 05 instead of 25.
However you have got lots of 20s in "empty" registers when I would expect 00
I can only suggest that you check the quality of your soldering.
Ah-ha. You had found the problem while I was typing !!
David.
Yes, anoying dry joint was holding together but not conducting. A good wiggle test broke it free.
To reduce the screen update time and reduce the flicker, I'll try only upating characters that have changed.
I guess it would be possible to bit test each character and only redraw changed pixels too, if I wrote a new font printing function.