RA8875 and SSD1963 controllers

[CrocKlok]

I had a question, I didn't saw them on the list and both are similar and was wondering which driver would work with both screens drivers? because this screens are most of the time are bigger but never test them before. Could you maybe help me with the driver I should select or is it possible to add them to the library? Thank you already.

[Bodmer]

Those controllers are not currently supported. I do not have either of those displays so will not be able to help.

Three files need to be created for a display driver X:

X_Init,h
X_Rotation.h
X_Defines.h

Existing files can be used for reference.

Edits to TFT_eSPI.cpp and User_Setup_Select.h also need to be made where marked with:

<<<<<<<<<<<<<<<<<<<<< ADD NEW DRIVERS TO THE LIST HERE <<<<<<<<<<<<<<<<<<<<<<<

[CrocKlok]

any possible way I can buy a screen and I could test here out if you can create it with help off feedback from me? so far I can see for 7 a 10 inch screen they are cheapest to get with touchscreen or you have any other suggestion for a other version that could also getting cheap? The cheapest was the ssd1963 version for so far I could see.

[Bodmer]

The RA8875 has its own graphics controller so I would not want to make the changes needed to the library for that display.

The ssd1963 should just needs the 3 files above to be created. There are existing libraries that support the ssd1963, if you get one of those working with a display then we are in a good position to port over code from that library to TFT_eSPI.

[CrocKlok]

I will order ssd1963 but it would take some time to get it. particular in this pandamic moments. I will keep it posted when I have one and more info.

[jamesee]

@Bodmer @CrocKlok

I have a SSD1963 TFT LCD. I have been trying to use https://github.com/jscrane/UTFT-Energia/tree/master/tft_drivers/ssd1963 but could not get it to work.

Stephen Crane actually forked and added HW_ESP32_defines.h and HW_ESP32.h to the UTFT libraries (https://github.com/jscrane/UTFT-Energia/tree/master/hardware/esp32). Will this be useful?

Is there anything I can help since I have the SSD1963 LCD?

[Bodmer]

I have added support for SSD1963, please test. Driver define options are here.

[jamesee]

I have added support for SSD1963, please test. Driver define options are here.

@Bodmer Just to confirm whether I should use the 8 bit parallel mode as below?

// Tell the library to use 8 bit parallel mode (otherwise SPI is assumed) //#define TFT_PARALLEL_8_BIT

// The ESP32 and TFT the pins used for testing are: //#define TFT_CS 33 // Chip select control pin (library pulls permanently low //#define TFT_DC 15 // Data Command control pin - must use a pin in the range 0-31 //#define TFT_RST 32 // Reset pin, toggles on startup

//#define TFT_WR 4 // Write strobe control pin - must use a pin in the range 0-31 //#define TFT_RD 2 // Read strobe control pin

//#define TFT_D0 12 // Must use pins in the range 0-31 for the data bus //#define TFT_D1 13 // so a single register write sets/clears all bits. //#define TFT_D2 26 // Pins can be randomly assigned, this does not affect //#define TFT_D3 25 // TFT screen update performance. //#define TFT_D4 17 //#define TFT_D5 16 //#define TFT_D6 27 //#define TFT_D7 14

[Bodmer]

SPI or 8 bit parallel mode should work but I have no way to test.

[CrocKlok]

I am still waiting for the screen otherwise I would test it.

[jamesee]

@Bodmer

I tested using the following pins:-

define SSD1963_480_DRIVER

define TFT_PARALLEL_8_BIT

// The ESP32 and TFT the pins used for testing are:

define TFT_CS 33 // Chip select control pin (library pulls permanently low

define TFT_DC 15 // Data Command control pin - must use a pin in the range 0-31

define TFT_RST 32 // Reset pin, toggles on startup

define TFT_WR 4 // Write strobe control pin - must use a pin in the range 0-31

define TFT_RD 2 // Read strobe control pin

define TFT_D0 12 // Must use pins in the range 0-31 for the data bus

define TFT_D1 13 // so a single register write sets/clears all bits.

define TFT_D2 26 // Pins can be randomly assigned, this does not affect

define TFT_D3 25 // TFT screen update performance.

define TFT_D4 17

define TFT_D5 16

define TFT_D6 27

define TFT_D7 14

I have problem with TFT_DC as my SSD1963 LCD does not have a DC pin. So I wired TFT_DC to the RS pin.

I upload the TFT_graphicstest_one_lib.ino example, and the outcome is as follows:-

[jamesee]

The actual pin mapping on the LCD side is as follows:

//#define TFT_CS CS //#define TFT_DC RS //#define TFT_RST REST

//#define TFT_WR WR //#define TFT_RD RD //#define TFT_D0 DB0 //#define TFT_D1 DB1 //#define TFT_D2 DB2 //#define TFT_D3 DB3 //#define TFT_D4 DB4 //#define TFT_D5 DB5 //#define TFT_D6 DB6 //#define TFT_D7 DB7

[jamesee]

define SSD1963_800_DRIVER

with same pin mapping as above

[jamesee]

define SSD1963_800ALT_DRIVER

[jamesee]

@Bodmer Will the SSD1963controller.pdf manual be useful to you?

SSD1963controller.pdf

[CrocKlok]

I finally receive my screen. What I see there is a color mismatched and text is mirrored. The screen is flipt from left to right mirrored. I have it also configured in 8 bit, I am not sure if it is possible do a SPI configuration for this screen? I have the same screen as jamesee. The rotation function from the code didn't work for me nothing changed it. I didn't try the touchscreen yet.

[jamesee]

@CrocKlok

Did you use the same pins mapping as me?

Did you get the same screen output as above pictures?

[CrocKlok]

@CrocKlok

Did you use the same pins mapping as me?

Did you get the same screen output as above pictures?

Similar result but I can see it was mirrored the screen. I get blue color with the normal 800 and 800alt a yellow color result. but I saw everything that is mirror image left is right and right is left. rotation option doesn't work for the screen yet. I might think it isn't embedded in the code yet for the screen. @Bodmer can you know what the problem here is? @jamesee Yes same pins but I change some DB to other pins from the esp32. and TFT_DC is RS I check the connection from the chip it is connected to DC from the chip.

[sergei-den]

I did a little bit of work on the driver, now almost everything is fine, but I lost the red color ((( I hope to find it soon. Also, at the moment this only works with SSD1963_800_DRIVER new_SSD1963_driver.zip

[CrocKlok]

@SergeiDenis I had same results. but it doesn't make sense for me pixel data interface initials on 9bits instead the 16-bit (565 format) why should this be done ??? Maybe it is better to get it working on 16-bit (565 format) instead 9bits. because it would be more compatible with lib to use. Also you would have later problems with colors again. @Bodmer maybe some input? also with the rotation implementation?

[jamesee]

@SergeiDenis

Confirmed working. Like what you mentioned, the red color is lost (tested using the Color_test.ino)

[Bodmer]

Switching back to 16 bit from 9 bit should fix the colour problem:

  writecommand(0xF0);   //pixel data interface
  writedata(0x03);      //16 bit colour

[CrocKlok]

@Bodmer yeah only problem is screen looks weird. With the 9bit it looks better again. Do we miss something how do you send out the resolution ? also in 16bit 565 format ? otherwise, we need curve use for colors. Also, pin 0 can't be use on the esp32 for me or do I need extra config to use it ? In the meantime I am going try out the touchscreen. Also use the new PDF from ssd1963 they remove option like 3Ah from the configuration in the new chips.

[CrocKlok]

Also, did somebody try out the touchscreen option ? I found out when I uncomment

define TFT_MISO 19

define TFT_MOSI 23

define TFT_SCLK 18

//#define TOUCH_CS 21 // Chip select pin (T_CS) of touch

still, compile till I uncommon the Touch_cs for pin 21. I get problems that error: 'spi' was not declared in this scope.

I wonder if this is also not added yet for the parralel option for the esp32 ? @Bodmer

[CrocKlok]

I might think it has to do with TOUCH_CS 21 is connected with a tft SPI screen. Is possible to add it also use with the parallel option for this screen @Bodmer or that somebody else know how to do that ?

[Bodmer]

The TFT_eSPI library only supports the SPI (XPT2046) touch controller when a SPI interface is used to the TFT. You can use a third party SPI library such as this one.

[CrocKlok]

@Bodmer it has an HR2046 chip it is the same as the XPT2046 chip. problem is when you select an 8bit-parallel option you get the problem when you select an example a screen ili9486 it compiles without any problems and works. So is maybe when you select a parallel option you can't and you get this error. possible also make it available for an 8bit parallel option?

[CrocKlok]

@SergeiDenis you have any new results ? that all colors are correct ?

[sergei-den]

@CrocKlok at the moment, if use 9bit, then we can add lines in SSD1963_Init.h:

      writecommand(0xBC);
      writedata(0x40);
      writedata(0x80);
      writedata(0x40);
      writedata(0x1);

This will give some of red color, but in doing so we get some distortion of all other colors. On 16-bit, no results yet.

[CrocKlok]

I made this one with atmega2560board and the lib UTFT works fine and this one is set with Set Pixel Data Interface parameter F0h with 03h so this 16bit 565 format. All colors works fine. The 800ALT had the right one for me

This is made tft_esp and the Set Pixel Data Interface with 0xF0h parameter on 0x06 that is a 9bit otherwise we don't get any right image. Also I modified command 0xB0 with first parameter on 0x08 to get some red back. This is without the update from @SergeiDenis from his BC code. I have to add F0 and combination from 0x01 has a 12 bit but we have to much red color. The image has 9bit and you can see the background that should be black is brown/red color.

The inverted image has some results but the white is light blue. This one was also made with the TFT_esp color test but inverted mode true.

Problem is color space has a mismatch and I think have to do how the colors send out or converted from tft_esp lib and we need help from @Bodmer otherwise we keep ghost hunting for the setting. Or somebody can port the color sending from the UTFT to TFT_esp would help. Also, the request for adding the XPT2046 for use the parallel is still a question for this. Hoop we can have some help with this.

Here is the option from the colors to send out.

[Bodmer]

Thanks CrocKlok, I understand the problem now. I have had a deeper look at the SSD1963 data sheet and see that the controller is rather unusual compared to the other supported TFT drivers:

1. It does not have a SPI mode, so can only be driven with a parallel bus.
2. It does not accept 16bit 565 colour data with an 8 bit parallel interface.

The init code is a direct copy of that used in UTFT but UTFT presumably uses a 16 bit parallel interface. So, in conclusion, the TFT_eSPI library will need further changes to support the SSD1963:

1. Change the interface mode to 8 bit in the init code:

   writecommand(0xF0);   //pixel data interface
   writedata(0x00);      //8 bit parallel interface

2. Add the capability to send 3 bytes (R+G+B, comprising 6 bit colour in MS 6 bits)

It may take up to 1 week before I can make these changes as I am busy with other (paid for!) work.

[CrocKlok]

Maybe this would be quick dirty trick. because you have it in 16bit 565 format maybe this could help because 2 LSB for the 8 bit are ignored the 'X' in the table D0, D1. we can maybe use this temporary RGB565 to RGB888? I call it a quick and dirty trick to test out. Because the table suggest to have a RGB666 format this way.

Ref. https://gist.github.com/companje/11deb82e807f2cf927b3a0da1646e795

//convert RGB565 to RGB888

byte src[] = loadBytes("ui.bin"); byte dst[] = new byte[src.length/2*3];

for (int i=0, j=0; i<src.length; i+=2) { int c = src[i] + (src[i+1]<<8); byte r = byte(((c & 0xF800) >> 11) << 3); byte g = byte(((c & 0x7E0) >> 5) << 2); byte b = byte(((c & 0x1F)) << 3); dst[j++]=r; dst[j++]=g; dst[j++]=b; } saveBytes("ui.rgb", dst);

size(754,754); println(dst.length); loadPixels(); for (int i=0; i<dst.length-3; ) { char r = char(dst[i++] & 255); char g = char(dst[i++] & 255); char b = char(dst[i++] & 255); pixels[i/3] = color(r, g, b); } updatePixels();

Also I am still wondering why does UTFT have mode in 16 bit 565 instead 8bit mode? because init is on 0xF0 with 0x03.

[Bodmer]

The change to 18 bit colour has been made. New version available for direct download from Github. This is untested by myself, report back if this does/does not work. Thanks.

[CrocKlok]

@Bodmer just to be sure. your saying 18bit color is that also send out in 3bytes from each in 6bits? Till now I try some out. For me no success yet. Still going test some possible ways. -I think I have an image screen again but fuzzy image and mirrored. -Also with setrotation(x) i cant rotated it and changing in init driver also didn't have any impact rotating it.

I am not sure if @SergeiDenis or @jamesee had some results.

[Bodmer]

The table posted above indicates 18 bit colours are needed, 6 bits Red, 6 bits Green and 6 bits Blue, each colour sent out as a byte.

This video and others by John B may help. It is probably just a case of finding the right register values.

Note that the intit file has 3 different init sequences that are used dependant on the driver option used, so make sure you edit the right one.

[CrocKlok]

@Bodmer i know that ;) can tell you I am configuring the right one. Till now still no results. Still busy trying to get at least some text on the screen in a good way and I use the color test for the screen. still blurry screen. Keep posted if I know more.

[jamesee]

I am not sure if @SergeiDenis or @jamesee had some results.

@Bodmer @CrocKlok

I am not getting any good outcome.

I used "#define SSD1963_800_DRIVER" in the User_Setup.h, so I changed the Processors/TFT_eSPI_ESP32.h#L296 to "#if defined (SSD1963_800_DRIVER).

In the SSD1963_Init.h, I changed the rotation command to 0x00 (as per @SergeiDenis setting) writecommand(0x36); //rotation writedata(0x00); //based on Bodmer's setting of 0x2A, it gave an inverse image

writecommand(0xF0); //pixel data interface writedata(0x00);

Attached images are what i got:

[jamesee]

@Bodmer

Is there anyway I can send you a SSD1963 LCD for your testing? I can order from AliExpress and send it to an address of your convenience. Email me at James.ee.developer@gmail.com.

Alternatively I could pay for your ordering of SSD1963 LCD via PayPal.

It will be more productive if you could test the driver code immediately.

[Bodmer]

I came to the same conclusion, it needs some experimentation. I have ordered one of these with a capacitive touch screen. Justification for me is it will be a better size screen for displaying weather forecasts...

I expect it will be a while before it turns up. As I have a purpose for it no payment is needed, but thanks for the offer.

On a closer look I note that John B was getting jagged edges to lines, I have seen this on another display and it was necessary to invert the least significant bit of the row address. Instead of the pixel order being 0,1,2,3,4,5,6,7 etc the pixel order was 1,0,3,2,5,4 etc !!!! The test to use is to try to draw pixels at coords 0,0 and 1,1 and 2,2 and 3,3 and 4,4 These should form a diagonal line. If the row order is odd then the pixels will be drawn at the wrong places. Maybe you can try the in the colour test sketch.

[CrocKlok]

@jamesee which version did you send to the last image ? because I don't get that images with the new one. the older one I had some good images but wrong config from 9bit and color space problems. possible to zip the files that you had ? if it was the older one before the update I have that one the same.

Here some images from the new one but I can't be rotated and if I see the text it is mirrored I change already some parameters without any success. also, I check the youtube video, but he uses 16bit writing instead for us the 8bit.

images are color test program. second line would say white and you can see it is mirrored. blue should be black and red one should be white background ;)

[jamesee]

@jamesee which version did you send to the last image ?

@CrocKlok I used the latest version. I backup my testing version, then git clone the repository again into the libraries folder.

@Bodmer That’s great. Just want to let you know we appreciate your library greatly ...

[Bodmer]

It appears these displays come in a few variants so it may end up being incompatible with some suppliers products. I have a few displays from Buy Display as they are a reliable supplier and identical displays are available for long periods, they also usually provide useful techinical information.

The Buy Display website page includes some software for an 8 bit parallel display. The init code pulled from it is listed below. This will be my starting point when the display I ordered arrives.

This code puts the display in landsape mode, so if you try it then do not include any setRotation() calls in your sketch as that may mess up the settings.

#elif defined (SSD1963_800BD_DRIVER) // Copied from Buy Display code

  writecommand(0xE2);   //PLL multiplier, set PLL clock to 120M
  writedata(0x23);      //N=0x36 for 6.5M, 0x23 for 10M crystal
  writedata(0x02);
  writedata(0x54);
  writecommand(0xE0);   // PLL enable
  writedata(0x01);

  delay(10);

  writecommand(0xE0);
  writedata(0x03);

  delay(10);

  writecommand(0x01);   // software reset

  delay(100);

  writecommand(0xE6);   //PLL setting for PCLK, depends on resolution
  writedata(0x03);
  writedata(0x33);
  writedata(0x33);

  writecommand(0xB0);    //LCD SPECIFICATION
  writedata(0x20);
  writedata(0x00);
  writedata(799 >> 8);   //Set HDP 799
  writedata(799 & 0xFF);
  writedata(479 >> 8);   //Set VDP 479
  writedata(479 & 0xFF);
  writedata(0x00);

  writecommand(0xB4);   //HSYNC
  writedata(0x04);      //Set HT
  writedata(0x1F);
  writedata(0x00);      //Set HPS
  writedata(0xD2);
  writedata(0x00);      //Set HPW
  writedata(0x00);      //Set LPS
  writedata(0x00);
  writedata(0x00);

  writecommand(0xB6);   //VSYNC
  writedata(0x02);    //Set VT
  writedata(0x0C);
  writedata(0x00);    //Set VPS
  writedata(0x22);
  writedata(0x00);    //Set VPW
  writedata(0x00);    //Set FPS
  writedata(0x00);

  writecommand(0xB8);
  writedata(0x0F);      //GPIO3=input, GPIO[2:0]=output
  writedata(0x01);      //GPIO0 normal

  writecommand(0xBA);
  writedata(0x01);    //GPIO[0] out 1 --- LCD display on/off control PIN

  writecommand(0x36);   //rotation
  writedata(0x08);      //set to rotate

  writecommand(0xF0);   //pixel data interface
  writedata(0x00);      //8 bit bus

  writecommand(0xBC);
  writedata(0x40);     //contrast value
  writedata(0x80);     //brightness value
  writedata(0x40);     //saturation value
  writedata(0x01);     //Post Processor Enable

  delay(10);

  writecommand(0x29);   //display on

  writecommand(0xBE);   //set PWM for B/L
  writedata(0x06);
  writedata(0x80);
  writedata(0x01);
  writedata(0xF0);
  writedata(0x00);
  writedata(0x00);

  writecommand(0xD0); 
  writedata(0x0D);  

[Bodmer]

It appears these displays come in a few variants so it may end up being incompatible with some suppliers products. I have a few displays from Buy Display as they are a reliable supplier and identical displays are available for long periods, they also usually provide useful techinical information.

The Buy Display website page includes some software for an 8 bit parallel display. The init code pulled from it is listed below. This will be my starting point when the display I ordered arrives.

This code puts the display in landsape mode, so if you try it then do not include any setRotation() calls in your sketch as that may mess up the settings.

#elif defined (SSD1963_800BD_DRIVER) // Copied from Buy Display code

  writecommand(0xE2);   //PLL multiplier, set PLL clock to 120M
  writedata(0x23);      //N=0x36 for 6.5M, 0x23 for 10M crystal
  writedata(0x02);
  writedata(0x54);
  writecommand(0xE0);   // PLL enable
  writedata(0x01);

  delay(10);

  writecommand(0xE0);
  writedata(0x03);

  delay(10);

  writecommand(0x01);   // software reset

  delay(100);

  writecommand(0xE6);   //PLL setting for PCLK, depends on resolution
  writedata(0x03);
  writedata(0x33);
  writedata(0x33);

  writecommand(0xB0);    //LCD SPECIFICATION
  writedata(0x20);
  writedata(0x00);
  writedata(799 >> 8);   //Set HDP 799
  writedata(799 & 0xFF);
  writedata(479 >> 8);   //Set VDP 479
  writedata(479 & 0xFF);
  writedata(0x00);

  writecommand(0xB4);   //HSYNC
  writedata(0x04);      //Set HT
  writedata(0x1F);
  writedata(0x00);      //Set HPS
  writedata(0xD2);
  writedata(0x00);      //Set HPW
  writedata(0x00);      //Set LPS
  writedata(0x00);
  writedata(0x00);

  writecommand(0xB6);   //VSYNC
  writedata(0x02);    //Set VT
  writedata(0x0C);
  writedata(0x00);    //Set VPS
  writedata(0x22);
  writedata(0x00);    //Set VPW
  writedata(0x00);    //Set FPS
  writedata(0x00);

  writecommand(0xB8);
  writedata(0x0F);      //GPIO3=input, GPIO[2:0]=output
  writedata(0x01);      //GPIO0 normal

  writecommand(0xBA);
  writedata(0x01);    //GPIO[0] out 1 --- LCD display on/off control PIN

  writecommand(0x36);   //rotation
  writedata(0x08);      //set to rotate

  writecommand(0xF0);   //pixel data interface
  writedata(0x00);      //8 bit bus

  writecommand(0xBC);
  writedata(0x40);     //contrast value
  writedata(0x80);     //brightness value
  writedata(0x40);     //saturation value
  writedata(0x01);     //Post Processor Enable

  delay(10);

  writecommand(0x29);   //display on

  writecommand(0xBE);   //set PWM for B/L
  writedata(0x06);
  writedata(0x80);
  writedata(0x01);
  writedata(0xF0);
  writedata(0x00);
  writedata(0x00);

  writecommand(0xD0); 
  writedata(0x0D);  

[jamesee]

@Bodmer

Based on the drive codes from" #elif defined (SSD1963_800BD_DRIVER) // Copied from Buy Display code", with your 18bits color codes in Processor/Processors/TFT_eSPI_ESP32.h, the result is as follows - still cannot get the red color (see "DEADBEEF"):

But if I change the rotation command 0x36 from 0x08 to 0x00 or 0x04 or 0x07, we can get good red color (see "DEADBEEF"); writecommand(0x36); //rotation writedata(0x00); //set to rotate

[jamesee]

@Bodmer

I noticed that after you changed the 18bits color code in Processors/TFT_eSPI_ESP32.h, the text (or font) has some distortion.

Below are a comparison of text with same font same program code BEFORE and AFTER you made the 18bits color changes.

BEFORE: (from SergeiDenis' SDD1963_Init.h) writecommand(0x36); //rotation writedata(0x00); //set to rotate writecommand(0xF0); //pixel data interface writedata(0x06); //9 bit bus

AFTER: writecommand(0x36); //rotation writedata(0x00); //set to rotate writecommand(0xF0); //pixel data interface writedata(0x00); //8 bit bus

[CrocKlok]

Oke I have some better quality images again. It looks like Arduino has to reboot after I replace the TFT_ESP directory. I get good black and white background but text is bad and no colors for me in 8bit mode 0xF0 with 0x00. When I went back to 9bit so 0xF0 with 0x06 for 9bit I get colors again but the background is for black brown and white get light blue. Also text was good and readable with colors. So for me, I am back from the beginning.

[Bodmer]

At the moment the library sends 3 bytes for the 8 bit interface. The Buy Display example code sends 3 buytes for the 8 bit interface so this inicates this part is correct, however there are other settings that presumable need to be changed as well.

If you go back to the previous version of TFT_eSPI, configure for 9 bits as you have before, then add a wire from pin D8 of the display to D7 (so the two pins are driven) you will get a full rang eof colours but there will be intensity steps in a single colour gradient, but that may be sufficient for now so you can start writing code for your project. With a 9 bit interface selected then you will see by reference to Table 7-1 above that you cannot set the most significant bit of the red because the library is not sending out 18 bits, it is sending out 565 colour as 2 bytes.

I think we need to wait now until I get my display. I see that the MCUfriend KBV library by David Prentice appears to support the SSD1963 in 8 bit mode so examination/test with that library may help find the required register settings.

EDIT: It appears Mcufriendkbv only suports a 16 bit interface, so that is not what we want.

[Bodmer]

One option is for me to adapt the library to support a 9 bit bus, this should be quite simple to do. Do you have another GPIO pin free for the display D8 pin? It must be in the GPIO pin range 0-31.

[CrocKlok]

@Bodmer if it is possible for my esp32 pin 0 is free. But I couldn't use it before. maybe you know why. Otherwise next one would be pin 35 or pin34. but this out the range from your info what I remember.

[jamesee]

@Bodmer

support 9-bits is ok for me. I have enough GPIO pins.

based on table 7-1, you need to write 9-bits data twice.

I believe the 9-bits data (actual 8-bits only as we only wired 8 gpio pins) is written once (that is why we could not get red color) with my previous testing with SergeiDenis' SDD1963_Init.h. But at least the text (font) did not distort.

[CrocKlok]

I am also thinking now wouldn't the 9bit be faster with refresh because it sends it in 2 bytes compare with the 3 bytes from the 8 bit ? I am also not sure if the DMA function is possible for this screen it has the connection for it if remember it.