RA8876 Parallel Display Library Testing

wwatson · Jul 1, 2024

@mjs513 - I cloned a copy of library and will start going through it. Not going to worry about 16Bit mode for now. I'll concentrate on testing everything in 8Bit mode. I'm having to move my storage unit to another one

so I'm kinda bouncing between that and this...

mjs513 · Jul 1, 2024

wwatson said:
@mjs513 - I cloned a copy of library and will start going through it. Not going to worry about 16Bit mode for now. I'll concentrate on testing everything in 8Bit mode. I'm having to move my storage unit to another one so I'm kinda bouncing between that and this...

Thanks expect some annoyances - was getting confusing working with 3 libs - but as I said should get easier

wwatson · Jul 1, 2024

mjs513 said:
Thanks expect some annoyances - was getting confusing working with 3 libs - but as I said should get easier

I had the same headaches when I was duplicating out all of the code for the different boards. Some good news. I have everything working including the ones in "testcases" folder in 8Bit mode and most all of it working 16Bit mode

The biggest issue was missing init code for RA8876 REG[01h] in parallel mode:

Code:

    lcdRegWrite(RA8876_CCR); // 01h
    //  lcdDataWrite(RA8876_PLL_ENABLE<<7|RA8876_WAIT_MASK<<6|RA8876_KEY_SCAN_DISABLE<<5|RA8876_TFT_OUTPUT24<<3

  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);
  }
/*
    lcdRegWrite(RA8876_CCR); // 01h
    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);
*/

So basically you have three options, RA8876_HOST_DATA_BUS_SERIAL, RA8876_HOST_DATA_BUS_8BIT and RA8876_HOST_DATA_BUS_16BIT modes. Also I added the software reset to "ra8876Initialize()". The only other thing that is needed is another define for lets say "USE_SPI" for use in SPI mode. This would also be needed if switching between 8Bit mode and 16Bit mode while running.

Once I finish I will create another branch like yours on my repo, "RA8876_combined" with the changes...

mjs513 · Jul 1, 2024

wwatson said:
I had the same headaches when I was duplicating out all of the code for the different boards. Some good news. I have everything working including the ones in "testcases" folder in 8Bit mode and most all of it working 16Bit mode The biggest issue was missing init code for RA8876 REG[01h] in parallel mode:

Sorry was off doing other things. Hope your moving went well. Knew there had to be something.

wwatson said:
The only other thing that is needed is another define for lets say "USE_SPI" for use in SPI mode.

Basically its already there - probably should rename it. Had to a hack for drawPixel:

Code:

#define use_lcdDataWrite16bbp

Since lcdDataWrite16bpp is only used for drawPixel with Flexio. Probably should rename.

wwatson said:
Once I finish I will create another branch like yours on my repo, "RA8876_combined" with the changes...

Thanks will make it easier to update.

wwatson · Jul 1, 2024

@mjs513 @KurtE - Well all sketches seem to be working now in 8Bit mode and 16Bit mode including the sketches in the "testcases" folder

I done for the day. I found and fixed a few more issues tomorrow I will update RA8876_common on my GitHub after going through all of the examples again in 8/16Bit modes. Hopefully I can also setup the RA8876 SPI display again to test the SPI version of the library. Then I can start in on the Dev board and MicroMod version...

KurtE · Jul 1, 2024

wwatson said:
@mjs513 @KurtE - Well all sketches seem to be working now in 8Bit mode and 16Bit mode including the sketches in the "testcases" folder
I done for the day. I found and fixed a few more issues tomorrow I will update RA8876_common on my GitHub after going through all of the examples again in 8/16Bit modes. Hopefully I can also setup the RA8876 SPI display again to test the SPI version of the library. Then I can start in on the Dev board and MicroMod version...

I have both setup... Bottom 8 bit, top SPI
Was playing today with ILI948x library for T4 and got that one to display. Now trying to decide on if/how to integrate
the integrate first into our combined ILI948x library.

But probably before that, Would like to get this library to work on Micromod with FlexIO2 DMA...

But maybe done for the night

KurtE · Jul 2, 2024

Quick update: have some other stuff going on, so not sure how much I will get done today.
But, I created a new branch:

GitHub - KurtE/Ra8876LiteTeensy at combined_t4x_wip

Teensy RA8876 Driver. Contribute to KurtE/Ra8876LiteTeensy development by creating an account on GitHub.

github.com

So far what I have done, is to create a header file with defaults by board type:
like:

Code:

#if defined(ARDUINO_TEENSY41)
// FlexIO pins: data: 19 18 14 15 40 41 17 16 WR:36 RD:37
//  FlexIO3
#define DISPLAY_WR 36
#define DISPLAY_RD 37

#define DISPLAY_D0 19    // FlexIO3:0 D0
#define DISPLAY_D1 18    // FlexIO3:1 |
#define DISPLAY_D2 14    // FlexIO3:2 |
#define DISPLAY_D3 15    // FlexIO3:3 |
#define DISPLAY_D4 40    // FlexIO3:4 |
#define DISPLAY_D5 41    // FlexIO3:5 |
#define DISPLAY_D6 17    // FlexIO3:6 |
#define DISPLAY_D7 16    // FlexIO3:7 D7

#define DISPLAY_D8 22    // FlexIO3:8 D8
#define DISPLAY_D9 23    // FlexIO3:9  |
#define DISPLAY_D10 20    // FlexIO3:10 |
#define DISPLAY_D11 21    // FlexIO3:11 |
#define DISPLAY_D12 38    // FlexIO3:12 |
#define DISPLAY_D13 39    // FlexIO3:13 |
#define DISPLAY_D14 26    // FlexIO3:14 |
#define DISPLAY_D15 27    // FlexIO3:15 D15

Changed the constructor to save away these values:

Code:

RA8876_t41_p::RA8876_t41_p(const uint8_t DCp, const uint8_t CSp, const uint8_t RSTp)
    : _dc(DCp), _cs(CSp), _rst(RSTp),
      _data_pins{DISPLAY_D0, DISPLAY_D1, DISPLAY_D2, DISPLAY_D3, DISPLAY_D4, DISPLAY_D5, DISPLAY_D6, DISPLAY_D7,
#if defined(DISPLAY_D8)
      DISPLAY_D8, DISPLAY_D9, DISPLAY_D10, DISPLAY_D11, DISPLAY_D12, DISPLAY_D13, DISPLAY_D14, DISPLAY_D15}, _bus_width(BUS_WIDTH),
#else
      0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, _bus_width(8),
#endif     
      _wr_pin(DISPLAY_WR), _rd_pin(DISPLAY_RD)
{
    RA8876_GFX(BUS_WIDTH);
}

I update the method: FASTRUN void RA8876_t41_p::FlexIO_Init() {
To use the pins that are stored in the array and the like. First I figures out which flexio object it is, plus maps the D0, RD, WR
pins to their flexIO pin...

Updated all of the configure functions like: FlexIO_Config_SnglBeat to use the computed flexio pin...
like:
| FLEXIO_SHIFTCTL_PINSEL(_flexio_D0) /* Shifter's pin start index */
and:
| FLEXIO_TIMCTL_PINSEL(_flexio_WR) /* Timer' pin index: WR pin */

Note: not sure how the RD pin was working are thought to work. It had some of the FlexIO stuff commented out, and digitalWriteFast calls to set high or low, but it still had the hard coded flexio RD pin mapping in: FlexIO_Config_SnglBeat_Read

So I copied over the gpioRead/gpioWrite functions from our other library.
And it sets the pin in Flexio or GPIO mode depending on Reads or writes...

I built with this and it still runs. Next up will be to remove where it resets the FlexIO object each time it does something, as well you might have some other FlexIO object on the same Flexio (like maybe a serial), which you probably don't want all of its setting reset all of the time...

I have not tried it yet, but it might actually run now on MicroMod FlexIO2, with the current stuff. Although it would use Interrupts instead of DMA for some of the multi-beat stuff.

Off to do some other stuff

wwatson · Jul 2, 2024

KurtE said:
Quick update: have some other stuff going on, so not sure how much I will get done today.
But, I created a new branch:

GitHub - KurtE/Ra8876LiteTeensy at combined_t4x_wip

Teensy RA8876 Driver. Contribute to KurtE/Ra8876LiteTeensy development by creating an account on GitHub.

github.com

So far what I have done, is to create a header file with defaults by board type:
like:

Code:

#if defined(ARDUINO_TEENSY41) // FlexIO pins: data: 19 18 14 15 40 41 17 16 WR:36 RD:37 // FlexIO3 #define DISPLAY_WR 36 #define DISPLAY_RD 37 #define DISPLAY_D0 19 // FlexIO3:0 D0 #define DISPLAY_D1 18 // FlexIO3:1 | #define DISPLAY_D2 14 // FlexIO3:2 | #define DISPLAY_D3 15 // FlexIO3:3 | #define DISPLAY_D4 40 // FlexIO3:4 | #define DISPLAY_D5 41 // FlexIO3:5 | #define DISPLAY_D6 17 // FlexIO3:6 | #define DISPLAY_D7 16 // FlexIO3:7 D7 #define DISPLAY_D8 22 // FlexIO3:8 D8 #define DISPLAY_D9 23 // FlexIO3:9 | #define DISPLAY_D10 20 // FlexIO3:10 | #define DISPLAY_D11 21 // FlexIO3:11 | #define DISPLAY_D12 38 // FlexIO3:12 | #define DISPLAY_D13 39 // FlexIO3:13 | #define DISPLAY_D14 26 // FlexIO3:14 | #define DISPLAY_D15 27 // FlexIO3:15 D15

Changed the constructor to save away these values:

Code:

RA8876_t41_p::RA8876_t41_p(const uint8_t DCp, const uint8_t CSp, const uint8_t RSTp) : _dc(DCp), _cs(CSp), _rst(RSTp), _data_pins{DISPLAY_D0, DISPLAY_D1, DISPLAY_D2, DISPLAY_D3, DISPLAY_D4, DISPLAY_D5, DISPLAY_D6, DISPLAY_D7, #if defined(DISPLAY_D8) DISPLAY_D8, DISPLAY_D9, DISPLAY_D10, DISPLAY_D11, DISPLAY_D12, DISPLAY_D13, DISPLAY_D14, DISPLAY_D15}, _bus_width(BUS_WIDTH), #else 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff}, _bus_width(8), #endif _wr_pin(DISPLAY_WR), _rd_pin(DISPLAY_RD) { RA8876_GFX(BUS_WIDTH); }

I update the method: FASTRUN void RA8876_t41_p::FlexIO_Init() {
To use the pins that are stored in the array and the like. First I figures out which flexio object it is, plus maps the D0, RD, WR
pins to their flexIO pin...

Updated all of the configure functions like: FlexIO_Config_SnglBeat to use the computed flexio pin...
like:
| FLEXIO_SHIFTCTL_PINSEL(_flexio_D0) /* Shifter's pin start index */
and:
| FLEXIO_TIMCTL_PINSEL(_flexio_WR) /* Timer' pin index: WR pin */

Note: not sure how the RD pin was working are thought to work. It had some of the FlexIO stuff commented out, and digitalWriteFast calls to set high or low, but it still had the hard coded flexio RD pin mapping in: FlexIO_Config_SnglBeat_Read

So I copied over the gpioRead/gpioWrite functions from our other library.
And it sets the pin in Flexio or GPIO mode depending on Reads or writes...

I built with this and it still runs. Next up will be to remove where it resets the FlexIO object each time it does something, as well you might have some other FlexIO object on the same Flexio (like maybe a serial), which you probably don't want all of its setting reset all of the time...

I have not tried it yet, but it might actually run now on MicroMod FlexIO2, with the current stuff. Although it would use Interrupts instead of DMA for some of the multi-beat stuff.

Off to do some other stuff

Very nice, I have been running around this morning chasing down a lost cell phone. Going to have some breakfast and then do the final GitHub update into "RA8876_combined". Will check out your repo...

wwatson · Jul 2, 2024

One last issue with "RA8876_combined" is with "ILI_Ada_FontTest.ino". Font OpenSans24 is not working properly:

The last issue. Will deal with it later. Updating the repo now...

wwatson · Jul 2, 2024

@KurtE - Was just checking out your library in post #82. Unfortunately not all the changes were pushed up so I am going through and adding the remaining change manually. The other issue is the RD signal using FlexIO does not play nice with the RA8876 when reading from display ram. It works reading from registers but not display ram. I fought this for over a month and finally controlled the RD signal manually with digitalWrite() and that works perfect. So some of the examples that don't read from display memory are working. I'll do all of the updates to the library and examples while preserving your changes other than the RD signal...

mjs513 · Jul 2, 2024

wwatson said:
One last issue with "RA8876_combined" is with "ILI_Ada_FontTest.ino". Font OpenSans24 is not working properly:

Strange thats now what I am seeing with my current version (didnt incorporate your changes):

Note: upper screen SPI, lower Flex
FontTest

FontTest4

Sorry been busy most of the day with doctors and plumbers and shopping

EDIT: Just downloaded your changes and now seeing the corruptions you are showing (tested on 8080)

mjs513 · Jul 2, 2024

Looks readRect or writeRect, gradients as well has an issue if you run @KurtE's FB test. Might be read speed as @KurtE mentioned

Top screen SPI; Bottom screen: 8080 on t4.1

now to start looking at deltas

wwatson · Jul 2, 2024

@mjs513 - That is strange. As I mentioned all of the changes I made should be up at:
https://github.com/wwatson4506/Ra8876LiteTeensy/tree/RA8876_combined

I am now working with @KurtE's "combined_t4x_wip" branch. Unfortunately he forked a copy of the other "RA8876_combined" before I had all of the fixs put in. But it should be no problem doing the updates on his branch. The first thing I have to do is change how the RD signal is processed. FlexIO cannot give a RD signal that the RA8876 will accept so need to change it back to manual digitalWrite() usage...

mjs513 · Jul 2, 2024

wwatson said:
@mjs513 - That is strange. As I mentioned all of the changes I made should be up at:
https://github.com/wwatson4506/Ra8876LiteTeensy/tree/RA8876_combined

I am now working with @KurtE's "combined_t4x_wip" branch. Unfortunately he forked a copy of the other "RA8876_combined" before I had all of the fixs put in. But it should be no problem doing the updates on his branch. The first thing I have to do is change how the RD signal is processed. FlexIO cannot give a RD signal that the RA8876 will accept so need to change it back to manual digitalWrite() usage...

Ok just gave @KurtE's wip branch a shot without your changes and fonttest4 works fine!. FB Test - SPI: Works perfect., 8080: looks like issue with readPixel colors are off which may be issue with RD signal. Other than that no issue.

Now back to your library

mjs513 · Jul 2, 2024

@wwatson - @KurtE
Found the problem - buswidth was set to 16 in the library not 8. Used my new setBusWidth command before the begin

Code:

tft.setBusWidth(8);
#if defined(use_spi)
    tft.begin();
#else
    tft.begin(20);
#endif

and all is working again with the updated combined lib (@wwatson version).

Maybe should make that a permanent addition to examples or agree to default to 8 and use the command to change to 16

KurtE · Jul 2, 2024

wwatson said:
@mjs513 - That is strange. As I mentioned all of the changes I made should be up at:
https://github.com/wwatson4506/Ra8876LiteTeensy/tree/RA8876_combined

I know sort-of the chicken and the egg...

That is, don't know what was updated from what @mjs513 branch has:
All of the changes I see up on your fork/branch from what is/was in @mjs513 branch look like:

Probably need to use some winmerge or the like program to compare.

And/or wait until you done with this set of changes and then continue to get it to work on MMOD (and DB4/5 on either FlexIO2 or FlexIO3 or both... Although I only have one such display

wwatson said:
I am now working with @KurtE's "combined_t4x_wip" branch. Unfortunately he forked a copy of the other "RA8876_combined" before I had all of the fixs put in. But it should be no problem doing the updates on his branch. The first thing I have to do is change how the RD signal is processed. FlexIO cannot give a RD signal that the RA8876 will accept so need to change it back to manual digitalWrite() usage..

Sorry, my plans were to have @mjs513 and myself and others such as yourself to check out the changes as compared to the one I forked from.
Then do PR back into @mjs513 fork/branch. And then PR it back to your master fork. Not sure if that would have been master or new branch.

As for digitalWrite usage changes, again not a major thing to change back.
// Simply
uncomment the lines that look like:
//digitalWriteFast(RD_PIN, HIGH); // Set RD pin high manually
And comment out the lines: that look like:
gpioRead(); // write line high, pin 12(rst) as output
or
gpioWrite();

EDIT: I made those changes and pushed it up to my fork/branch

wwatson · Jul 2, 2024

KurtE said:
I know sort-of the chicken and the egg...

That is, don't know what was updated from what @mjs513 branch has:
All of the changes I see up on your fork/branch from what is/was in @mjs513 branch look like:
View attachment 34892
Probably need to use some winmerge or the like program to compare.

And/or wait until you done with this set of changes and then continue to get it to work on MMOD (and DB4/5 on either FlexIO2 or FlexIO3 or both... Although I only have one such display

Sorry, my plans were to have @mjs513 and myself and others such as yourself to check out the changes as compared to the one I forked from.
Then do PR back into @mjs513 fork/branch. And then PR it back to your master fork. Not sure if that would have been master or new branch.

As for digitalWrite usage changes, again not a major thing to change back.
// Simply
uncomment the lines that look like:
//digitalWriteFast(RD_PIN, HIGH); // Set RD pin high manually
And comment out the lines: that look like:
gpioRead(); // write line high, pin 12(rst) as output
or
gpioWrite();

EDIT: I made those changes and pushed it up to my fork/branch

Sorry for the confusion. I'll finish making the needed changes and test. Is there a way to fork a single branch from a repo or do you have to fork the whole repo?

KurtE · Jul 2, 2024

wwatson said:
Sorry for the confusion. I'll finish making the needed changes and test. Is there a way to fork a single branch from a repo or do you have to fork the whole repo?

TNot a problem... Been there done that (many times)...
With the Read issue, looking at Logic Analyzer output, (using digitalWriteFast version), looks sort of strange:

The line with my scribbled arrow in green is the RD pin, the one pointed to by BLUE is the WR pin. Note, that the WR pin is changing state

looks like it is getting pulses on both RD and WR...

wwatson · Jul 2, 2024

KurtE said:
TNot a problem... Been there done that (many times)...
With the Read issue, looking at Logic Analyzer output, (using digitalWriteFast version), looks sort of strange:
View attachment 34897
The line with my scribbled arrow in green is the RD pin, the one pointed to by BLUE is the WR pin. Note, that the WR pin is changing state

looks like it is getting pulses on both RD and WR...

Interesting, that's not what I was getting at first. I'll have to to take a look on my end. The issue was with the multiple pulse RD signal provided by FlexIO:

This is what I was getting with FlexIO. Three RD pulses for one RA8876 read command. Now that I think about it, that WR pulse could be from the gpioRead()/gpioWrite() functions. @Rezo said those are not really necessary and are not in the original working driver. Again I'll hook up my LA and make sure...

KurtE · Jul 2, 2024

Potentially the problem is the timing. That is for example with the ILI9341 and the ILI948x displays,
I know we need to do memory reads at a lower clock speed

In our Parallel ILI948x code,
the FlexIO_Config_SnglBeat_Read() is setup to use a different Clock...
p->TIMCMP[_flexio_timer] =

Code:

(((1 * 2) - 1) << 8)                /* TIMCMP[15:8] = number of beats x 2 – 1 */
        | (((ILI9488_CLOCK_READ) / 2) - 1); /* TIMCMP[7:0] = baud rate divider / 2 – 1 ::: 30 = 8Mhz with current controller speed */

Which we have been experimenting at different clock speeds:

Code:

// #define ILI9488_CLOCK_READ 30   //equates to 8mhz
#define ILI9488_CLOCK_READ 60 // equates to 4mhz
//#define ILI9488_CLOCK_READ 120   //equates to 2mhz

Wonder if we try something like that here as well.

wwatson · Jul 2, 2024

KurtE said:
Potentially the problem is the timing. That is for example with the ILI9341 and the ILI948x displays,
I know we need to do memory reads at a lower clock speed

In our Parallel ILI948x code,
the FlexIO_Config_SnglBeat_Read() is setup to use a different Clock...
p->TIMCMP[_flexio_timer] =

Code:

(((1 * 2) - 1) << 8) /* TIMCMP[15:8] = number of beats x 2 – 1 */ | (((ILI9488_CLOCK_READ) / 2) - 1); /* TIMCMP[7:0] = baud rate divider / 2 – 1 ::: 30 = 8Mhz with current controller speed */

Which we have been experimenting at different clock speeds:

Code:

// #define ILI9488_CLOCK_READ 30 //equates to 8mhz #define ILI9488_CLOCK_READ 60 // equates to 4mhz //#define ILI9488_CLOCK_READ 120 //equates to 2mhz

Wonder if we try something like that here as well.

Already tried that before I believe but it has been quite a while since I played with this. I can setup the test sketch and check it out again. The reads from video memory were were the problem not register reads. When reading from a memory location that had been written to with a 16bit value very rarely returned the correct value. Will check it out tomorrow...

KurtE · Jul 2, 2024

wwatson said:
Already tried that before I believe but it has been quite a while since I played with this. I can setup the test sketch and check it out again. The reads from video memory were were the problem not register reads. When reading from a memory location that had been written to with a 16bit value very rarely returned the correct value. Will check it out tomorrow...

If what you have works… if it ain’t broke don’t fix it…
just curious, I probably need to reread some of the flexio timer section, like when you do a read operation , and the clock signal goes low, how long is the setup time before the pins are sampled…

wwatson · Jul 2, 2024

KurtE said:
If what you have works… if it ain’t broke don’t fix it…
just curious, I probably need to reread some of the flexio timer section, like when you do a read operation , and the clock signal goes low, how long is the setup time before the pins are sampled…

I still am curious as to why there is more than one RD pulse per single read event. I know there is a dummy read with each RD event but I have seen up to 4 RD pulses per RD event. Also the RF says that writing to the config register automatically triggers a RD event as well. So does switching from a read config to a write config trigger a RD/WR pulse? Inquiring minds need to know

And why is the RA8876 only sensitive to FlexIO RD pulses and not WR pulses? Again I played with this problem for almost a month and do not have a real answer to the issue. Just a hack to make it work. Sigh...

wwatson · Jul 3, 2024

@KurtE @mjs513 - Could not leave well enough alone

Went through all of the testing again using the LA and also played more with the shifter baud rate without success.
Filled the screen with 0x0000. Then did:

Code:

  lcd.drawPixel(0x0000,0x0000,0xffff);
  for(i = 0; i < 2; i++) {
  rslt = lcd.getPixel(i,0);
  Serial.printf("rslt = 0x%4.4X\n",rslt);
  }

Result after a few passes through the loop():

Code:

Press anykey to continue
rslt = 0x0000
rslt = 0x0000
Press anykey to continue
rslt = 0x0000
rslt = 0x00FF
Press anykey to continue
rslt = 0x0000
rslt = 0x0000
Press anykey to continue
rslt = 0x0000
rslt = 0x0000
Press anykey to continue
rslt = 0x0000
rslt = 0x00FF
Press anykey to continue

You can see that location 0 16bit read always returns zero and location 1 16bit read is sometimes returning 0x00ff. Same problem as before.
Then just writing 0xffff to location 0x0000 then doing a single 16bit read read of location 0x0000 shows:

Marker 'D' is the dummy read, marker 'E' is the low byte and 'F' is the high byte of the 16 bit read. Notice for each byte all of the RD pulses. It returns 0x0000 instead of 0xffff.
Now, not using FlexIO RD but instead using digitalWrite(), comment out gpioRead /gpioWrite and writing 0xffff to location 0:

Marker 'A' dummy read, marker 'B' low byte and 'C' high byte. 0xffff is returned from location 0.
Result:

Code:

 SDRAM Dev Board and RA8876 parallel 8080 mode testing (8/16)

FlexIO_Init: D0:19 WR:36 RD:37
Bus speed: 20 MHZ
Bus Width: 8-bits
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue
rslt = 0xFFFF
Press anykey to continue

Consistent accurate results from 16bit read of location 0. I'm satisfied for now that using the digitalWrite() method is probably the only and most reliable way to do the video memory reads unless somebody can figure out how to use FlexIO RD reliably.
Sorry for the long post but I had to know that I had not missed something

mjs513 · Jul 3, 2024

wwatson said:
Consistent accurate results from 16bit read of location 0. I'm satisfied for now that using the digitalWrite() method is probably the only and most reliable way to do the video memory reads unless somebody can figure out how to use FlexIO RD reliably.
Sorry for the long post but I had to know that I had not missed something

Inquiring minds want to know

. Was playing a bit more as well this morning, including the clock read speed but no luck (was using @KurtEs version). So as Kurt said - go with what works.

RA8876 Parallel Display Library Testing

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Senior Member+