800x480 ssd1963 display with UTFTGLUE

Using Arduino Displays
1

I’m mainly posting this incase someone with similar displays and drivers is trying to find what libraries are available to use.
Thanks David for all your work.
I have a 800x480 5” ssd1963 display (ER-TFTM050-5) with a ER-AS-SSD1963 driver board. It is attached to a Arduino Mega2560.
I have been using the excellent UTFT and UTouch libraries as I haven’t found any other libraries to drive this board and display.
I came across the UTFTGlue library today via this forum so I have downloaded it and installed it.
I needed to make a few changes/additions to the 800x480 example but it is up and running fine.
My main question is regarding the line UTFTGLUE myGLCD(0x91 63, A2, A1, A3, A4, A0);.
Further down, commented out with comments re changing your model parameters, is UTFT myGLCD(ITDB50, 38, 39, 40, 41); which I changed to
UTFT myGLCD(SSD1963_800480,38, 39, 40, 41); which I know works.
I added to setup()
PinMode(8,OUTPUT);
digitalWrite(8,HIGH); //to turn the black light on

Both those changes were necessary to get the sketch to work.

My question is, do I need the UTFTGLUE myGLCD(0x91 63, A2, A1, A3, A4, A0);. line? It wouldn’t work just with that line without my
UTFT myGLCD(SSD1963_800480,38, 39, 40, 41) line.

What’s it’s purpose please?

2

The constructor arguments are all dummies.
You can use whatever values you like.

UTFTGLUE reads the controller ID from MCUFRIEND_kbv.

MCUFRIEND_kbv uses the bus wiring and control wiring from standard shields. In your case from a special USE_MEGA_16BIT_SHIELD

Since you have an EastRising display and Adapter Shield it probably is a read-write display. However the Bus DIR signal is hardwired to 3.3V on JP3.

If you already have legacy UTFT programs, why do you want to use UTFTGLUE ?
Your Shield should work just fine with UTFT. UTFT has no concept of reading anyway.

Yes, I think you need the digitalWrite(8,HIGH); for the backlight with any library.

David.

3

Thanks for the fast reply. I was looking for a library with more functions which I thought the UTFTGLUE within the MCUFRIEND_kbv library may give. After playing with it on my screen/driver I see that it has exactly the same functions as the UTFT library so there is no advantage in using UTFTGLUE as you have pointed out.

4

You can use MCUFRIEND_kbv as a native GFX library. i.e. with intuitive methods instead of the unusual UTFT style methods.

But for an existing UTFT project you might just as well stick with the library that you know.

David.

5

So the MCUFRIEND_kbv library has the capability to run my SSD1963 board and 800x480 SSD1963 display on the Mega without UTFT or UTFTGLUE libraries?
If so, I’d love to give it a go.

6

I’ve checked out the MCUFRIEND_kbv examples but the touchscreen is the sticking point.
I can’t reconcile the pins between TouchScreen and URTOUCH.
TouchScreen (XP, YP,, XM, YM); vs URTOUCH(tclk, tcs, din, dout, irq).
I can see the PIN numbers for TouchScreen in the button example are 6, A1, A2, 7 (4 pins only) with 300 as a 5th parameter but the URTOUCH pins are 43, 42, 44, 45, 46(5 pins).

Any help would be appreciated.

.

7

O/K. Downloaded the data sheets for the driver board and had a look at the hardware and it would appear that the touch panel is 4 wire and is SPI controlled.
Mega connections are:
MOSI Pin 45
MISO Pin 44
SCLK Pin 43
CS Pin 42
IRQ Pin 46 - many wired examples seem to leave this one not connected but mine is hard wired.
More reading to do so I call it using the pins its connected to on the Mega. A lot of libraries/examples I've looked at have MOSI and MISO preset and apparently can't be changed.

8

First off. Your screen has either got an I2C Capacitive Touch controller or an SPI Resistive Touch controller.
It does not have a bare Resistive Touch Panel.

Looking at the revision A0 version of the schematic.

You can alter SPI pins via solder-bridges J1-J6.
I suggest that you use hardware SPI pins with XPT2046_Touchscreen library that you can install via the IDE Library Manager.
Or you can just bit-bash with URTouch library.

David.

9

Sorry for my poor execution of terminology. I’ll try better in the future.
Upon inspection,the touch screen is a 4 wire resistive panel which is soldered to the TFT panel.
Connections from the driver board to the Arduino Mega are of SPI configuration using the PIN numbers I mentioned earlier going by the information gleaned from page 7 of the TFT LCD Arduino Shield Datasheet; ER-AS- SSD1963 from EastRising. The Jumper pins J11 to J14 ( not J1 to J6) have been soldered to configure the board for the resistive touch screen.
I will download the suggested library and do my best to configure as I love a challenge.

10

I have only looked at the 24-Jun-2015 ER-AS-SSD1963 schematic.

I suggest that you read the appropriate documentation. I don't have this display or this shield. I just printed the schematic and filed a paper copy (some years ago).

I am pretty certain that there will be an XPT2046 SPI Touch controller chip. After all, you were using URTouch beforehand.

I would assume that you have the TFT screen write functions working with MCUFRIEND_kbv. To use any read functions you would need to modify the Adapter Shield hardware.

David.

11

Just pulled it apart again and had a look for the J1 to J6 you mentioned. They are for SPI Hardware or SPI software select. They are soldered for SPI Software select. Unfortunately, according to the pin outs in the documents, the board is not connected to Mega pins 49 to 53 and Pins 50 to 53 are required for hardware SPI.
Looks like I'll have to try and deal with it in hardware as you say, by repinning. Unfortunately, software wise, it seems Megas are locked in software to pins 50 to 53 in the pins_arduino.h file for the Mega.
Keeps me off the streets though :slight_smile:

12

MCUFRIEND-kbv examples working now.
Only problem is, while WHITE and BLACK colours are correct, others are reversed eg BLUE is RED, RED IS BLUE, YELLOW IS CYAN, CYAN IS YELLOW etc.
The invert function doesn’t work as it inverts WHITE and BLACK. as well and they are OK.

13

Edit MCUFRIEND_kbv.cpp from

#if defined(SUPPORT_1963) && USING_16BIT_BUS 
    case 0x1963:
        _lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | READ_NODUMMY | INVERT_SS | INVERT_RGB;

to

#if defined(SUPPORT_1963) && USING_16BIT_BUS 
    case 0x1963:
        _lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | READ_NODUMMY | INVERT_SS;

Which initialisation table are you using? The v2.9.9-Release uses

//        table8_ads = SSD1963_480_regValues, table_size = sizeof(SSD1963_480_regValues);
        table8_ads = SSD1963_800_regValues, table_size = sizeof(SSD1963_800_regValues);
//        table8_ads = SSD1963_NHD_50_regValues, table_size = sizeof(SSD1963_NHD_50_regValues);
//        table8_ads = SSD1963_NHD_70_regValues, table_size = sizeof(SSD1963_NHD_70_regValues);
//        table8_ads = SSD1963_800NEW_regValues, table_size = sizeof(SSD1963_800NEW_regValues);
//        table8_ads = SSD1963_800ALT_regValues, table_size = sizeof(SSD1963_800ALT_regValues);

David.

14

Thanks again for the reply.

The initialisation table was the same as the one you posted (couldn't see a Version number?? but the text was the same as yours)

The first line you posted
"#if defined(SUPPORT_1963) && USING_16BIT_BUS" - mine was missing
" && USING_16BIT_BUS" ie. it read "#if defined(SUPPORT_1963)".
I added the "&& USING_16BIT_BUS" and deleted the "INVERT_RGB" as you suggested.
All colours are now spot on.

Thanks again.

15

I have moved a sketch over from UTFT to UTFTGLUE.
The only change is the constructor.
In the UTFT sketch its UTFT myGLCD(SSD1963_800480,38,39,40,41); It compiles fine and the sketch runs as expected
In the UTFTGLUE sketch its UTFTGLUE myGLCD(SSD1963_800480,38,39,40,41);. It compiles fine and loads but all I have is a white screen.

The example GLUE_demo_ 800x480 does exactly the same thing.

I have tried 0x1963 instead of SSD1963_800480 (which i need to call in tft.begin(0x1963 ) when using MCUFRIEND_kbv.h and Adafruit_GFX.h and not UTFTGLUE btw those sketches work fine) and that doesn't work either.

(Of course, to run the UTFT call so it works means I have to include UTFT.h)

16

Install MUFRIEND_kbv via the IDE Library Manager.
Read the mcufriend_how_to.txt file e.g.

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

Edit graphictest_kbv.ino example sketch setup() from

    if (ID == 0xD3D3) ID = 0x9481; // write-only shield

to

    if (ID == 0xD3D3) ID = 0x1963; // write-only shield

Edit UTFTGLUE.h

         if (ID == 0xD3D3) ID = 0x9090;   //write-only controller HX8357-D

to

         if (ID == 0xD3D3) ID = 0x1963;   //write-only controller SSD1963

The graphictest_kbv.ino edit must be done on every native sketch. i.e. to tell the library to use SSD1963.
The UTFTGLUE.h edit only needs to be done once. All UTFTGLUE sketches will work without any edits. e.g. run the smaller GLUE_Demos

Run graphictest_kbv.ino and report back.
Run GLUE_Demo_800x480.ino and report back.

Please follow my instructions to the letter.

If you have a problem, describe exactly how and what you installed, copy-paste any edits, describe the result.

#12 was an excellent report. e.g. RED-BLUE swap
#14 said that the colours were correct.

#15 is gobbledygook. i.e. copy-paste exactly what you have changed.

David.

17

gobbledygook?? Is this clearer?

Basicallly, I wrote a sketch and used constructor
UTFT myGLCD(SSD1963_800480,38,39,40,41) and it worked.

I changed only the Constructor on the same sketch to UTFTGLUE myGLCD(SSD1963_800480,38,39,40,41) and it didn't work - all I got was a white screen.

I tried UTFTGLUE myGLCD(0x1963,38,39,40,41); and got the same white screen.

Exactly the same thing happened with your 800x480_demo example.

Graphictest_kbv has never been a problem because it doesn't use UTFTGLUE .
That was stated in #15.
All I needed to do in that sketch, as stated in #15, was to use tft.begin(0x1963) as I do in all MCUFRIEND_kbv sketches.

As I stated in #1, I always have to use
PinMode(8,OUTPUT);
digitalWrite(8,HIGH);
to turn the black light on

After making the changes to the UTFTGLE.h file you suggested, I am happy to report that the GLUE_Demo_800x480 sketch now works with only these additions to the sketch.
Constructor now reads UTFTGLUE myGLCD(0x1963,38,39,40,41);

plus the addition of

PinMode(8,OUTPUT);
digitalWrite(8,HIGH);
in the setup()

Thanks for your help David.

18

I have no idea what your sketch says.

Which is why I always ask for people to use the library examples.
Then everyone in the world can see the code.
And you just need to copy-paste the one or two lines that you might have edited.

Of course you could obtain GitHub membership and fork the source code. And then everyone could use the GitHub tools to view your changes.

But quite honestly, it is not difficult to just follow my instructions in #16. And answer any questions e.g.

If UTFT v2.8.3 examples work, just quote example by name and copy-paste the constructor line.
And quite honestly, if you are happy with UTFT why not just stick with UTFT?

David.

19

I answered your questions from #16 by posting the results of the changes you recommended in #17.

I did post the constructor line that worked.

Was there anything in #17 that wasn’t clear that you would like me to explain again?
My questions were about UTFTGLUE. Why mention UTFT examples?

I do have a membership in GitHub.

20

My apologies. I think that I replied before your #17 edits. My Internet is VERY flaky today.

You could have written

UTFTGLUE myGLCD(0, 0, 0, 0, 0); //will work just as well

But you would still need

    pinMode(8, OUTPUT);
    digitalWrite(8, HIGH);

for the backlight in any library.

If you have further problems, you can Fork in GitHub. (delete the library manager installation first)
Then you can post full code and I can create Test Branches.

David.