3.95" LCD Module for Mega2560 - Only Half Screen

I have 3.95" LCD Module for Mega2560. The packaging says it has a 9488 driver. I am connecting it directly to a Mega 2560 board. Every example I load only displays correctly for the first (top) half of the screen. Also the touchscreen demo works correctly for up and down axis, but left and right are reversed.

I'm using the LCDWiki examples for testing. I've set the sketch to use 16bit mode for ILI9488 driver.

Sorry if I am not providing sufficient information, I am very new to Arduino and LCDs.

The display is the same as this one below.


I have read some posts discussing R5 and R4 settings. My board has R5 missing. Do I need to bridge this to enable 16 bit?

Hi, @neilsonwheels
Welcome to the forum.

Please read the post at the start of any forum , entitled "How to use this Forum".

This will help with advice on how to present your code and problems.

Thanks for the image of your display.
A copy of your code would greatly help to fix your problem.

Tom.... :smiley: :+1: :coffee: :australia:

It is always best to provide a link to the actual display that you have bought.
However I can identify the board from your photo.

The Mega2560 Shield plugs into the Arduino MEGA2560 header sockets as Nature intended.

If you want to use in 16-bit mode, you must change R4, R5 with a soldering iron. Run the LCDWIKI examples for 16-bit ILI9488.

It comes out of the box in 8-bit mode. Run the LCDWIKI examples for 8-bit ILI9488.

You can use the display with MCUFRIEND_kbv as a SPECIAL e.g.
USE_SPECIAL and USE_MEGA_16BIT_SHIELD and tft.begin(0x9488);
USE_SPECIAL and USE_MEGA_8BIT_PORTC_SHIELD and tft.begin(0x9488);

Note that this display has a design fault which means that it is write-only. Hence tft.readID() will not work and you have to force tft.begin(0x9488);


Thanks David, I made the R4, R5 mod, however I am still only getting half the screen working with the LCDWIKI and MCUFRIEND examples. It doesn't appear to be any different than before I made the mod.

With the MCUFRIEND configuration, I have used the special method. I'm not entirely sure whether I have set everything correctly. I am confused about the tft.begin sections.

For example, in the graphicstest_v25.cpp file I have the following code:

    if (g_identifier == 0x00D3) g_identifier = 0x9481; // write-only shield
    if (g_identifier == 0xFFFF) g_identifier = 0x9341; // serial
    //    g_identifier = 0x7789;                             // force ID

Can you confirm that this is correct?

Thanks for your help, I am eager to play with this display.


I don't know what the graphicstest_v25.cpp file is.

You generally read the ID. If tft.readID() returns 0xD3D3 it means you have a write-only display.
Most other ID values refer to a real-life ID that was successfully read from the controller chip.

In your particular case you are forcing 0x9488

I strongly advise you to read the "how_to" file.
Edit the "shield.h" and "special.h" files.
Edit and Run graphictest_kbv.ino from the examples with tft.begin(0x9488);

Ask if you don't understand.


1 Like

Thanks David, I have been following the how to.
Can you tell me where I make the tft.begin(0x9488); entry?
That part I do not understand.

After making all of the changes to the utility files, the Sketch does not compile.

The how_to says:

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
18. Please run LCD_ID_readreg.ino to verify your non-standard wiring.  Paste the defines to a Forum message.

19. OPEN-SMART Shields have different wiring to regular Uno Shields:
    Edit utility/mcufriend_shield.h:  #define USE_SPECIAL
    Edit utility/mcufriend_special.h: #define USE_OPENSMART_SHIELD_PINOUT_xxx e.g. USE_OPENSMART_SHIELD_PINOUT_MEGA
    Edit MCUFRIEND_kbv.cpp:           #define SUPPORT_8352B

In your case you just need:

    Edit utility/mcufriend_shield.h:  #define USE_SPECIAL
    Edit utility/mcufriend_special.h: #define USE_MEGA_16BIT_SHIELD

Example sketches should compile without error. However most of the examples "guess" 0x9481 if readID() returns 0xD3D3 e.g.

    uint16_t ID = tft.readID();
    //    if (ID == 0xD3D3) ID = 0x9481; // write-only shield
    if (ID == 0xD3D3) ID = 0x9488; // USE THIS FOR YOUR SHIELD

So you need to make sure that all of your sketches use 0x9488

Personally, I test the ID. Which means that the same sketch will work on a proper read-write Uno shield.

If you have compile errors I suggest that you re-install MCUFRIEND_kbv via the IDE Library Manager and re-edit the two utility files.


David. Just to clarify. To change from 8 bit to 16 bit you remove the resistor R4 (make position R4 open circuit) and solder the resistor into position R5.
Is that correct!

Yes. But first of all you need to compare your pcb with the photo in #1.
i.e. same chips, same copper traces, same printing.

If in doubt post a link to the actual display that you have bought.
Or post a photo of the actual pcb on your desk.


Looks similar to the earlier photo. Here’s mine

On another note, I can’t use UTFT as the driver for ILI9488 is 16 bit. There is no driver for 8 bit that I can see.
It does work fine on MCUFRIEND_kvb when the 8bit shield is defined.

Your pcb says NC for positions digital D22-D29 on the 18x2.
Your pcb has no message about changing 8-bit to 16-bit.

I am intrigued. U3 appears to be connected to the NC pins
U2 appears to be connected to D37-D30.

I suspect that there is a pcb error somewhere. Hence they just sell these as 8-bit only.

I would not worry too much. In practice 8-bit is almost as fast as 16-bit.
And 8-bit on a Mega Shield is much faster than running an 8-bit Uno Shield on a Mega.

The only disadvantage of your 8-bit Mega Shield is that few libraries support it. e.g. the (badly spelled) LCDWIKI or (use as special) MCUFRIEND_kbv.


Thanks. I noticed the NC pins but also noted that U3 appeared to be connected as you did, so I thought I might hedge my bets and give it ago hence my question re the jumpers.

Is it possible to write a UTFT driver for the ILI9488 8 bit display? I notice that there are other 8 bit displays supported in UTFT. Can someone point me in the right direction.
I want to use URTouch but I can’t calibrate as URTouch uses UTFT.
I have rewritten the URTouch_calibration.ino to suit the 8 bit display using MCUFRIEND_kbv tft for the display but while repeatable, the cal figures don’t seem to suit this particular display.

Note that UTFT.h is not supported by the Library Manager.

Yes, it is very easy to write a UTFT driver. You just hack the publicly available source code.

Why do you want to use URTouch ?
Your display has the Touch controller on the proper hardware SPI pins.
URTouch is not supported by the IDE Library Manager.
URTouch has no concept of hardware SPI. And you will not be able to use the microSD if you bit-bash with URTouch.

Surely you would use a proper library like XPT2046_Touchscreen.h which understands SPI and is supported by the Library Manager.


p.s. I would expect the URTouch_calibration.ino sketch to work with UTFTGLUE. But it seems pointless when the XPT2046 is on the SPI pins.

But will UTFTGLUE work with the 8 bit ILI9488 on my board?
The reason I am using URTtouch is that I have a number of sketches written using it, which I want to port to some different screen sizes with minimal code change.
I’m not sure of what you mean when you say URTouch and UTFT.h are not supported by the IDE Library Manager.? All programs load and run fine so could you elaborate please.
I have bought another driver board for my SSD1963 display and changed the jumpers to Hardware SPI so it used the standard SPI pins on the mega and it works fine with URTouch.
I never use the micro SD
When you say you hack the publicly available source code, I have only found driver code for 16 bit and I’m not sure if I can hack that.
Having some time on my hand I guess I could rewrite all the sketches to use XPT2046_Touchscreen.h.
Thanks for you reply and any further information.

Henning Karlsen (the author of UTFT.h) will not put the source code on GitHub. So the IDE Library Manager does not recognise UTFT or URTouch. Try the Manager for yourself.

Yes, you can install random libraries into random locations by yourself.
e.g. UTFT and URTouch.

But this means there is no verification or version maintenance from the Manager.

There is a similar situation with the LCDWIKI (badly spelled library) software. i.e. not supported by the IDE Library Manager.

Regarding 8-bit ILI9488. You just need to add the appropriate
UTFT\tft_drivers\ili9488\initlcd.h and UTFT\tft_drivers\ili9488\setxy.h

Allocate a slot in the dsx[], dsy[], dtm[] tables and define the slot number in UTFT.h e.g.

//#define NOT_IN_USE 24
#define ILI9488_8 24

Study the different entries for
UTFT\tft_drivers\ili9341\16\xxxx.h and UTFT\tft_drivers\ili9341\8\xxxx.h


One question I asked still remains unanswered. Will UTFTGLUE work with my 8bit ILI948&?
I tried running UTouch_calibr_kbv but only got the white screen.

I don't know where you got UTouch_calibr_kbv from. It is old. It is not in v2.9.9-Release

It refers to Mr Karlsen's UTFT.h and obsolete UTouch.h

UTouch.h has been replaced with URTouch.h
UTFT will not work with your 8-bit ILI9488 unless you write the appropriate driver.

UTFTGLUE should work fine with your screen. i.e. for TFT graphics.
Have you not tried GLUE_Demo_480x320 ?

When GLUE_Demo is working you can try UTFTGLUE with your legacy UTFT programs (non UTouch )


GLUE_Demo_480x320 only gives a white screen.
I call UTBFTGLUE myGLCD(0,38,39,40,41) or
UTBFTGLUE myGLCD(9488,38,39,40,41) etc, etc and it stays white