This is a link to a 3.95" TFT LCD from Ali Express. I am having heaps of trouble with Ali Express so take care.... The 3.95" is NOT available from eBay 
The link works even though it says "3-5-inch"
Hi David,
I have the red PCB 2.4" touchscreen TFT with mcufriend written on it and I'm using an Arduino UNO with your library. I have used your library with other versions of this TFT no problem but I got some new ones today which give exactly the same results as user ylph was getting in post #305 and #307. I too tried your suggestions from post #311 and did not see any change.
I was just wondering if you had any ideas since?
Also the bags my modules came in have two numbers on them ZC13500 which I think is just the part number of the screen and 20630218 which I assume is just a reference number the seller uses. I'm just telling you in case they are useful but I'd guess they are no help.
Ylph has mailed me a shield. I am expecting it to arrive tomorrow or Wednesday. ( if California to England works ok)
No, I have no ideas at the moment but at least it will be a lot easier with the real thing on my desk.
I am gobsmacked by the sheer range of 2.4" controllers. I am convinced that this is due to different panels becoming surplus in China. They just use whatever is available and it appears on Ebay.
I would be a lot happier if they used 74VHC245 chips and not 74HC245. But hey-ho, the shields work and they are certainly cheap!!
The 2.4" shields seem to survive China Post better than the bigger 3.5 or 3.95 panels. Cracked Touch Panels will never work.
David.
That's great, hopefully it gets there okay. If not I have a few and I could send one over from Ireland which should get there okay.
I actually just took apart a cracked one which didn't survive the journey here to see if there was any identifying numbers behind the screen. Again doubt these numbers are useful but printed on the shielding behind the screen there is XYL824572-2201Yl, TX02400304-00 and also a date 2013/09/25. I actually taught they'd have been much older than that. Also on the pcb beneath the screen was 02323E_P139-14.
I'll keep an eye on the thread to see if you have any progress, fingers crossed you can crack it. Thanks for all the work you've done already by the way, your library has already been a great help to me with other screens in the past.
Hi David
I'm glad to say I eventually changed my slideshow to use
#include <Adafruit_GFX.h>
#include <MCUFRIEND_kbv.h>
MCUFRIEND_kbv tft;
The sketch was using Bodmer's libraries on my BangGood 3.2" screens.
It was the most difficult library replacement I have done. The sketch has used about 6 different libraries in its' travells.... 
I kept getting errors I couldn't explain. Eventually I got some "printing" to work.
The final stumbling block was realising that most of my problems were Hard & Soft SPI!!!!!!!!!!!!!
Once I changed MOSI, MISO, CLK & CS in SdFat everything fell in place.
I still can't display JPG pictures as there are 3 "pushColors" and one STILL gets rejected by the compiler as "ambiguous"
tft.pushColors(pImg[2] >> 3 | (pImg[1] & 0xFC) << 3 | (pImg[0] & 0xF8) << 8, 1, 0);
I will slowly work it out 
C++ newbie
I will now attempt the change/replacement in my main sketch 
I thought I would try to point out the problem for anyone else who is going from a BangGood 3.2" ILI9481 display to and Ali Express 3.95" ILI9488
Apparently I have the same display as Ylph. The resisters match perfectly. All of the graphics test programs that I have run, run perfectly except for the two landscape screens on a portrait display. The paint program uses the whole screen properly, but displays on the smaller parts. I also tried the changes to MCu***.cpp with no effect. I will continue to watch this thread.
I originally bought the UNO to set up a system to photograph water drops, which works much better than I expected.
I wonder if I can get some help here?
I want to copy 2 rectangles off a displayed screen.... They are the background behind the MM (minutes) and the SS (seconds) digits of a digital clock display.
I want to use "transparent" printing so I have to handle my own repainting of the background. I assume I can copy from GRAM to SRAM with the readGRAM method and put it back with the pushColors after a setAddrWindow. So that is what I coded but the display remains BLACK after the pushColors????
I extracted the skeleton of my sketch from "readpixel_kbv" then paint random pixels in a rectangular format then "copy" readGRAM then clear the screen then setAddrWindow then pushColors but the screen remains blank after the clearScreen.
Have I misunderstood readGRAM or pushColors or setAddrWindow?
Thanks in anticipation
Here is my full "TEST" sketch....
/* Skeleton from readpixel_kbv */
#include <Adafruit_GFX.h>
#include <MCUFRIEND_kbv.h>
MCUFRIEND_kbv tft;
unsigned short minutes[12800];//different definitions
uint16_t seconds[12800]; //in case it mattered?
uint16_t g_identifier;
void setup(void) {
tft.reset();
g_identifier = tft.readID();
tft.begin(g_identifier);
tft.setRotation(1);
tft.fillScreen(0x0000);
}
void loop() {
int cy = 479;
for(int z = 0; z < 160; z++) {
for(int c = 0; c < cy; c++) {
tft.drawPixel(z + c, z, random(0xFFFF)); //Top LHS
if (c < (cy - 160)) tft.drawPixel(479 - z, z + c, random(0xFFFF)); //Top RHS
tft.drawPixel(479 - z - c, 319 - z, random(0xFFFF)); //Bottom RHS
if (c < (cy - 160)) tft.drawPixel(z, 319 - z - c, random(0xFFFF)); //Bottom RHS
}
cy -= 2;
}
delay(500);
tft.readGRAM(176, 130, minutes, 128, 100);//copy rectangle behind "minutes"
tft.readGRAM(340, 130, seconds, 128, 100);//copy rectangle behind "seconds"
tft.fillScreen(0x0000);
tft.setAddrWindow(176, 130, 128, 100);
tft.pushColors(minutes, 12800, 0);//copy minutes rectangle back?
tft.setAddrWindow(340, 130, 128, 100);
tft.pushColors(seconds, 12800, 0); delay(2000);//copy seconds rectangle back?
}
I tried ",0" & ",1" as the 3rd argument
The Adafruit pushColors() method uses 3 arguments. The last argument signifies that it is the first call.
Normally you would be filling up a rectangle in several stages. e.g. when reading blocks from an SD card.
Look at the software scroll example in the demo sketch.
You seem to be very profligate with memory. You cannot afford a 25kB SRAM buffer on a MEGA2560. It is tight on a Zero. I know that you have a Due, but not everyone is so lucky.
David.
Thanks for your reply
I could be wrong (newbie!) but there are three pushColors in "MCUFRIEND_kbv.cpp" and one in "Adafruit_TFTLCD.cpp" and none in "Adafruit_GFX.cpp" so which one is being "called"?
Did you mean example "scroll_kbv", no pushColors?
But I tried first = 0 and first =1 neither painted anything What's "up"?
I HAVE looked at pushColors in "graphictest_kbv" (is that the one you mean?) but no shoes dropped?
It is actually 51Kb, 25,600 shorts/unit16_t. I wanted to use PROGMEM till I found out I can't write to PROGMEM
BTW I also store the backgrounds under the semi colons too But they are 128 bytes each so negligible....
I tried * and & but they didn't compile.... I told you! NEWBIE!
The sketch I posted should run if you have and AliX (MCU 9488) screen and a Due.
Put me out of my misery. Please tell me what I'm doing wrong?
I had one Mega, ordered 5 more, 4 arrived, one got refunded
I have 3 Dues and I'm ready to order 6 more if I could find the R3-E variant.... because I think the background is so important to me For the 6 clocks I HOPE to make....
Sorry Louis, I should really document the methods formally.
Here is your sketch as you intended:
/* Skeleton from readpixel_kbv */
#include <Adafruit_GFX.h>
#include <MCUFRIEND_kbv.h>
MCUFRIEND_kbv tft;
unsigned short minutes[12800];//different definitions
uint16_t seconds[12800]; //in case it mattered?
uint16_t g_identifier;
void setup(void)
{
tft.reset();
g_identifier = tft.readID();
tft.begin(g_identifier);
tft.setRotation(1);
tft.fillScreen(0x0000);
}
void loop() {
int cy = 479;
for (int z = 0; z < 160; z++) {
for (int c = 0; c < cy; c++) {
tft.drawPixel(z + c, z, random(0xFFFF)); //Top LHS
if (c < (cy - 160))
tft.drawPixel(479 - z, z + c, random(0xFFFF)); //Top RHS
tft.drawPixel(479 - z - c, 319 - z, random(0xFFFF)); //Bottom RHS
if (c < (cy - 160))
tft.drawPixel(z, 319 - z - c, random(0xFFFF)); //Bottom RHS
}
cy -= 2;
}
delay(500);
tft.readGRAM(176, 130, minutes, 128, 100);//copy rectangle behind "minutes"
tft.readGRAM(340, 130, seconds, 128, 100);//copy rectangle behind "seconds"
tft.fillScreen(0x0000);
tft.setAddrWindow(176, 130, 176 + 128, 130 + 100);
tft.pushColors(minutes, 12800, 1);//copy minutes rectangle back?
tft.setAddrWindow(340, 130, 340 + 128, 130 + 100);
tft.pushColors(seconds, 12800, 1);
delay(2000);//copy seconds rectangle back?
}
Note that the H file gives you some pretty good clues. But I should be more explicit
x, y expect coordinates of a pixel location. w, h expect a width and height of a rectangle.
The compiler will use the pushColors(uint16_t *block, ...) variant because you have a block of uint16_t colours in SRAM.
int16_t readGRAM(int16_t x, int16_t y, uint16_t *block, int16_t w, int16_t h);
void setAddrWindow(int16_t x, int16_t y, int16_t x1, int16_t y1);
void pushColors(uint16_t *block, int16_t n, bool first);
I am following the Adafruit conventions. I am sure that you could make a good argument for setAddrWindow() using width and height rather than coordinates. Hey-ho, I am stuck with this syntax.
Personally, I find the Adafruit methods() more intuitive than UTFT methods()
Bodmer's pushColors() works differently. His setWindow() sends the WriteGRAM command. Hence he does not need a "first" argument. I could have followed his style and used a setReadWindow() which sends the readGRAM command. But this would be incompatible with other Adafruit libraries.
Regarding examples. If you want to experiment with reading blocks of memory, put something interesting in them. Then draw them in a different place.
I am guessing that you intend to draw a MandelBrot as a background. Once you have saved the rectangle(s), you simply draw the saved rectangle before drawing the fresh Number on top.
David.
Thanks David....
My fault (newbie) I assumed (x,y,w,h) instead of (x1,y1,x2,y2)
I overwrote my sketch with yours and, of course, it worked
No, the Mandelbrot is just one of the backgrounds.... I mainly intend to use family pictures stored on the micro SD card. Pictures change every half hour or whatever?
I can also do this copying when the picture is actually drawn by modifying the "bmpDraw"? But I would have to do this for "drawSdJpeg" and "rawDraw" routines too and I have to check which logic is faster? readGRAM or "bmpDraw"? Is readGRAM fast? I suppose I can check myself?
Thanks for your help
All I have to do now is get the touch panel working, it'll be the way to control/change alarm etc of the clock. The clock will also be personalized with birthdays and event days etc.... I know, every iPad, iPhone or Android can do this....
After midnight so bed....
Thanks
david_prentice:
10. It currently supports UNO shields with "mcufriend.com" pcbs with controllers:
----- HX8347-A 240x320 ID=0x8347 new Untested
ILI9320 240x320 ID=0x9320
ILI9325 240x320 ID=0x9325
ILI9327 240x400 ID=0x9327
ILI9329 240x320 ID=0x9329
ILI9335 240x320 ID=0x9335
ILI9341 240x320 ID=0x9341
ILI9481 320x480 ID=0x9481
ILI9486 320x480 ID=0x9486
ILI9488 320x480 ID=0x9488
LGDP4535 240x320 ID=0x4535
RM68090 240x320 ID=0x6809
R61505V 240x320 ID=0xB505
R61505W 240x320 ID=0xC505 new Untested
R61509V 240x400 ID=0xB509
----- S6D0139 240x320 ID=0x0139 removed due to lack of tester
S6D0154 240x320 ID=0x0154
SPFD5408 240x320 ID=0x5408
----- SSD1963 800x480 ID=0x1963 new Untested
SSD1289 240x320 ID=0x1289
ST7781 240x320 ID=0x7783
ST7789V 240x320 ID=0x7789
- These Mcufriend-style shields tend to have a resistive TouchScreen on A1, 7, A2, 6 but are not always the same rotation of direction.
Run the TouchScreen_Calibr_kbv.ino sketch to diagnose your model and then scale the result from TouchScreen.h methods()
Question about weird colors:
I have an Mcufriend 3,6" display, 320x480 resolution, and touchscreen works when set to
#define YP A2 // must be an analog pin, use "An" notation!
#define XM A1 // must be an analog pin, use "An" notation!
#define YM 6 // can be a digital pin
#define XP 7 // can be a digital pin
Some background: When using Adafruit's TFTLCD library, the tftpaint2 program only shows white background and yellow pixels for everything, regardless of what color is supposed to be shown.
Also the Y axis (0-480) of the touchscreen is inverted. But the icons marked 1 through 8 show up okay (though yellow). To get around that I just added 'p.y = 480 - p.y;' after the mapping.
When I replaced
Adafruit_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD, LCD_RESET);
with
MCUFRIEND_kbv tft;
the screen looked a bit better, in that it now shows black background and blue foreground.
However all the icons 1 through 8 are inverted, also the touchscreen X and Y axes are both inverted. (So that if I draw towards the lower-left, the drawn pixels move towards the upper-right.)
tftpaint2 (with MCUFRIEND_kbv) says it doesn't recognize the chip, so I force it to init with 0x9481.
graphicstest_kbv, now there's the interesting bit. It recognizes the 9481 chip, but the colors are messed up or missing. See the attached image. Blue seems to work okay, since it wants to draw a lot of blue. But the pictures 'GREEN BARS' and 'RED BARS' are both greenish-blue in the beginning, and then go towards blue. So it's not the photo that's off, the colors on screen are actually all shades of mostly blue.
In the image is also a photo of the display itself, seen from the underside where "mcufriend" and "(9481)" is shown.
In the ebay listing, they said that it was another chip, and in the listing itself some test code was listed, like so:
Tftlcd 3.6-inch touch screen with uno r3
3.6-inch LCD touch screen
Resolution : 480x320
Controller : ili9488
Test code:
ILI9327:
LCD_Write_COM(0xE9);
LCD_Write_DATA(0x20);
LCD_Write_COM(0x11); //Exit Sleep
[...]
(from the item listing 3.5 Inch TFT LCD Display Arduino Touch Screen Module UNO R3 Board Plug and Play for sale online | eBay)
Telling the mcufriend_kbv library to use chip 9488 didn't work at all though. And it's odd that their 'test code' is marked ILI9327. gaaah.
Any input on how come this display is so very happy in showing either yellow-on-white (with Adafruit TFTLCD) or blue-on-black (with mcufriend_kbv)?
Please run the LCD_ID_readreg sketch and paste the Serial output to your message.
David.
Doh! Certainly, here it is:
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) 00 00 ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 00 00 Manufacturer ID
reg(0x0009) 00 00 00 00 00 Status Register
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 02 04 94 81 FF ILI9481, HX8357-B
reg(0x00C0) 00 10 3B 00 02 11 Panel Control
reg(0x00CC) 00 00 Panel Control
reg(0x00D0) 00 00 43 Power Control
reg(0x00D2) 00 01 22 00 00 NVM Read
reg(0x00D3) 00 01 22 00 ILI9341, ILI9488
reg(0x00DA) 00 00 RDID1
reg(0x00DB) 00 00 RDID2
reg(0x00DC) 00 00 RDID3
reg(0x00EF) 00 00 00 00 00 00 ILI9327
reg(0x00F2) 00 00 33 00 00 00 00 00 00 00 00 00 Adjust Control 2
reg(0x00F6) 00 80 80 80 Interface Control
As a quick comment, like so many others have said, great library you've done! It's the only one that lets me use my display usefully.
Footnote: Since I'm only going to use it to draw symbols that can be pushed, working touch and blue-on-black really -is- good enough for me, but, y'know.. it's always neat to have things fully working. And I've only had it a day so far, so I don't know if it'll do like a couple of Sainsmart displays and stop working with white screen after a couple of days - I blame crappy soldering on those. (One also had a broken touch resistor connector, that could be fixed with conductive glue carefully pressed in between the top layers of the screen, using a ceramic knife edge to veeeery carefully opening up enough to get the thin glue-syringe needle in.)
Another picture to attach: This shows the screen -just- after the 'grey' (well, blue) bars have scrolled upside down on the screen, and after this yellow-on-white the graphics demo restarts. So whatever it does in that final about two seconds long pause shows off that it's capable of displaying white and yellow (with some slightly reddish-pink text, that has me thinking that the "red" portion of the display is working aswell, technically. Just not the way the software expects it.)
Also of note is how the icon looks, I'm fairly sure that's not how it's inteded to be. If so, perhaps related to Adafruit's tftpaint2, where the 'chip so and so' text shows up okay, but the 1-8 icons were flipped. I'm out of my depth here, so I'll just throw out the guess that it's got something to do with how a memory chunk (the image) is transferred to the display, that somewhere in there is a misunderstanding between software and controller.
You clearly have a genuine ILI9481 controller.
Yes, I would like to get this working for you.
The first step is to delete the current library and re-install a fresh download copy.
You seem to have no RED at all.
Does anyone else have a problem with this Shield?
I only own a 16-bit write-only ILI9481. So I have to rely on remote reporting.
The brief "yellow on white" is COLOUR INVERSION. i.e. tft.invertDisplay(true)
David.
I think I already had the latest, but now I've re-downloaded mcufriend_kbv and re-opened graphictest from it. Still the same blue on black, but now with being sure that it's the latest library.
I use the arduino-1.6.6 official linux IDE, if that helps. Are there other libraries I should reinstall that can be of importance, like Adafruit stuff or suchlike.. anything that the program uses that isn't already in mcufriend_kbv?
I think that Bodmer's TFT_HX8357 library supports the 8-bit data bus now. You will need to read the configuration instructions.
I am not at my PC to check.
David.
I'll have a look at it, thanks! So far, the compiler gives a ton of errors on the form DDRA, PORTC, PORTG etc "not declared in this scope". reads Ahh. In User_Setup.h it says "This library supports the Mega and HX8357B/C display drivers only", but it has a define for ILI9481. Luckily I have a Mega, so I can try connecting that, once I find in the code what Mega pins go to what Uno-display pins.