HELP Arduino Mega 2560 and 3.5" TFT

I've poured over pages and pages of forum posts and other resources and have had no luck making my 3.5" TFT work.

Quick Info:

  • the display is designed for an UNO
  • I've used an identical-but-smaller display on an UNO successfully with the SWTFT library
  • This display on my mega 2560 shows only white, the code is verified to be running via Serial monitor
  • I've tried the code used for my UNO-based project (SWTFT) with no luck (I thought pinouts are the same)
  • I've tried UTFT with several different model and pin configurations in the init call, and with and without the USE_UNO_SHIELD_ON_MEGA definition commented
  • The eBay listing for the display shows the controller to be ILI9488, and suggests that one use the included code (similar to the ILI9327 init code), which I have. I've used several modified versions of the init code, in fact, with no luck

I'm about out of ideas. I haven't tried the new display on my uno or old display on the mega, as the uno and older screen are hardwired in an enclosure at the moment.

Does anyone have any suggestions?

I've had some limited success and ruled out some things.

  • Using this modified UTFT library, I was able to get the display to display something. It ran the tests as shown, but was very slow and the colour were wrong and grainy, and the display was shifted by some number of pixels both horizontally and vertically
  • Cannot get either the smaller display to work on the Mega or the larger display to work on the Uno, trying all manner of driver and library combinations

The modified library appears to use an 8-bit version of the ILI9327 driver normally found in the UTFT library. This is consistent with what the display seller claims (that it has an ILI9488 chip and to use ILI9327 drivers). On an email request, the seller sent me a zipped folder with code that produces the same result as the above library, but hard-coded in the example instead of in a library. The zip foile also contained a video that shows screen capture of someone loading UTFT, hinting that the above would work, but is useless aside from that.

Now, I've read further on the subject, and speed seems to be an issue on the Mega due to pin/port mapping being slow. I understand this, but example videos on youtube show a working example of this type of shield (perhaps a different chip) on a Mega running the UTFT display tests at "full speed" without any colour distortion. Does anyone have any insight into this? I understand I may need to make rotation adjustments, but the colour and whatnot needs to be correct first.

Lastly, can anyone confirm that my issues would just disappear if I were to buy another similar display that uses the back row of pins on the Mega? Does this change how mapping works? Would the different pin arrangement necessitate a different chip and driver, and thus make the libraries work without hacking them up?

See the attached image.

Your display is designed for a UNO. The TFT should work on a MEGA but be a bit slower.
The microSD will not be able to use the hardware SPI and consequently will need bit-banging.

The first job is to identify which controller that you actually have. Run the sketch from this message:

If it really is a ILI9327, would you be willing to test a library for me?

Regarding MEGA2560 shields. The "one-piece" option seems to use resistors for level-shifting. The TFT and Touch works ok. The SD is totally unreliable.
The "two-piece" option (regular TFT + MEGA adapter shield) should work ok but is a lot more expensive. I have never used them. People are very rude about Sainsmart.

David.

After adding in appropriate print statements, it gives the indentifier to be 38024. Now, I’d downloaded that before but not actually ran it (thinking it a waste for some reason). It worked, with the following notable characteristics.

On the Mega:

  • rotation was portrait
  • colours were wrong
  • items displayed were flickering
  • it was slow

On the Uno it was the same but much faster. I can use the Uno going forward if I can correct the colour and flicker issues.

See attachments for pictures.

We have no idea what sketch you are running. It definitely does not look like any UTFT example.
UTFT has no concept of reading the chip ID.

If you plug the shield directly into your MEGA and run the sketch that I linked to, we could see which controller that you have.

I can assure you that running a guessing game with UTFT is a nightmare. It takes time to rebuild for different "types" and then brain-ache to compare it with the data sheets.

David.

My apologies for the lack of clarity.

I ran one of the sketches in the mcufriend_kbv library to produce those images, and the images were only intended to showcase the remaining colour and flicker issues.

Above, I said that Serial.print(tft.readID()); yielded "38024". Serial.print(tft.readID(), HEX); yielded "9488", which is consistent with the seller claims of the controller.

Ah-ha. I had never thought of looking at a decimal number for the ID !

So you have a UNO shield 320x480 with an ILI9488 controller. It will work fine on your MEGA. As will the Touch library. What is the problem?

I do not believe that you would get those images from the MCUFRIEND_kbv examples. I have the same shield. I can test it with the "old" library version.

David.

Right, so like above, as soon as I used the kbv library, I got "usable" images on both boards (same display), but the Mega is much slower. The images attached in the previous post were indeed taken of the kbv library example.

The information has so far been very helpful and my remaining questions are as follows:

  • Is there any way to speed up the Mega?
  • How do I fix the colour and flicker issues?

I have just run the example with the ILI9488 shield on a MEGA2560 with my current library. It works fine.
I then installed the "old" library (that you got from this website). It is horrible ! All the graphics get rendered correctly but it is very jittery.

I will upload the current library. Possibly tomorrow.

You can speed up the Mega by wiring a custom adapter shield. Basically, it routes the data bus to PORTA (D22-D29) and the SPI pins to D50-D53. I made an adapter from a standard Mega Protoshield pcb by soldering the header pins that I wanted. Unfortunately, most Ebay Protoshields come with the headers mounted. You would need to snip off the males that you don't need.

Quite honestly, you have bought a shield designed for the UNO. If you wanted to use a MEGA, you should have bought the correct shield (and adapters).

David.

The story behind the purchase order of components would explain why I have an UNO shield and am worrying with trying to get it working on a Mega, but it’s not a huge concern now, I suppose. It works on both, but is just slow on the Mega. Assuming there are library or hardware corrections that can be made for that, let’s focus on the colour and flicker issue.

The attached image was generated using the below lines (and the kbv library we’ve been discussing)

#define RED 0xF800
#define GREEN 0x07E0
#define BLUE 0x001F
#define YELLOW 0xFFE0

tft.fillRect(0,0,TFTWIDTH/2,TFTHEIGHT/2,RED); //upper left
tft.fillRect(TFTWIDTH/2,0,TFTWIDTH/2,TFTHEIGHT/2,GREEN); //upper right
tft.fillRect(TFTWIDTH/2,TFTHEIGHT/2,TFTWIDTH/2,TFTHEIGHT/2,BLUE); //lower right
tft.fillRect(0,TFTHEIGHT/2,TFTWIDTH/2,TFTHEIGHT/2,YELLOW); //lower left

What’s going on with the colour? Is it a depth issue? This is unfamiliar territory for me, other than the basic underlying principles of colour rendering.

IMG_3461.JPG

I have just removed the old MCUFRIEND_kbv and replaced with my current one. I really do not feel like swapping again.

I built and ran the following sketch on a UNO with a ST7781 and the MEGA2560 with the ILI9488:

#include <Adafruit_GFX.h>    // Core graphics library
#include <MCUFRIEND_kbv.h> // Hardware-specific library

#define    BLACK   0x0000
#define BLUE    0x001F
#define RED     0xF800
#define GREEN   0x07E0
#define CYAN    0x07FF
#define MAGENTA 0xF81F
#define YELLOW  0xFFE0
#define WHITE   0xFFFF

MCUFRIEND_kbv tft;

void setup() {
    // put your setup code here, to run once:
    tft.reset();
    tft.begin(tft.readID());
    tft.fillScreen(BLACK);
    uint16_t TFTWIDTH = tft.width();
    uint16_t TFTHEIGHT = tft.height();
    tft.fillRect(0, 0, TFTWIDTH / 2, TFTHEIGHT / 2, RED);             //upper left
    tft.fillRect(TFTWIDTH / 2, 0, TFTWIDTH / 2, TFTHEIGHT / 2, GREEN); //upper right
    tft.fillRect(TFTWIDTH / 2, TFTHEIGHT / 2, TFTWIDTH / 2, TFTHEIGHT / 2, BLUE); //lower right
    tft.fillRect(0, TFTHEIGHT / 2, TFTWIDTH / 2, TFTHEIGHT / 2, YELLOW); //lower left

}

void loop()
{
    // put your main code here, to run repeatedly:

}

It worked fine on both displays.

I will upload the current library tomorrow. Something looks seriously wrong with your display.

Regarding speed. These displays work very fast with a “whole 8-bit port” for the data bus. They are marginally faster with a whole 16-bit port. What cripples them is the routing of D2-D9 pins to multiple ports. Even a Due is slow. However, if you route sensibly, the displays are very fast. On an Xmega with VPORTs, it beats most ARMs.

David.

Regarding the speed, I had understood the port routing being the limiter, but didn't know that you could reroute them.

By "reroute", do you mean in hardware (wire up to different pins so routing need not occur?) or in software (rewrite the code that routes the output?)?

I'm beginning to wonder if the display is messed up, or if there's a voltage or current issue somewhere. There aren't any static artifacts, the colour issues are calculated; I'll explain. When drawing a red rectangle, for example, it is comprised of alternating parallel lines of different colour that look "roughly red". When you change the size of the rectangle, even by a single pixel in height or width, the comprising lines are drawn differently. They are the same colours, but are different thicknesses or orientations. It is quite strange.

Thanks for your help so far, it's been great.

I have the same / similar problema.
I have a TFT touch-screen 3.5" mcufriend display, and it works fine on Arduino UNO and Arduino MEGA 2560. I connect it to the same ports. All right, but in Arduino MEGA 2560 is a slower ... I use MCUFRIEND_kbv 2.9.8 library.
How can I speed up the display in arduino MEGA 2560?
If not possible, what display touch-screen 3.5" can I buy with the similar price and size which work on Arduino MEGA 2560? I don't want buy anyone and get slow too.

Thanks a lot in advance!!!

Ok, I understand that, if a route with VPORTs it will go speed up, but ... how? I understand what can I do, but I don't understand how? Any idea?

Shields for mega2560 use the 18x2 header. They do not fit on a Uno.

The Mcufriend for mega2560 shields are cheap. But the SD card probably will not work properly.

If you want screen, touch and SD you have to pay more money.

David.

david_prentice:
Shields for mega2560 use the 18x2 header. They do not fit on a Uno.

I know. But I need some of these ports (18x2) for other things, because of that I want use Mcufriend Uno display on mega2560.

david_prentice:
The Mcufriend for mega2560 shields are cheap. But the SD card probably will not work properly.

Not problem for me. I only need screen and touch, I don't need SD and will not need never.

So, the question is. Can I use Mcufriend Uno display on mega2560 with speed up? Changing the analog ports to some digital ports?
I read this post MCUfriend TFT LCD pin re-assignment - Displays - Arduino Forum and I asked too. Really the problem is the same. To use the Mcufriend Uno display on mega2560 with speed up changing the analog ports to digital ports or something like, and free some analog ports on mega2560. Is it possible?

Thanks!!

Victor

God invented boys and girls. Shields work in the same way.

If you want to use a Uno shield on a Mega2560 it will work fine but be slower than a Uno.
If speed is important to you, buy a Mcufriend mega2560 Shield. The clue is in the number of pins and the

TFTLCD for mega2560

printed on the pcb.

The Uno shield lets you access A6-A15, D14-D53 on a mega2560. (which is a LOT of pins)
The Mega2560 shield lets you access A0-A15, D8-D21 (which is quite a few pins)

Seriously, you should have learned about boys and girls at school.

If you are determined to defy Nature with a Uno shield, XM, YP must be on Analog pins if you want to use the Touch Screen. Verify your unnatural wiring with LCD_ID_readreg sketch. I will only write a SPECIAL for wiring that has been tested.

David.

Ooooook, all understanded.
Thanks a lot to all!!!