RA8876 Performance Improvement.

[wwatson]

While working on a driver for the RA8889 10.1" display from Buydisplay that @Rezo brought to my attention, I discovered that there was a way to improve the performance of both RA8876 and RA8889 buy changing some clock settings:

#ifdef USE_FAST_CLOCK_MODE
#define OSC_FREQ    10  // OSC clock frequency, unit: MHz.
#define DRAM_FREQ    166 // 120 // SDRAM clock frequency, unit: MHz. RA8876
#define CORE_FREQ    130 // 120 // Core (system) clock frequency, unit: MHz.
#define SCAN_FREQ    35  // 50  // Panel Scan clock frequency, unit: MHz.
#else
#define OSC_FREQ    10  // OSC clock frequency, unit: MHz.
#define DRAM_FREQ    120 // 120 // SDRAM clock frequency, unit: MHz. RA8876
#define CORE_FREQ    120 // 120 // Core (system) clock frequency, unit: MHz.
#define SCAN_FREQ    50  // 50  // Panel Scan clock frequency, unit: MHz.
#endif

This gives an ~200ms speed improvement. I used the piptest.ino sketch to monitor the loop cycle time. In normal speed mode the loop cycle time is ~730ms and in fast speed mode the loop cycle time is ~530ms. I tested with the 8080 parallel i/f only as I don't have a SPI display setup right now. I might also apply to the SPI version as well. Here is the link to the TeensyRA8876-8080 repo. TeensyRA8876-common repo was not altered. The settings should be safe within the given specs:

/*==== [SW_(1)]  PLL  =====*/
// Crystal resonator for RA8876, suggested 10MHz
// SDRAM access clock,suggested 50~160MHz
// RA8876 system core clock, suggested 50~130MHz
// TFT driving clock PCLK, refer to LCD SPEC specified PCLK frequency requirements
// DRAM_FREQ >= CORE_FREQ   
// CORE_FREQ >= 2 * SCAN_FREQ

Back to the RA8889 . It's not exactly the same as the RA8876 but close

 

[beermat]

On the RA8889, I've gone as high as:

#define OSC_FREQ      10
#define DRAM_FREQ    250
#define CORE_FREQ    210
#define SCAN_FREQ     50

using 8080 16 bit parallel. Improves the speed of the display both with 2D functions and writing to SDRAM, but it still is nowhere close to what I can achieve with the SSD1963, NT35510 and other controllers in 8080 parallel mode.

 

[wwatson]

On the RA8889, I've gone as high as:

#define OSC_FREQ      10
#define DRAM_FREQ    250
#define CORE_FREQ    210
#define SCAN_FREQ     50

using 8080 16 bit parallel. Improves the speed of the display both with 2D functions and writing to SDRAM, but it still is nowhere close to what I can achieve with the SSD1963, NT35510 and other controllers in 8080 parallel mode.

Are those controllers available with a 10.1" display?

 

[beermat]

Hmmm, haven't really looked, but I wouldn't bet money on it, unfortunately.....I haven't looked at every source exhaustively, but when I've been looking at 800*480 resolution, the NT35510 doesn't seem to be present in much larger than 4-5". The SSD1963 is available at 800*480 in 7" from a couple of sources if you like rectangular pixels and non-IPS displays Seems like the physically larger displays at BuyDisplay go with the RA8889......which is frustrating.....it seems like its intended as a controller that can give slow MCUs a faster way to utilize screens, but my hope was, given it is a newer family than all the early 2000s controllers we use, it could also be faster than those using bus access, but sadly not....

 

[wwatson]

Thanks for the reply. I have troubles seeing some of the smaller displays. Thats why I was asking

 

[beermat]

It seems as the years go by, I'm having the same issue

 

[thebigg]

Thanks for this. Unfortunately using these values results in an overflow. It works, but probably not as intended

lib/Ra8876LiteTeensy/src/RA8876_t3.cpp:809:69: warning: unsigned conversion from 'int' to 'ru8' {aka 'unsigned char'} changes value from '264' to '8' [-Woverflow]
 809 | lcdRegDataWrite(0x08,(DRAM_FREQ*16/OSC_FREQ)-1);

 

[thebigg]

Changing

#define DRAM_FREQ    166 // 120 // SDRAM clock frequency, unit: MHz. RA8876

to

#define DRAM_FREQ    160 // 120 // SDRAM clock frequency, unit: MHz. RA8876

gets rid of the compiler warning and still "feels" faster.
Also does not exceed this

// SDRAM access clock,suggested 50~160MHz

 

[wwatson]

Thanks for this. Unfortunately using these values results in an overflow. It works, but probably not as intended

lib/Ra8876LiteTeensy/src/RA8876_t3.cpp:809:69: warning: unsigned conversion from 'int' to 'ru8' {aka 'unsigned char'} changes value from '264' to '8' [-Woverflow]
 809 | lcdRegDataWrite(0x08,(DRAM_FREQ*16/OSC_FREQ)-1);

Thanks for testing. I have not tried it on the Ra8876LiteTeensy library yet but I did run into that error when I set the DRAM frequency to 160 instead of 166. Will have to take a look at the older /Ra8876LiteTeensy library...

 

[wwatson]

Changing

#define DRAM_FREQ    166 // 120 // SDRAM clock frequency, unit: MHz. RA8876

to

#define DRAM_FREQ    160 // 120 // SDRAM clock frequency, unit: MHz. RA8876

gets rid of the compiler warning and still "feels" faster.
Also does not exceed this

// SDRAM access clock,suggested 50~160MHz

HA, you beat me to the post I see that I did not change the DRAM frequency back to 160 before I did the first post. It should be:

#ifdef USE_FAST_CLOCK_MODE
#define OSC_FREQ    10  // OSC clock frequency, unit: MHz.
#define DRAM_FREQ    160 // 120 // SDRAM clock frequency, unit: MHz. RA8876
#define CORE_FREQ    130 // 120 // Core (system) clock frequency, unit: MHz.
#define SCAN_FREQ    35  // 50  // Panel Scan clock frequency, unit: MHz.
#else
#define OSC_FREQ    10  // OSC clock frequency, unit: MHz.
#define DRAM_FREQ    120 // 120 // SDRAM clock frequency, unit: MHz. RA8876
#define CORE_FREQ    120 // 120 // Core (system) clock frequency, unit: MHz.
#define SCAN_FREQ    50  // 50  // Panel Scan clock frequency, unit: MHz.
#endif

Sorry for the confusion...

 

[wwatson]

@thebigg - A quick question. Are you using the SPI interface for your display? That would confirm that the speedups work with the SPI interface...

 

[thebigg]

@wwatson - Yes I'm using SPI. Unfortunately, the above changes have made things unstable (an endless stream of Serial.println("2D ready failed"); ) and I have reverted them. My setup is probably a little unusual in that I have *very long* wires to the screen (>2m) and even with inline resistors to tame the ringing I cannot run reliably with SPI speed above 18MHz. Hope others have better luck with pushing things...

 

[wwatson]

@wwatson - Yes I'm using SPI. Unfortunately, the above changes have made things unstable (an endless stream of Serial.println("2D ready failed"); ) and I have reverted them. My setup is probably a little unusual in that I have *very long* wires to the screen (>2m) and even with inline resistors to tame the ringing I cannot run reliably with SPI speed above 18MHz. Hope others have better luck with pushing things...

I occasionally ran into that problem and made a change to the "check2dBusy()" function that helped. Changed:

for (i = 0; i < 100000; i++) { // Please according to your usage to modify i value.

To:

for (i = 0; i < 1000000; i++) { // Please according to your usage to modify i value.

I think the Ra8876LiteTeensy library version has:

for (i = 0; i < 500000; i++) { // Please according to your usage to modify i value.

You could try 1000000 and see if that helps at all. The long wires are definitely a speed bump. I can get 47MHz with 3" wires but not 50MHz...

 

[Rezo]

My biggest issue with the RA8889 (and previous versions) is they have this wait/busy pin and register indicator, and if you write too fast, the RA/SDRAM can’t handle the speed and it will assert the wait pin until it’s ready.

With polling transfers you can get around this by checking a bool that’s value is changed from an interrupt on the wait pin.
But with DMA transfers, this does not work too well (at all). Trying to stop the transfer and start it again midway does not play nicely.
Quite a shame that such a modern chip is so slow.

I’ve ordered an SSD1963 based display from BuyDisplay and will see how fast of a transfer it can take. Per @beermat testing, the SSD can handle a faster bus speed/data transfer rate than the RA

 

[beermat]

Thanks for this. Unfortunately using these values results in an overflow. It works, but probably not as intended

lib/Ra8876LiteTeensy/src/RA8876_t3.cpp:809:69: warning: unsigned conversion from 'int' to 'ru8' {aka 'unsigned char'} changes value from '264' to '8' [-Woverflow]
 809 | lcdRegDataWrite(0x08,(DRAM_FREQ*16/OSC_FREQ)-1);

It doesn't result in an overflow. That line you get the compiler warning on is guarded by:

else if((DRAM_FREQ>=32)&&(DRAM_FREQ<=39))

so that code will not be executed unless DRAM_FREQ is between 32 and 39 inclusive, so the overflow situation warned about will not happen for higher values of DRAM_FREQ. This part of the code will be executed:

if(DRAM_FREQ>=158)                            //
{
   lcdRegDataWrite(0x07,0x02);                //PLL Divided by 4
   lcdRegDataWrite(0x08,(DRAM_FREQ*2/OSC_FREQ)-1);
}

and that, with OSC_FREQ of 10, can support a DRAM_FREQ of up to 1280 (which the screen cannot ), so you'll be fine - the compiler is warning about a part of code that will overflow if the DRAM_FREQ is a certain value, but it will not be executed if the DRAM_FREQ is above that value.

 

[wwatson]

If interested, I have adapted the RA8876 8080 library to the RA8889. I started off with a T41 with 3" wire leads. Forget it. I could not get any reliable or consistent operation at all. Don't know what the difference is between the RA8876 and RA8889 boards but it is something. Do not have any shorter leads to test with. The DB 5.0 with @KurtE's adapter board seems to work good with the RA8889 display. One thing I noticed is if drop the the 8080 buss speed below 12MHz the display will not work?? Anyway Here are the links to the libraries:
TeensyRa8889-8080
and
TeensyRA8889-GFX-Common

I may take a look at setting up the RA8889's jpeg and AVI decoder functions. Just don't understand why they would only run the decoder from a flash memory chip only?? Oh well...

 

[beermat]

I may take a look at setting up the RA8889's jpeg and AVI decoder functions. Just don't understand why they would only run the decoder from a flash memory chip only?? Oh well...

It's disappointing, right, that they can't play it from SDRAM? I think it's because this screen is meant to be used by really low end MCUs in an end product, so they offer all that acceleration onboard for 2D and the product manufacturer can add a flash chip with any final images/videos they want flashed in the final product. Expecting a low end MCU to be able to push that data over a bus, or even store that data itself to send, is probably too much. I'm thinking kitchen appliance displays, etc that have a nice display with animations but otherwise don't do much

The RA8889 I have was more finicky with wiring than other screens, but I still got it running off 6" wires (16 bit 8080) originally, but that was on the edge. I found that connecting all the grounds on the BuyDisplay model I had helped, but ultimately plugged it into an adapter board I made for testing screens with short PCB traces, probably similar to Kurts harness....