Slow Screen Redraw using EastRising 3.5" TFT-LCD Capacitive Touch Screen Display

[DonpK]

Screen redraw times using an East Rising 3.5" TFT-LCD Capacitive Touch Screen Display are about 10 to 15 times slower than a similar Adafruit 3.5" display. I worked with Cal on the EastRising display earlier in the year. The capacitive touch seems to work fine, but the redraw seems much slower than it should be. Here are some tests I've done.

1. Run Adafruit's graphicstext.ino on both the Adafruit display with HX8357 and EastRising with ILI9488. Both driver libraries are installed in Arduino library folder. -Display times on both displays are almost the same.

2. Run DPKgraphicstest_V2.ino which redraws screen with a solid color on both displays using two different versions of the GUIslice library.

The Adafruit display uses the regular GUIslice 0.16.0 library. The East Rising 3.5" display uses the GUIslice-WIP-CapCalib_01-04-21 library which includes the ard-shld-eastrising_35_ili9488_cap.h file written by Cal for this display which has a capacitive touch screen.

The redraw time using the Adafruit/GUIslice 0.16.0 setup takes 542,068µS. The redraw time using the East Rising/the GUIslice-WIP-CapCalib_01-04-21 setup takes 8,500,500µS.

Do you have any idea why the GUIslice-WIP-CapCalib_01-04-21 is so much slower?

I have attached several files I've used for this test. The two graphic tests:

  *    `graphicstext.ino`
  *    `DPKgraphicstest_V2.ino`

The two GUIslice library versions. In the attachment, the two different GUIslice libraries both named "GUIslice" are subfolders. Each GUIslice folder has a text file identifying which version it is:

  *`GUIslice-WIP-CapCalib_01-04-21`
    ---`GUIslice`
  *`GUISlice_0.16.0-AdafruitTFT_config_with_Resistive_Touch`
    ---`GUIslice`

EastRisingRedrawTestFiles.zip

[Pconti31]

@DonpK Sorry, but I can't follow what you are testing here. When I look over your examples the Adafruit version is using Hardware SPI and the GUIslice config has a different set of pins in use, maybe software spi.

Also, the Adafruit is testing lots of graphics while GUIslice only has fill rect of the background color.

I would suggest inside your GUIslice config you turn off clipping and touch since that's not what is being tested,.

#define GSLC_CLIP_EN 0
//#define DRV_TOUCH_ADA_FT6206
////#define DRV_TOUCH_CALIB     
#define DRV_TOUCH_NONE

For some reason, loop won't cycle through both colors Hmmm, maybe you are running into some optimizations Calvin has in place. I replaced setting background with a Box the size of whole screen and setting its color instead.

Again, your two test programs don't make a fair comparison so I modified them for your display and made the Adafruit and GUIslice versions as close as possible. Now I don't have your hardware so I can't test further so that's up to you and Calvin but at least the numbers will be correct as far as comparing them side by side. DPKgraphicstest_V2.zip graphicstest.zip Paul--

[DonpK]

Thanks @Pconti31 for your help and suggestions.

I am testing two different TFT-LCD displays - the Adafruit 3.5" breakout display, and the East Rising 3.5" display. Both displays are using ATMega1284P microcontrollers. Both displays are using SPI.

Thank you for modifying and simplifying the two redraw test sketches I attached in my first posting. Since the two displays have different SPI pins, I added pin #defines for both displays on the GUIslice test sketch. The appropriate #defines should be uncommented for the specific board. I also added "PC" to the file names to indicate they are your versions.

I've attached your modified test sketches as well as a text file giving the redraw time results. There are four sets of timings: one for each display using the Adafruit graphicstest sketch and one for each display using the GUIslice sketch. The GUIslice library is GUIslice-WIP-CapCalib_01-04-21 which Cal wrote for the East Rising display. The Adafruit display uses the regular GUIslice library. As the results show, the East Rising display is much slower using GUIslice-WIP-CapCalib_01-04-21

Paul Conti Files_07-1-2021.zip

[Pconti31]

@DonpK @ImpulseAdventure A quick look at your numbers and it looks to me the issue is with the ILI9488 Library not GUIslice. I made a hack to ILI9488.cpp and would be curious if the numbers improve at all. ILI9488.zip

Paul--

[DonpK]

@Pconti31 @ImpulseAdventure Thanks Paul. I tried your version of ili9488.cpp. On the East Rising display, the PCDPKgraphicstest.ino redraw timing sketch runs about 8 times faster with your ili9499.cpp versus the ili9499.cpp file which is in the Arduino ILI9499 library. However the same sketch redraws 15 times faster on the Adafruit. Note that the East Rising display is using GUIslice-WIP-CapCalib_01-04-21 and Adafruit display uses GUIslice 0.16.0. Note also, that the "regular" ILI9488 library is a version Cal gave me last November when we started working on this project. I'm not sure whether he modified the standard Jaret Burkett ILI9488 library.

I'm attaching the latest version of my notes on these timing tests which include your ili9488.cpp Note that some of the colors don't display correctly.

TFT-LCD Redraw Tests Using P. Conti Sketches_07-19-2021.zip

[Pconti31]

@DonpK @ImpulseAdventure Note also, that the "regular" ILI9488 library is a version Cal gave me last November Ah! Well, that's a horse of a different color if he modified it. I just modified one I pulled from github jaretburkett/ILI9488.

Anyway, The numbers are still horrible and the display unusable at this point. Attached is my attempt to fix the colors. The first attempt was mostly to see if I could help performance but without the display not much I can do. Good luck! ILI9488.zip Paul--

[DonpK]

@Pconti31 @ImpulseAdventure Thanks for your help. Do you know of any TFT-LCD displays with capacitive touch that GUIslice already supports? Don

[Pconti31]

@DonpK @ImpulseAdventure I don't own one so maybe you a should post a new issue asking for recommendations from someone using such a display. You could also try using a faster MCU like the ESP32 with TFT_eSPI which claims support for ILI9488 spi displays. Also, the chinese code lovyan03/LovyanGFX claims to be even faster then TFT_eSPI.
Paul--

[ImpulseAdventure]

Hi guys -- just trying to catch up on some emails again (I'm in the midst of packing for a home renovation so things are "busy" to say the least :)

@DonpK @Pconti31 -- I looked back at the ILI9488 library I had sent to Don in November and can confirm that it is identical to the same / latest version of jaretburkett/ILI9488. In other words, you should be able to use the modifications that Paul attached above (ie. for write16BitColor and fillRect).

Also, Don -- I may have overlooked something, but I'm wondering if you might be able to use the latest GUIslice version instead of the CapCalib version? I believe all of those changes were integrated. That way, perhaps one could compare apples-to-apples with the same code versions of GUIslice? ie. use the same "latest" GUIslice for both the Adafruit display and EastRising display modes?

thx

[DonpK]

@Pconti31 @ImpulseAdventure
I ran the redraws tests on the two different TFT-LCD displays - the Adafruit 3.5" breakout display, and the East Rising 3.5" display. Both displays are using ATMega1284P microcontrollers. Both displays are using SPI. Both tests used the latest GUIslice Version 0.16.1.2 Both tests used PCDPKgraphicstest_V2.ino (attached) which redraws the screen alternating between two colors. The Adafruit displays uses ard-adagfx-hx8357-simple.h and the EastRising display uses ard-shld-eastrising_35_ili9488_cap.h (attached).

The Adafruit display redraws about 15 times faster than the EastRising display - 541,704µS for the Adafruit versus 8,422,840µS for the EastRising display.

PCDPKgraphicstest_V2.zip ard-shld-eastrising_35_ili9488_cap.zip

[Pconti31]

@DonpK @ImpulseAdventure I read the datasheet for the ILI9488 chip and came up with this version of ILI9488 library that should be faster than the one I gave you before and the colors should be correct. ILI9488-fast18bit.zip

This I'm afraid is likely as fast as you are going to get. This chip has two problems.

1. It's SPI top speed is 15mhz while the Adafruit's HX8357 is 20mhz.
2. It only supports 18bit color not 16bit color like the Adafruit. This means it needs to write one extra byte for each color. Or 153600 extra writes for a screen fill.

Now the ILI9488 library isn't coded to get the max speed it nevertheless could never overcome these two issues. If the HX8357 gives you 541ms the theoretical top speed for the ILI9488 will be 541*1.5 (15mhz plus one extra byte) = 811.5ms. Though, it would take a lot more work than I can put into this driver to get even that speed.

Now you should test my new library against the PCgraphicstest.zip that doesn't use GUIslice. This will show you the best times you can get. If then you test my library against GUIslice and its much slower then I would guess the touch handling for the Capacitive chip is what is the problem. If so, you can confirm its the problem by turning off touch in ard-shld-eastrising_35_ili9488_cap.h as so:

  //#define DRV_TOUCH_ADA_FT6206        // Adafruit FT6206 touch driver
 //#define DRV_TOUCH_CALIB      // DPK Added 01/10/2021 20:10
 #define DRV_TOUCH_NONE

If the numbers now match PCgraphicstest.ino we have identified the problem.

Unless, Calvin has a better idea. Paul--

[DonpK]

@Pconti31 @ImpulseAdventure Thanks for you additional work, Paul. Disabling the touch capability didn't have any effect the redraw speed, but using your modified ILI9488 definitely did.

Running the P. Conti non_GUIslice, modified version of Adafruits's graphicstest.ino: EastRising 3.5" TFT-LCD with Burkett ILI9388 Library: Redraw Time = Red 8,422,700µS (about the same time for the Adafruit 3.5" TFT-LCD) Redraw Time = Yellow 8,499,632µS (about the same time for the Adafruit 3.5" TFT-LCD)

with P.Conti modified version of ILI9488 library: Redraw Time = Red 1,226,964µS Redraw Time = Yellow 1,226,972µS

Running your_GUIslice, modified version of Adafruits's graphicstest.ino: with P.Conti modified version of ILI9488 library:
Redraw Time = Red 1,226,688µS (Adafruit 3.5" display - 541,712µS) Redraw Time = Yellow 1,226,692µS (Adafruit 3.5" display - 541,700µS)

So your modified ILI9488 library resulted in a speed improvement of ca. 7x. As you may have seen, Burkett also has some observations about speed in regards to color processing and Arduino processors.

[Pconti31]

@DonpK @ImpulseAdventure Well, I found one last way to sqeeze a little more performance out of this library. This really is my last attempt. Sorry, I couldn't do more. ILI9488-fast18bit-v2.zip Paul--

[DonpK]

@Pconti31 @ImpulseAdventure

Nice work, Paul! Here are the current times using your ILI9488v2:

EastRising 3.5" TFT-LCD with P. Conti ILIILI9488-fast18bit-v2 and the GUIslice version of the graphicstest.ino:

Redraw Time = Red 763,656µS Redraw Time = Yellow 763,660µS

This is quite an improvement over your V1 and not too much slower than the Adafruit 3.5" display.

I want to do some more experimenting, but a few trials with some simple GUIslice/Builder elements (toggle switch, etc.) have a redraw time which is quite adequate.

BTW, here is a discussion of another ILI9488 library for the same EastRising 3.5" display. And here, apparently, is the driver he came up with. Don

[Pconti31]

@DonpK @ImpulseAdventure Great! I'm happy for you. Good luck with the rest of your project. Paul--

[DonpK]

@Pconti31 @ImpulseAdventure As I work with the EastRising 3.5" display. I've noted a couple of things:

1. This line #include "../configs/ard-shld-eastrising_35_ili9488_cap.h" is missing from the src/GUIslice_config.h file in GUIslice versions "0.16.1.3" and "0.16.1.2" and possibly some earlier versions. However, the ard-shld-eastrising_35_ili9488_cap.h config file is present in the configs folder.
2. I've noticed a problem that does not occur on either the Adafruit or EastRising displays using GUIslice Ver. 0.16.0, but does occur on both displays using Ver 0.16.1.2. If a button is pressed, say on the KeyPad, the button will freeze up in the "Selected Color" mode. Sometimes repeatedly pressing the button will get it to complete its function, sometimes the entire display is frozen and needs to be rebooted. This is an intermittent problem.

Are the earlier versions of GUIslice between 0,16,0 and 0,16,1,3 available somewhere for downloading? I'd like to try to troubleshoot this problem. I'm using the latest version of Builder. Thanks, Don

[Pconti31]

@DonpK @ImpulseAdventure 16.0 is simply in Releases. Calvin doesn't use tags between check ins so I really don't know how to get other versions. Hopefully he will join in.

The real problem is that most things have been heavily modified for non-touch GPIO input. So I really don't think comparing the different versions would help you out. It wouldn't me. Good luck if you go that route.

I believe you would be better off coming up with a small repeatable sample with a list of touches that cause the problem using the standard Adafruit TFT display and posting it. Leaving the debugging to Calvin. Paul--

[DonpK]

@Pconti31 @ImpulseAdventure Thanks, Paul, that's a good suggestion. I'll put together a simple example that appears to run fine on V0.16.0, but has this problem I described with the latest versions.

It's quite possible, perhaps even likely, that the problem is caused by something I'm doing wrong.

Don

[ImpulseAdventure]

Hi @DonpK --

Please note that I'm in the midst of a renovation so responses may be delayed (not to mention much of my electronic test hardware is living in a stack of boxes :)

Paul correctly notes that I haven't created an official release for some time. In fact, we are just about to release version 0.17, but I had wanted to ensure my recent fixes (eg. for the external inputs, redraws, focus, etc.) are looking stable first. Your observation comes at the right time as perhaps an error did slip through, so it would be good to identify this now.

In order to narrow down versions that worked vs those that don't, you can actually download them from GitHub even if an official release wasn't made. For example:

• Go to the main GUIslice repository page
• Click on the "commits" clock symbol under the green "Code" button
• Select one of the commits for an older date / version you'd like to try
• Click on the "< >" button on the far right (Browse the repository at this point in the history)
• Click on the green "Code" button and select "Download ZIP"

As Paul mentioned, it will be much easier to debug if you are able to strip down / recreate your observation with a simple example.

Hope that helps!

[DonpK]

@ImpulseAdventure @Pconti31 I can describe in a bit more detail the touch problem I discussed previously.

The problem involves the display freezing after a touch. I'm using the latest versions of GUIslice and Builder. The problem does not occur on the Adafruit resistive display, only the EastRising capacitive display.

Using the keypad widget as an example, if the user touches the keypad digit very quickly, that is, the time the finger is in contact with the screen is very brief, the digit is entered properly. However, if the finger stays on the display for a slightly longer period of time, occasionally the display freezes, that is, the keypad digit changes to its "selected" color, but the digit is not entered. The key needs to be touched again for the digit to be entered.

I'm afraid this is not much to go on, especially since you don't have this EastRising display, but I thought it might ring some bells. Don

[Pconti31]

@DonpK @ImpulseAdventure Try playing around with ADATOUCH_SENSITIVITY in your ard-shld-eastrising_35_ili9488_cap.h file. I would first increase 40 to 128. Then go up or down depending upon your results. Paul-

[DonpK]

@Pconti31 @ImpulseAdventure

I'll give it a try.

I've also contacted the person who has written a driver for the FT6236 which is the actual controller in the EastRising display, not the FT6206, although Adafruit claims their library works with the FT6236.

Don

[ImpulseAdventure]

Hi Don --

First, please try increasing the GSLC_TOUCH_MAX_EVT in your config file (eg. from 1 to 5) in case your touch driver is falling behind on the touch events it generates.

I recommend we narrow down the observations with a much simpler sketch than the KeyPad as there is a lot more complexity within the keypad widget. When you run the latest GUIslice (eg. 0.16.1.x) and ex04_ard_ctrls:

• Do you see any lagging? Did it change with an increased MAX_EVT?
• Do you ever see a case where it looked like a control "froze"? (ie. remain highlighted even though you released your touch)

thanks

[DonpK]

@ImpulseAdventure I tried changing GSLC_TOUCH_MAX_EVT running the KeyPad widget and didn't see any improvement. About 20%-50% of the time the KeyPad key would freeze in the "Selected" color without completing the digit entry.

I tried two versions of ex04_ard_ctrls- the version from the Builder examples and the version from the GUIslice-only examples. On both, I increased the dimensions of the Checkbox widget on the 3.5" display to make it easier to test the touch action.

The GUIslice-only version performed well, that is, the box changed from checked to unchecked with each touch regardless of the touch length. Increasing the GSLC_TOUCH_MAX_EVT at a certain point seemed to reduce the performance, that is, the Checkbox wouldn't alternate states as reliably with a single press.

The Builder version of ex04_ard_ctrls also performed much better than the KeyPad although perhaps not changing state quite as reliably as with the GUIslice-only version. Changing GSLC_TOUCH_MAX_EVT didn't improve performance much.

Do you have a GUIslice-only version sketch example of the KeyPad widget? The one I use I generated with Builder. It might be interesting to see if there was any performance difference. We may be just looking a performance limitation of the touch driver/Arduino processor.

Thanks for you help, Don

[Pconti31]

@DonpK @ImpulseAdventure Have you tried setting ADATOUCH_SENSITIVITY to 128 yet? This value is the default for FT6206 that is currently being overwritten by GUIslice to a lower limit of 40. Paul--

[DonpK]

@Pconti31 @ImpulseAdventure I tried 128 in ard-shld-eastrising_35_ili9488_cap.h config file for the ADATOUCH_SENSITIVITY setting. I didn't see any improvement. The Keypad widget regularly hangs up in the "Selected" mode without entering the digit. The Builder and GUIslice versions of ex04_ard_ctrls as mentioned previously, run pretty well. Don

[Pconti31]

@DonpK @ImpulseAdventure Maybe the problem is the inefficient way Adafruit implemented the driver. Well, that may be harsh. They implemented support for gestures but it's not really the FT6236's strong suit. Attached is my edits of the library, removing gesture support. It will run faster, so maybe it will help?

Paul--

[Pconti31]

@DonpK @ImpulseAdventure I really should spend more time looking code over before posting :( Here is what I hope is a working version of my edits for FT6206 library. Paul_V2_Adafruit_FT6206.zip Paul--

[DonpK]

@Pconti31 @ImpulseAdventure Thanks, Paul, for your efforts. I know it's challenging where you don't have the display itself for testing. Paul_V2_Adafruit_FT6206 works okay. However, I don't see any change in the "freeze" problem we're looking at,

I've attached a screenshot video showing what's happening and the difference between short screen taps and longer ones. Sorry is so short, but the file size limit appears to be 10mB Don

https://user-images.githubusercontent.com/13510364/131936921-a612a89d-472e-4acc-b288-d7e37131562e.mp4

[Pconti31]

@DonpK @ImpulseAdventure This maybe a problem with the new Input Controls code.

When you first press the '1' button but instead press say the '9' button I'm guessing the 9 doesn't work. Is that true? If true, it means the '1' button is being treated like a rotary or physical 'arrow' button was tabbed to the position and selected, but now the code is waiting for you to press either a physical 'enter' button or touch the '1' button.

In this case we can go back in time and try a working code base, then move forward until the code breaks to identify where we added the problem.

Now if the '9' button above works fine or the code base before the Input Control is added then you might just be out of luck.

Use the message from ImpulseAdventure commented 27 days ago above for directions on how to get a complete working earlier code base. I would try the one just before Input Controls are added. Commits on Apr 30, 2021
Add runtime pressure calibration for #363 e5eb723 Paul--

[DonpK]

@Pconti31 @ImpulseAdventure "When you first press the '1' button but instead press say the '9' button I'm guessing the 9 doesn't work."

I'm not quite clear on the button sequence you're suggesting. Press '1' and if it works then press '9', or start by pressing '9', or press '1' and if '1' hangs try '9' to see if it works normally? Don

[Pconti31]

@DonpK @ImpulseAdventure Well, a lot of details have been given in all of the above posts. So I thought it would be a good idea to step back and try and understand the current issue. Above at various times you have posted that the device seems to hang or not take input.

Now given your video above the '1' button is glowing when you touch it and it stays glowing even though it should at best just flash. Also, nothing appears in the text box. Then in the video you repeat touch '1' button and then it appears to work, then you press it again and a second 1 appears.

I'm asking if you do this experiment again, get the '1' in a glow state but this time press '9' instead of '1' what happens? Does a 9 show up in the text box or does the keypad ignore the press? Paul--

[DonpK]

@Pconti31 @ImpulseAdventure Your second paragraph describes what's going on well. I've prepared a longer video and uploaded it to a Google Drive file. Here is the link. Hopefully, you'll be able to play it.

The issue involves what I'll call "short press" and "long press" and since it's not clear exactly how long the screen must be pressed for a "long press", it's not possible to exactly reproduce the freeze a 100% of the time, but it happens regularly.

I've written a short "script" describing what's in the video.

1. Long press '1'. 1's key freezes in "Selected" mode, but no digit appears.
2. Long press '9'. 1's key turns off "Selected" mode and 9's key freezes in "Selected".
3. A couple of Short presses and 9's key comes out of "Selected" mode and '9' is entered in digit window.
4. Long press on BS. BS key freezes in "Selected" mode and '9' remains in digit window.
5. Short press on BS. BS key comes out of "Selected" mode and deletes '9'.

Don

[Pconti31]

Well it confirms my theory of the input control being the problem. Of course, could still be your ft6236 chip. Next download the GUIslice version I mentioned above. If it works we are on the right path otherwise you may just be hosed.

[Pconti31]

@DonpK @ImpulseAdventure Some good news (unless you are Calvin). After viewing your video I tried my Mega with adafruit's 2.8 ili9341 display with using the stmpe610 resistive touch chip and easily reproduced the problem using ex26. This is using GUIslice version 0.16.1.3.

It's also not the new Input Control since long press also freezes the version prior to the Input Control. Of course, this version has no select glow state for the button. Commits on Apr 30, 2021 Add runtime pressure calibration for #363 e5eb723 Paul--

[ImpulseAdventure]

Great! I’m really glad to hear that it was observed on the Adafruit 2.8 resistive since that means I should be able to recreate it on my own hardware too.

Apologies again for the delays as work and renovations have been keeping me very busy at the moment. I will aim to do some testing tomorrow so hopefully can get this addressed.

Many thanks for all the help in debug & reporting!

[DonpK]

@Pconti31 @ImpulseAdventure Paul, I'm glad you were able to view the video and reproduce the problem locally. That should make troubleshooting easier. I apologize that you had to request share permission for the video. I thought I had set it up so anyone with the link could view it. I have now done that (I hope).

Cal, no rush on my part; take a look at it if you get some time.

Don

[ImpulseAdventure]

Hi guys --

While I couldn't reproduce the same behavior with my Adafruit 2.8" resistive display on ex26 while long-touching & releasing over the same key, I can observe it if I touch a key and drag outside of the keypad before releasing the touch. It wasn't actually a "freeze" -- it just didn't release the glow state in this "TOUCH_UP_OUT" transition.

My hunch is that the long touches on your display are eventually registering an errant touch event outside of the keypad area which is mimicking a release similar to what I observed.

I have fixed the "TOUCH_UP_OUT" transition now and checked in the code as version 0.16.1.5. If you still observe the issue with your display using this update, please do the following:

• Uncomment "DBG_TOUCH" in your config file
• Change DEBUG_KEYPAD from 0 to 1 in /src/elem/XKeyPad.h
• Run ex26_ard_calc
• Touch one of the input areas to bring up the keypad
• A) Briefly touch the 1 button and release
• B) Long hold on the 9 button and release (we might see it stay highlighted)
• Please attach the log file to this issue.

Thanks!

[Pconti31]

The new update worked for me.

[DonpK]

@ImpulseAdventure @Pconti31

I was able to reproduce the problem on my Adafruit 3.5" display as described by Cal. The update has corrected the problem on that display.

The update has also corrected the "freeze" problem on the EastRising 3.5" display. One note: the #include "../configs/ard-shld-eastrising_35_ili9488_cap.h" is not in the GUIslice_config.h file. However, there is a ard-shld-eastrising_35_ili9488_cap.h file in the configs folder.

Thanks to both of you guys for getting this display into a usable condition and, of course, thanks for the enormous amount of time and effort you've put in on this great product!

Don

[ImpulseAdventure]

Really glad to hear it is working properly! I have also checked in a change to add the extra configuration for your display.

Closing the issue, but please feel free to open a new one if other things come up. thx

[m-a-c-f]

I need help with ILI9488. There no way to make it work with parallel 16 bits.

This is my init code:

LCD_COM(0XF7);
LCD_DATA(0XA9);
LCD_DATA(0X51);
LCD_DATA(0X2C);
LCD_DATA(0X82);

LCD_COM(0XC0);
LCD_DATA(0X11);
LCD_DATA(0X09);
LCD_COM(0XC1);
LCD_DATA(0X41);
LCD_COM(0XC5);
LCD_DATA(0X00);
LCD_DATA(0X0A);
LCD_DATA(0X80);
LCD_COM(0XB1);
LCD_DATA(0XA0);
LCD_DATA(0X11);
LCD_COM(0XB4);
LCD_DATA(0X02);
LCD_COM(0XB6);
LCD_DATA(0X02);
LCD_DATA(0X22);
LCD_COM(0XB7);
LCD_DATA(0Xc6);
LCD_COM(0XBE);
LCD_DATA(0X00);
LCD_DATA(0X04);
LCD_COM(0XE9);
LCD_DATA(0X00);
LCD_COM(0X36); //MEMORY ACCESS CONTROL
LCD_DATA(0XB8); //HORIZONTAL

// LCD_DATA(0X08); //VERTICAL

LCD_COM(0X3A); //SET DBI
LCD_DATA(0X55); //16 BITS INTERFACE

LCD_COM(0XE0);
LCD_DATA(0X00);
LCD_DATA(0X07);
LCD_DATA(0X10);
LCD_DATA(0X09);
LCD_DATA(0X17);
LCD_DATA(0X0B);
LCD_DATA(0X41);
LCD_DATA(0X89);
LCD_DATA(0X4B);
LCD_DATA(0X0A);
LCD_DATA(0X0C);
LCD_DATA(0X0E);
LCD_DATA(0X18);
LCD_DATA(0X1B);
LCD_DATA(0X0F);
LCD_COM(0XE1);
LCD_DATA(0X00);
LCD_DATA(0X17);
LCD_DATA(0X1A);
LCD_DATA(0X04);
LCD_DATA(0X0E);
LCD_DATA(0X06);
LCD_DATA(0X2F);
LCD_DATA(0X45);
LCD_DATA(0X43);
LCD_DATA(0X02);
LCD_DATA(0X0A);
LCD_DATA(0X09);
LCD_DATA(0X32);
LCD_DATA(0X36);
LCD_DATA(0X0F);

LCD_COM(0X11);
delay_ms(120);
LCD_COM(0X29);

The LCD behavior is:

And I made some modification to my LCD module, I start to suspicious that this module cannot work with 16 bits.

Any tip?

[Pconti31]

@m-a-c-f I don't own this board so I can't be of any further help but here is what little I know: It looks like your board is only 8 bit not 16 bit parallel and is made specially for Arduino Mega as a shield.

Some documentation I found:

Demo_Arduino_Mega2560.zip 3.95inch_Arduino_8BIT_Module_MAR3953_User_Manual_EN.pdf

In the future you should post a new issue if you what help I wouldn't usually look at any closed issues. Paul--

[m-a-c-f]

Thank you!

You are absolutely right. This board is 8 bits only.

Regards.