RA8876 Parallel Display Library Testing

Afternoon all (at least from the east coast). Busy yesterday playing the Propsheild attached to the RA8876 attached to the Devboard 5. It uses we have posted before.

EDIT:
 

Attachments

  • RA8876_PropshieldIMU_Display.zip
    2.3 KB · Views: 20
Last edited:
Good news 24-bit color is working :D
RA8876_24Bit_color.jpg


This is the test sketch which uses some modified functions to generate the screen shown above:


Code:
// RA8876_8080_testing.ino

//#include "images.h"
//#include "Teensy41_Cardlike.h"
//#include "flexio_teensy_mm.c"
//#include "teensy41.c"

#include <RA8876_t41_p.h>

uint8_t dc = 13;
uint8_t cs = 11;
uint8_t rst = 12;

#define BACKLITE 5 //External backlight control connected to this Arduino pin

RA8876_t41_p tft = RA8876_t41_p(dc,cs,rst); //(dc, cs, rst)

uint32_t start = 0;
uint32_t end =  0;
uint8_t busSpeed = 12;
uint8_t rData = 0;
uint16_t  rslt = 0;
uint32_t  rslt32 = 0;

void setup() {
  while (!Serial && millis() < 3000) {} //wait for Serial Monitor
  Serial.printf("%c MicroMod Board and RA8876 parallel 8080 mode testing (8Bit/DMA)\n\n",12);
//  Serial.print(CrashReport);
//  pinMode(WINT, INPUT); // For XnWAIT signal if connected and used.

  // Set 16bit mode
  tft.setBusWidth(16);
  // DB5.0 WR pin, RD pin, D0 pin.
  tft.setFlexIOPins(53,52,40);

  tft.begin(busSpeed);// 20 is working in 8bit and 16bit mode on T41
  delay(100);

  Serial.print("Bus speed: ");
  Serial.print(busSpeed,DEC);
  Serial.println(" MHZ");
  Serial.print("Bus Width: ");
  Serial.print(tft.getBusWidth(),DEC);
  Serial.println("-bits");

  tft.Select_Main_Window_24bpp();

  tft.drawSquareFill24(0,0,1023,599,0x000000);
 
  tft.setFontSize(2);
  tft.drawSquareFill24(10,10,100,100,0xFF0000);
  tft.setTextColor24(RED);
  tft.textxy(0,4);
  tft.print("24-BIT RED");

  tft.drawSquareFill24(210,210,300,300,0x00FF00);
  tft.setTextColor24(GREEN);
  tft.textxy(10,10);
  tft.print("24-BIT GREEN");

  tft.drawSquareFill24(410,410,500,500,0x0000FF);
  tft.setTextColor24(BLUE);
  tft.textxy(23,16);
  tft.print("24-BIT BLUE");
}


void loop() {
  waitforInput();
}

void waitforInput()
{
  Serial.println("Press anykey to continue");
  while (Serial.read() == -1) ;
  while (Serial.read() != -1) ;
}
Changes were made to the "Ra8876Teensy_GFX_Common" library. I only modified functions needed to do this test which was mainly to some of the the RA8876 registers during initialization and then a few others. This is the main one for setting the foreground color. Setting the background color will be the same:
Code:
//**************************************************************//
//**************************************************************//
void RA8876_common::foreGroundColor16bpp(ru16 color, bool finalize) {
    lcdRegDataWrite(RA8876_FGCR, color >> 8, false);    // d2h
    lcdRegDataWrite(RA8876_FGCG, color >> 3, false);    // d3h
    lcdRegDataWrite(RA8876_FGCB, color << 3, finalize); // d4h
}

//**************************************************************//
//            Set 24-bit foreground color.
//**************************************************************//
void RA8876_common::foreGroundColor24bpp(ru32 color, bool finalize) {
    lcdRegDataWrite(RA8876_FGCR, color >> 16, false);    // d2h
    lcdRegDataWrite(RA8876_FGCG, color >> 8, false);    // d3h
    lcdRegDataWrite(RA8876_FGCB, color << 0, finalize); // d4h
}
And part of the initialization portion:
Code:
    lcdRegWrite(RA8876_MACR); // 02h
//    lcdDataWrite(RA8876_DIRECT_WRITE << 6 | RA8876_READ_MEMORY_LRTB << 4 | RA8876_WRITE_MEMORY_LRTB << 1);
    lcdDataWrite(RA8876_MASK_HIGH_BYTE_EVEN_DATA << 6 | RA8876_READ_MEMORY_LRTB << 4 | RA8876_WRITE_MEMORY_LRTB << 1);

    lcdRegWrite(RA8876_ICR); // 03h
    lcdDataWrite(RA8877_LVDS_FORMAT << 3 | RA8876_GRAPHIC_MODE << 2 | RA8876_MEMORY_SELECT_IMAGE);

    lcdRegWrite(RA8876_MPWCTR); // 10h
//    lcdDataWrite(RA8876_PIP1_WINDOW_DISABLE << 7 | RA8876_PIP2_WINDOW_DISABLE << 6 | RA8876_SELECT_CONFIG_PIP1 << 4 | RA8876_IMAGE_COLOCR_DEPTH_16BPP << 2 | TFT_MODE);
    lcdDataWrite(RA8876_PIP1_WINDOW_DISABLE << 7 | RA8876_PIP2_WINDOW_DISABLE << 6 | RA8876_SELECT_CONFIG_PIP1 << 4 | RA8876_IMAGE_COLOCR_DEPTH_24BPP << 2 | TFT_MODE);

    lcdRegWrite(RA8876_PIPCDEP); // 11h
//    lcdDataWrite(RA8876_PIP1_COLOR_DEPTH_16BPP << 2 | RA8876_PIP2_COLOR_DEPTH_16BPP);
    lcdDataWrite(RA8876_PIP1_COLOR_DEPTH_24BPP << 2 | RA8876_PIP2_COLOR_DEPTH_24BPP);

    lcdRegWrite(RA8876_AW_COLOR); // 5Eh
//    lcdDataWrite(RA8876_CANVAS_BLOCK_MODE << 2 | RA8876_CANVAS_COLOR_DEPTH_16BPP);
    lcdDataWrite(RA8876_CANVAS_BLOCK_MODE << 2 | RA8876_CANVAS_COLOR_DEPTH_24BPP);
    
    // RA8876_BTE_COLR - 92h
//    lcdRegDataWrite(RA8876_BTE_COLR, RA8876_S0_COLOR_DEPTH_16BPP << 5 | RA8876_S1_COLOR_DEPTH_16BPP << 2 | RA8876_S0_COLOR_DEPTH_16BPP); // 92h
    lcdRegDataWrite(RA8876_BTE_COLR, RA8876_S0_COLOR_DEPTH_24BPP << 5 | RA8876_S1_COLOR_DEPTH_24BPP << 2 | RA8876_S0_COLOR_DEPTH_24BPP); // 92h
This test only verified using 24-bit color mode with 8/16-bit host bus modes.
Unfortunately everything in this library is based on 16-bit color so most all of the code will have to be changed. Again, do I double the code in this same library or create another copy of the library modify it and name it "RA8876Teensy_32bit_GFX_common"? I am leaning towards the latter. either way it's going to be a lot of work...
 
Unfortunately everything in this library is based on 16-bit color so most all of the code will have to be changed. Again, do I double the code in this same library or create another copy of the library modify it and name it "RA8876Teensy_32bit_GFX_common"? I am leaning towards the latter. either way it's going to be a lot of work...
Would definitely go with the later approach. Will be cleaner and easier to debug if any issues crop up.
 
@KurtE - Did the PR. But I am still having troubles with ILI_ADA_FontTest4 and OpenSans24. With SPI I'm getting this. Second keystroke after boot:
ILI_ADA_FontTest4.jpg

Downloaded your latest SPI and common version just now and got the same results...
 
@KurtE - Did the PR. But I am still having troubles with ILI_ADA_FontTest4 and OpenSans24. With SPI I'm getting this. Second keystroke after boot:

Yep - I saw that, which is why I added the print to know which font it was... Still have not looked at it to fix it...
Not sure if library issue or font issue...
 
Yep - I saw that, which is why I added the print to know which font it was... Still have not looked at it to fix it...
Not sure if library issue or font issue...
It's kind of odd as it is displaying the the characters in the correct size right now using what I have setup for 24-bit color. Just inconsistent color which is a hardware setup issue I think...
 
It's kind of odd as it is displaying the the characters in the correct size right now using what I have setup for 24-bit color. Just inconsistent color which is a hardware setup issue I think...
@mjs513 I am sort-of foggy on this. I believe that this is one of the few instances of Anti-aliased fonts which there is special processing for.

Do you remember much about this?
 
@mjs513 I am sort-of foggy on this. I believe that this is one of the few instances of Anti-aliased fonts which there is special processing for.

Do you remember much
What I remember is that it was a pr to one of the libs that we then propagated through the other libs as we went.

With that said have to hook up the spi ra8876 again and retest. Last time I tested the font4 sketch with ra8876 spi it was all working. Maybe something got lost along the way. But probably won’t be until morning. Pretty much done for the night.
 
Ok found the problem rather quickly to be honest. The issue is with draw pixel in common.
For SPI it has to be:
Rich (BB code):
void RA8876_common::drawPixel(ru16 x, ru16 y, ru16 color) {
    graphicMode(true);
    setPixelCursor(x, y);
    ramAccessPrepare();
    //lcdDataWrite16(color);
    lcdDataWrite(color);
    lcdDataWrite(color >> 8);
//#if defined(use_lcdDataWrite16bbp)
//    lcdDataWrite16bbp(color);
//#endif
}

vs

Rich (BB code):
void RA8876_common::drawPixel(ru16 x, ru16 y, ru16 color) {
    graphicMode(true);
    setPixelCursor(x, y);
    ramAccessPrepare();
    lcdDataWrite16(color);
//    lcdDataWrite(color);
//    lcdDataWrite(color >> 8);
//#if defined(use_lcdDataWrite16bbp)
//    lcdDataWrite16bbp(color);
//#endif
}

Your choice on how you want to differentiate.

EDIT: Maybe be simpler to move drawPixel into each lib instead of gfx?
 
I was going to mention that the colors look different on mine (DB5)
IMG_0687.jpeg


Your choice on how you want to differentiate.

EDIT: Maybe be simpler to move drawPixel into each lib instead of gfx?
I to would probably make that one virtual and each library...
 
Ok found the problem rather quickly to be honest. The issue is with draw pixel in common.
For SPI it has to be:
Rich (BB code):
void RA8876_common::drawPixel(ru16 x, ru16 y, ru16 color) {
    graphicMode(true);
    setPixelCursor(x, y);
    ramAccessPrepare();
    //lcdDataWrite16(color);
    lcdDataWrite(color);
    lcdDataWrite(color >> 8);
//#if defined(use_lcdDataWrite16bbp)
//    lcdDataWrite16bbp(color);
//#endif
}

vs

Rich (BB code):
void RA8876_common::drawPixel(ru16 x, ru16 y, ru16 color) {
    graphicMode(true);
    setPixelCursor(x, y);
    ramAccessPrepare();
    lcdDataWrite16(color);
//    lcdDataWrite(color);
//    lcdDataWrite(color >> 8);
//#if defined(use_lcdDataWrite16bbp)
//    lcdDataWrite16bbp(color);
//#endif
}

Your choice on how you want to differentiate.

EDIT: Maybe be simpler to move drawPixel into each lib instead of gfx?
Awesome :D I'll test here and change the repo...
EDIT: Made the change to TeensyRA8876_SPI and got the same good results as mjs513...
 
I just synced up and built and ran on both 8080(DB5) and SPI(T41) and both are now showing the font correctly. :D

Suggestion: the common library should not have anything like #ifdef USE_SPI.

I think there currently is only one example:
Code:
boolean RA8876_common::ra8876Initialize() {


    // Init PLL
    if (!ra8876PllInitial())
        return false;
    // Init SDRAM
    if (!ra8876SdramInitial())
        return false;


    lcdRegWrite(RA8876_CCR); // 01h


#if defined(USE_SPI)
    lcdDataWrite(RA8876_PLL_ENABLE << 7 | RA8876_WAIT_NO_MASK << 6 | RA8876_KEY_SCAN_DISABLE << 5 | RA8876_TFT_OUTPUT24 << 3 |
     RA8876_I2C_MASTER_DISABLE << 2 | RA8876_SERIAL_IF_ENABLE << 1 | RA8876_HOST_DATA_BUS_SERIAL);
#else
    if(_bus_width == 16) {
        lcdDataWrite(RA8876_PLL_ENABLE<<7|RA8876_WAIT_NO_MASK<<6|RA8876_KEY_SCAN_DISABLE<<5|RA8876_TFT_OUTPUT24<<3
        |RA8876_I2C_MASTER_DISABLE<<2|RA8876_SERIAL_IF_ENABLE<<1|RA8876_HOST_DATA_BUS_16BIT);
    } else {
        lcdDataWrite(RA8876_PLL_ENABLE<<7|RA8876_WAIT_NO_MASK<<6|RA8876_KEY_SCAN_DISABLE<<5|RA8876_TFT_OUTPUT24<<3
        |RA8876_I2C_MASTER_DISABLE<<2|RA8876_SERIAL_IF_ENABLE<<1|RA8876_HOST_DATA_BUS_8BIT);
    }
#endif
...

We should probably add another virtual function to the common class, like setHostBus... or something which the two different
other classes implement with the code in the #if...
 
24-Bit color images are now working using writeRect(), pushPixels16bitAsync() and pushPixels16bitDMA(). Examples using writeRect():
image_2.jpg

and:
image_3.jpg

finally:
Image_1.jpg

These are all 16.7Meg color images that were converted to ".h" files using gimp. Unfortunately there is quite a bit of noise in the pictures. They look really good on the screen. I am getting closer to being done with the library but there are still issues. One is TeensyRA8876_8080 and TeensyRA8876_SPI need to have writeRect(), pushPixels16bitAsync() and pushPixels16bitDMA() changed to use a uint32_t buffer pointer instead of a uint16_t pointer. This would mean duplicating those functions or moving them into the 24-Bit and 16-Bit common files. I Also needed to create 24-Bit color names that matched some of the basic colors used in some of the examples. I have converted and tested some existing examples and they are working. Some will not like images that are based on 16-Bit colors.

I'm getting a little burnt out with this and need to take a break so I'm going to populate @KurtE DB5 shield and fix the DB5 connector,,,
 
Don't blame you - think we all know the feeling!
Yep you can say that again!.

Will be fun to try it.

At some point I was thinking of maybe trying to hack it into the NT35510 code.
Probably in a very limited scope,

Then thought maybe try to adapt the picture viewer to output to it.
For example I believe the JPEGDEC library has an option to output RGB8888 format.
Wonder how well it works and how hard it would be to then adapt that to output. Maybe for the most part
toss the alpha channel...

Likewise on the RA8876...
 
24-Bit color images are now working using writeRect(), pushPixels16bitAsync() and pushPixels16bitDMA(). Examples using writeRect():
Are these changes up on github? Just wondering as might be interesting to see how the images compare to the other displays.
 
Are these changes up on github? Just wondering as might be interesting to see how the images compare to the other displays.
Not yet. Still finishing up. I made some more changes and DMA quit working :( SPI version is going to be really interesting. As it turns out All three libraries have to be changed so that is going to mean three more repo's. Today I will upload what I have for the 8080 parallel version so far for testing. It still is very much unfinished:)
Edit: Just rechecked DMA operation and it is working again. Go figure..
 
Last edited:
Not yet. Still finishing up. I made some more changes and DMA quit working :( SPI version is going to be really interesting. As it turns out All three libraries have to be changed so that is going to mean three more repo's. Today I will upload what I have for the 8080 parallel version so far for testing. It still is very much unfinished:)
Edit: Just rechecked DMA operation and it is working again. Go figure..
No hurry for me, having fun again playing with the GIGA.
 
Way back when in T4 beta testing I had found a Raytracing sketch that ran on Arduino and ESP32 that I used on the T4 with an ILI9341 (https://forum.pjrc.com/index.php?th...-ili9488-on-t3-x-and-beyond.55735/post-210250). See the video of the original (
).

So decided to test on the NT35510 (800x480) and RA8876 (1024x600) 8bit mode. Both took about 3 seconds to render:

NT35510:
1723148883278.png


RA8876:
1723148903502.png


EDIT: Forgot here is the sketch
 

Attachments

  • TFT22_raytrace-240808a.zip
    5.9 KB · Views: 33
Last edited:
Back
Top