320 x 480 TFT ILI9481 Slow on MEGA

You either re-route the microSD SPI pins (D11-D13) to D50-D52 e.g. showBMP_kbv_Uno
Or you use software SPI on D11-D13 e.g. showBMP_not_Uno

Software SPI involves using a third party SD library. Instructions in showBMP_not_Uno

David.

What happens with SD_SS? GND, 53 or 10?

david_prentice:
You will be surprised !!!

David.

OK care to enlighten me, and others, or is it a secret?

To me everything you have said so far seems to align with my guess.

Take it easy Grumpy_Mike.

I've been trying to get SdFat to work like showBMP_not_Uno instructs, but I keep on getting "'SdFatSoftSpi' does not name a type".

I uninstalled the version of SdFat I had, installed and ran all "official" versions on the IDE list, from 1.0.1 through 1.0.5. All give the same result.

What am I missing?

David, great library by the way. I'm chuffed at my new TFT speed.

Grumpy_Mike:
OK care to enlighten me, and others, or is it a secret?

To me everything you have said so far seems to align with my guess.

These particular Shields use 8080-8 parallel interface for the TFT.
And SPI for the microSD

Very few display boards or modules make the IM# pins available to the user.
The displays are manufactured for 8080-8, 8080-16, SPI, ... interface and you cannot alter it.

Some displays from Adafruit and EastRising do let you change the IM# pins.

Surplus parallel 8080-16 and 8080-8 displays are cheap. SPI capable displays are expensive.

David.

heinburgh:
I've been trying to get SdFat to work like showBMP_not_Uno instructs, but I keep on getting "'SdFatSoftSpi' does not name a type".

I uninstalled the version of SdFat I had, installed and ran all "official" versions on the IDE list, from 1.0.1 through 1.0.5. All give the same result.

If you route the microSD to the Mega's hardware SPI pins, the SD.h library works out of the box. e.g. showBMP_kbv_Uno
Obviously you must set an appropriate SD_CS define. i.e. 53 if you re-routed SD_CS to 53.

There is no need to use the SdFat.h library if you re-route.
If you use a Uno shield on the Mega, you must use SdFat because the microSD is on the Uno SPI pins.

Note that you have to configure SdFat library i.e. edit a library H file.

David.

I'm using an UNO shield on a MEGA. Simply because I didn't realise my mistake until after the item arrived. It's from China on EBAY and the sell it as UNO/MEGA shield.

Could you point me to the right direction for the edits to the SdFat library file?

The instructions are in the showBMP_not_Uno sketch.
If you have a question, quote the instruction that you do not understand.

This will help me to improve the instructions.
Especially for non-English speakers but improvements for Brits / Americans would be good too.

David.

david_prentice:
The instructions are in the showBMP_not_Uno sketch.
If you have a question, quote the instruction that you do not understand.

This will help me to improve the instructions.
Especially for non-English speakers but improvements for Brits / Americans would be good too.

David.

Hello David,

To get back to the annoying topic of running TFT's for UNOs on MEGAs. I'm doing a little project where I was supposed to use this TFT with an UNO - but then the need to use softwareserial popped up - now the UNO is out the window, in with the mega. I connected the wiring as you mentioned earlier in this post and the display works like a dream, as quick as on the UNO. Problem is the touch screen. The touch screen works well on the UNO but no response on the MEGA.

Please tell me there's something I can do to get the touch screen going on the mega...

RM68140 320x480 ID=0x6814. Picture below.

Think about it. The calibration sketch is designed for the shield. So it only diagnoses data pins on 2-9 and A0-A5.

If you have moved data pins to 22-29 on the Mega, you need to map the Uno diagnosed pins.
E.g. if XP, YM were diagnosed on 6,7 they would now be 28, 29.

It looks very painful to connect lots of jumper cables. I would make a proper Adapter with a Protoshield.
If you map data to 22-29 and SD pins to 50-52, the TFT, Touch and SD will work fast and efficiently.

David.

Beauty! Thanks David.

David, another question on this same TFT - I just loaded an exact copy of a sketch on a second identical tft screen (picture in post #21) but the area where touch work is notably smaller on the bottom of the second screen, I guess with about 5mm.

Loaded touch_shield_kbv and sure enough, one can clearly see the difference when painting lines along the edges.

Is this software related? Same chip, according to the serial output:

Found unknown LCD driver
ID=0x6814
Screen is 320x480
Calibration is:
LEFT = 920 RT = 150
TOP = 940 BOT = 120
Wiring is: SWAPXY
YP=55 XM=56
YM=29 XP=28

What's this all about?

Please use the TouchScreen_Calibr_native sketch from the v2.9.8 examples on a Uno.

Copy-paste the debug output from the Serial Terminal.

It is not uncommon for Touch Panels to be a bit vague in one corner. I doubt that many people ever notice.

Most apps use "buttons" which are not very critical. A Paint sketch might follow the stylus over the screen. A calibrated screen should give you a perfect point. But possibly with one missing corner.

David.

I tried that, and changed the pins to this: int XP = 28, YP = A1, XM = A2, YM = 29; since I'm using it on a MEGA.

Says "broken screen" in small font in the middle of the screen, Serial output:

TouchScreen.h GFX Calibration
MTouchScreen.h GFX Calibration
Making all control and bus pins INPUT_PULLUP
Typical 30k Analog pullup with corresponding pin
would read low when digital is written LOW
e.g. reads ~25 for 300R X direction
e.g. reads ~30 for 500R Y direction

BROKEN TOUCHSCREEN
ID = 0x6814

If you have a DMM you can measure the resistance in the normal way.
A single crack in the Touch glass will render it "broken".

A fellow member sent me a Red 0x6814 shield. The Touch works ok.
I presume that the screen in #0 is a 3.5" Blue ILI9481. It does not have a Touch Panel.

You can recognise Touch Panels by a 4-way ribbon with gold printed traces. Sometimes with printed icons.

David.

Hi David,

When using my 3.5" MCUfriend touch tft it suddenly started registering fake "touches" on the bottom left corner, seems to be at random time intervals. I thought the MIN_PRESSURE may be too low causing the touch feature to be too sensitive, but increasing that value even up to 500 from the default 20 made no difference.

Any idea what this can be? Any test I can run to try and debug this issue?

Thanks,
Hein

There will always be occasional glitches. I did not write the TouchScreen.h library. I would prefer a different algorithm for processing a "valid" touch. e.g. median from 5 readings.

But you can always do some processing of your own. e.g. has the touch registered in the same place for several milliseconds?

This is pretty easy to do with buttons. Not so easy if you are drawing a work of Fine Art.

David.

david_prentice:
But you can always do some processing of your own. e.g. has the touch registered in the same place for several milliseconds?

Is there a sketch in the examples that can tell me where and for how long it was pressed for?

To answer my own question above, I revisited my 3.5" MCUfriend touch screen and getting phantom screen touches every now and then. This is the code I inserted in the loop, just before the touch screen conditions. It forces a wait of 120ms before a touch is registered as a real touch.

boolean tapped;
unsigned long newTapTime;
int tapSensitivity = 120;



void loop
{

    if ((tp.z > MINPRESSURE) && (tp.z < MAXPRESSURE) && !tapped)           //   NEW TAP
    {
      tapped = true;
      newTapTime = millis();
    }

    if (!(tp.z > MINPRESSURE && tp.z < MAXPRESSURE) && (millis() - newTapTime > tapSensitivity))   // NO TAP
    {
      tapped = false;
      realTouch = false;
    }
      
    
    
    if (tapped && millis() - newTapTime > tapSensitivity)
    {
      Serial.println(F("<<<  REAL TOUCH  >>>"));
      realTouch = true;
    }  
    else
      realTouch = false;
        
    if (realTouch) 
    {

     .....   rest of touch screen directions here.