RA8876 Parallel Display Library Testing

@KurtE @mjs513 - Finally got back to the 24-Bit color libraries. So far I have the all but TeensyRA8876_SPI converted. With that said, here is the two 24-bit libraries:
https://github.com/wwatson4506/TeensyRA8876-24-Bit-8080
and:
https://github.com/wwatson4506/TeensyRA8876-24-Bit-GFX-Common

Only a few of the examples have been converted to 24-bit color so far. The ones the include 16-Bit images do not work. The ones that use the RA8876 graphics engine should work if converted to 24-Bit color. There is one test sketch in the examples folder ("TeeeensyRa8876_24-Bit_Color_Testing.ino") that does use 24-bit color images. Since GIMP converts 24-Bit jpg files to .h files using a trigraph array you have to use a decoder which is included in the sketch. The downside is you can only process one image at a time right now. I have not had time to explore this further yet. Here is the sketch:
Code:
// TeensyRA8876_24-Bit_testing.ino

#include "RA8876_Config_8080.h"
#include <RA8876_t41_p.h>

//#define BACKLITE 5 //External backlight control connected to this Arduino pin
RA8876_t41_p tft = RA8876_t41_p(RA8876_8080_DC,RA8876_8080_CS,RA8876_8080_RESET);

uint8_t busSpeed = 12;

//*****************************************************************************
// Un-comment one the three  sections here and the corresponding section below.
//*****************************************************************************
/*
#include "parrots.h"
char *pixel1, *data1 = header_data1;
int i1 = width1 * height1;
char *processed_data1 = pixel1 = (char *)malloc(i1 * 4 + 1);
*/
/*
#include "images_1.h"
char *pixel2, *data2 = header_data2;
int i2 = width2 * height2;
char *processed_data2 = pixel2 = (char *)malloc(i2 * 4 + 1);
*/

#include "Original-image-24bit-RGB.h"
char *pixel3, *data3 = header_data3;
int i3 = width3 * height3;
char *processed_data3 = pixel3 = (char *)malloc(i3 * 4 + 1);

//****************************************************************************

// Trigraph to 24-bit RGB decoder
void trigraphDecode(int i, char *pixel, char *data) {
  while(i-- > 0) {
    pixel[0] = ((((data[2] - 33) & 0x3) << 6) | ((data[3] - 33)));
    pixel[1] = ((((data[1] - 33) & 0xF) << 4) | ((data[2] - 33) >> 2));
    pixel[2] = (((data[0] - 33) << 2) | ((data[1] - 33) >> 4));
    pixel[3] = 0;
    data += 4;
    pixel += 4;
  }
}

void setup() {
  while (!Serial && millis() < 3000) {} //wait for Serial Monitor
  Serial.printf("%c MicroMod Board and RA8876 parallel 8080 mode testing (8-Bit/16-BitDMA)\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(RA8876_WR,RA8876_RD,RA8876_D0);
  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.fillScreen(COLOR16M_BLACK);

}

void loop() {
//*******************************************************************************
// Un-comment one of the three sections here and the corresponding section above.
//*******************************************************************************
/*
  trigraphDecode(i1, pixel1, data1);
  tft.writeRect(500,50,width1,height1,(uint32_t *)processed_data1);
//  tft.pushPixels16bitAsync((uint32_t *)processed_data1,10,10,width1,height1); //16-Bit only at this time
//  tft.pushPixels16bitDMA((uint32_t *)processed_data1,0,0,width1,height1);  //16-Bit only at this time
*/
/*
  trigraphDecode(i2, pixel2, data2);
  tft.writeRect(500,50,width2,height2,(uint32_t *)processed_data2);
//  tft.pushPixels16bitAsync((uint32_t *)processed_data2,10,10,width2,height2); //16-Bit only at this time
//  tft.pushPixels16bitDMA((uint32_t *)processed_data2,0,0,width2,height2);  //16-Bit only at this time
*/


  trigraphDecode(i3, pixel3, data3);
  tft.writeRect(500,50,width3,height3,(uint32_t *)processed_data3);
//  tft.pushPixels16bitAsync((uint32_t *)processed_data3,10,10,width3,height3); //16-Bit only at this time
//  tft.pushPixels16bitDMA((uint32_t *)processed_data3,0,0,width3,height3);  //16-Bit only at this time

//*******************************************************************************

  waitforInput();
  tft.setFontSize(2);
  tft.drawSquareFill(10,10,100,100,0xFF0000);
  tft.setTextColor(COLOR16M_RED,COLOR16M_BLACK);
  tft.textxy(0,4);
  tft.print("24-BIT RED");

  tft.drawSquareFill(210,210,300,300,0x00FF00);
  tft.setTextColor(COLOR16M_GREEN);
  tft.textxy(10,10);
  tft.print("24-BIT GREEN");

  tft.drawSquareFill(410,410,500,500,0x0000FF);
  tft.setTextColor(COLOR16M_BLUE);
  tft.textxy(23,16);
  tft.print("24-BIT BLUE");
  waitforInput();
}

void waitforInput()
{
  Serial.println("Press anykey to continue");
  while (Serial.read() == -1) ;
  while (Serial.read() != -1) ;
}
There are two sections, one in setup(0 and one in loop() that have three choices of images. Changing to one of the choices in setup() requires a corresponding change in loop(). I could make that even more confusing you want me to :D Anyway that is were I am at with these libraries so far. There are probably lots of bugs and incomplete code changes. But I thought I would get them put up on GitHub so you guys could test and possibly give me guidance. I'll keep testing here...
EDIT: Forgot to mention that rendering 8-Bit images in DMA or Async modes does not work yet. 16-Bit works good...
 
I have a version now that runs. Note it is held together with bailing wire and spit :D
But included it here if you want to try it.

It can be run with MTP enabled or not. Currently I have it working with image files on SD Card (bmp, jpeg and PNG) PNG decoding is still
temperamental...

You can have an ini file to set some configuration stuff: PictureViewOptions.ini
I don't remember what all they do right now, current on on this SD has
Code:
debug=0
JPGScale=0
Center=1
ImageTimeMS=2000
step=0
PNGScale=-1
BackGround=0xF800

Note the background color is RED (565 format) I convert in the sketch to 888...

It is partially working, in that sometimes I get several pictures that work, like:

IMG_0693.jpeg

And then other times, it will go through sequence of pictures where they are messed up.
IMG_0692.jpeg


And it is not the actual images as next loop it might display fine. When it goes bad, it may stay bad for a while and then recover

EDIT: currently the code is using the decoders and writing all of it out to SDRAM in 32 bit format and then when read in and timing is right
it does a write of the whole thing from SDRAM to the screen...

Next up: up the speed of SDRam currently 166 and see if helps...
Also add option to switch to output directly to the RA8876 code bypassing the intermediate ...

Also check to see if the code used in the other version of this sketch works where I tell it to do each of the writes (tft.useCanvas()/updateScreen) works...
 

Attachments

  • ra8876_tft_picture_view_24bit-240811a.zip
    13 KB · Views: 34
Last edited:
198 appears to have helped :D
But not completely
IMG_1952.jpeg


Turned off using buffer and the fill screen worked to red,but write reacts are screwing up. Was running for awhile and all appeared to be fine

Edit: Updated sketch
 

Attachments

  • ra8876_tft_picture_view_24bit-240811a.zip
    13.2 KB · Views: 34
But not completely
View attachment 35399

Turned off using buffer and the fill screen worked to red,but write reacts are screwing up. Was running for awhile and all appeared to be fine

Edit: Updated sketch
PNG file works:
Ra8876_24bit_png.jpg

But jpeg file seems to missing red colors:
Ra8876_24bit_jpg.jpg

Otherwise it works without having to convert pictures :D Nice...
Edit: Tested with some other jpg files. Some were good and some were not...
 
Last edited:
Nice, I updated it to play with some additional things, like the ability to try to turn on useCanvas. (c command)
it is not working too well yet. Also within canvas I also tried to update using async... Got worse.

Funny, I have much better luck with JPEG files. You might check to see if yours is up to date...
PNG files are a lot more temperamental for me. For example, it does not appear to want to decode PNG files that are created
by the windows snipping tool. I first noticed it when I tried to download an image from one of @mjs513 posts....

If however I then open the file up in Photoshop Elements and save it back as PNG it likes those... I opened up issue on
github... For example it does not like this image:

display_adapters.png

Where I probably should put some stanoffs under the other end of the display :D
 

Attachments

  • ra8876_tft_picture_view_24bit-240811a.zip
    13.4 KB · Views: 34
@KurtE - I'm sure there are a lot more issues with the 24-Bit library to work out. I am still fighting to get 8-Bit 8080 bus to work with 24-Bit color. It's probably something simple that I have not detected yet :) Will keep plugging away at it till I find it. I usually don't give up easy.

Standoffs are good if youo don't run out off them like I do:D
 
@KurtE - I'm sure there are a lot more issues with the 24-Bit library to work out. I am still fighting to get 8-Bit 8080 bus to work with 24-Bit color. It's probably something simple that I have not detected yet :) Will keep plugging away at it till I find it. I usually don't give up easy.

Standoffs are good if youo don't run out off them like I do:D
I will wait until your next drop of stuff, before doing much more with the sketch and playing.

I found some standoffs and actually some screws that fit them…

makes the area look a lot more organized 😆
IMG_0694.jpeg
 
@KurtE @mjs513 - Finally getting somewhere with 8-Bit bus and 24-Bpp but still not quite there yet. This is with Async and 8-Bit bus.
Using the existing pushPixels16bitAsync() function (un-commented part):
Code:
FASTRUN void RA8876_t41_p::pushPixels16bitAsync(const uint32_t *pcolors, uint16_t x1, uint16_t y1, uint16_t x2, uint16_t y2) {
    while (WR_IRQTransferDone == false) {
    } // Wait for any DMA transfers to complete
    uint32_t area = (x2) * (y2);

    graphicMode(true);
    activeWindowXY(x1, y1);
    activeWindowWH(x2, y2);
    setPixelCursor(x1, y1);
    ramAccessPrepare();
/*
    bteMpuWriteWithROPData8(currentPage, width(), x1, y1,  //Source 1 is ignored for ROP 12
                            currentPage, width(), x1, y1, x2, y2,     //destination address, pagewidth, x/y, width/height
                            RA8876_BTE_ROP_CODE_12,
                            ( const uint32_t *)pcolors);
*/
    MulBeatWR_nPrm_IRQ(( const uint32_t *)pcolors, area);
}
Resulted in this 24Bpp picture:
MPU8_24bpp_BAd.jpg

You can see three distinct sections of the same image. Now, using BTE like this:
Code:
FASTRUN void RA8876_t41_p::pushPixels16bitAsync(const uint32_t *pcolors, uint16_t x1, uint16_t y1, uint16_t x2, uint16_t y2) {
    while (WR_IRQTransferDone == false) {
    } // Wait for any DMA transfers to complete
    uint32_t area = (x2) * (y2);
/*
    graphicMode(true);
    activeWindowXY(x1, y1);
    activeWindowWH(x2, y2);
    setPixelCursor(x1, y1);
    ramAccessPrepare();
*/
    bteMpuWriteWithROPData8(currentPage, width(), x1, y1,  //Source 1 is ignored for ROP 12
                            currentPage, width(), x1, y1, x2, y2,     //destination address, pagewidth, x/y, width/height
                            RA8876_BTE_ROP_CODE_12,
                            ( const uint32_t *)pcolors);

    MulBeatWR_nPrm_IRQ(( const uint32_t *)pcolors, area);
}
Results in this:
MPU8_24bpp_better.jpg

Which is better. Still 3 distinct sections. One good two bad. No other code was modified. Been studying the RM and example code I have found. If I switch to 16-Bit bus it fails to load the picture properly which is strange because writeRect() works and it uses BTE for both 8 and 16-Bit bus? Probably has something to do with Async usage? Don't know yet...
 
I have a small issue with rendering an image to the RA8876 using the DB5, DMA, 16-Bit mode and 20MHz or more. Here is the image:
PROGMEM_16Bit_20MHz.jpg

The picture is torn. Now if I copy the image to SDRAM the image turns out like this:
SDRAM_16Bit_20MHz.jpg

Could it be that the access speed of FLASHMEM is to slow? SDRAM works fine even at 24MHz. Here is the sketch:
Code:
// RA8876_8080_testing.ino

#include "RA8876_Config_8080.h"
#include <RA8876_t41_p.h>
//#include "images.h"
//#include "Teensy41_Cardlike.h"
//#include "flexio_teensy_mm.c"
#include "teensy41.c"

RA8876_t41_p tft = RA8876_t41_p(RA8876_8080_DC,RA8876_8080_CS,RA8876_8080_RESET);

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

uint16_t *data1 = (uint16_t *)sdram_malloc(480 * 320 + 1);

void setup() {
  while (!Serial && millis() < 3000) {} //wait for Serial Monitor
//  Serial.print(CrashReport);

  Serial.printf("%cT41/MicroMod/DB5 Board and RA8876 parallel 8080 mode testing (8-Bit/16-Bit)\n\n",12);

  // Set 16bit mode
  tft.setBusWidth(USE_8080_16_BIT_MODE);

  // DB5.0 WR pin, RD pin, D0 pin.
  tft.setFlexIOPins(RA8876_WR,RA8876_RD,RA8876_D0);
 
  // Set bus speed
  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.fillScreen(COLOR65K_BLACK);
  memcpy(data1,teensy41,480*(320 * 2));
}


void loop() {
  start = micros();
//  tft.writeRect(10,280,480,320,(uint16_t *)teensy41); // FLASHMEM buffer
//  tft.writeRect(10,280,480,320,(const uint16_t *)data1); // SDRAM buffer
//  tft.pushPixels16bitAsync(teensy41,0,0,480,320); // FLASHMEM buffer
//  tft.pushPixels16bitAsync((const uint16_t *)data1,0,0,480,320); // SDRAM buffer

//  tft.pushPixels16bitDMA(teensy41,300,150,480,320);    // FLASHMEM buffer BAD
  tft.pushPixels16bitDMA((const uint16_t *)data1,300,150,480,320);  // SDRAM buffer GOOD

  end = micros();
  Serial.printf("Elapsed time: %dus\n",end - start);

  waitforInput();
}

void waitforInput()
{
  Serial.println("Press anykey to continue");
  while (Serial.read() == -1) ;
  while (Serial.read() != -1) ;
}
Any ideas are welcome...
 
Hi again. I was involved earlier and wrote a library for the MicroMod using 8080 with Flexio & DMA & lvgl and checked with the digital analyzer of why we have too much beats and found a solution to manually load the shifters etc... see here: https://github.com/leutholl/TFT0784_mm which stems of https://github.com/wwatson4506/Ra8876LiteTeensy/issues/16

Today I faced a very interesting problem that I'd like to share with you.

My library works when using GCC 5.4.1 which was the teensy package for platformio 4.17.0. Last week, I udpated my build system and that installed teensy package 5 which includes GCC 11.3.1 and guess what happens now: my colors are inverted. But only sometimes and if it is inverted for the whole MultiBeat Flex transfer. After DMA and when I send a new buffer, it's 50%/50% if the buffer is inverted or not. Interestingly, it's not a true inversion as black stays black and white stays white. I strongly believe that the MSB/LSB is messed up during runtime and this could point to a change of memory alignment or cache invalidation but only for GCC 11.3.1.

I was pulling my hair out as this happened together with a new pcb release and I spent a whole day with my scope to check for signal integrity only to find that the bloody GCC is the root cause and the HW is just fine.

I don't know anything more than that - wo while I want to let you know to check your build system, I also might need some help in case you know what that could be.... I don't have a strong history on messing around with the compiler options, so for now, I configure my env for this project to use the older package (platformio can do that, nice!) - this won't be a long term fix though.

PS: I was suspecting the FlexIO_t4 update that came with the same package update, but no, it is the gcc....

PPS: Man, my java days were so much simpler and productive
 
Sorry, but I am also not that familiar with compiler options as well and I have never used PlatformIO so I don't know If I can be if any help here. Maybe others will chime in and help :)
 
Sorry, but I am also not that familiar with compiler options as well and I have never used PlatformIO so I don't know If I can be if any help here. Maybe others will chime in and help :)
Sorry I also don't use PlatformIO. Sometimes I will play a little bit with the compiler options, but just a little bit, normally I leave it at the defaults...

I was pulling my hair out as this happened together with a new pcb release and I spent a whole day with my scope to check for signal integrity only to find that the bloody GCC is the root cause and the HW is just fine.

As for GCC being root cause, hard to say fully. Yes maybe you ran into some new bug, or the like, but could be many other things like:

a) Maybe timing is just borderline working, that is, I am playing with the NT35510 display, and sometimes I see things like this. Then I find depending on configuration, running it at 24mhz speed has problems, but works at 28, and on some does not work at 30... I have not fully traced things out to know why. Sometimes might be wire length or the like. Maybe a timing issue where you need to add or remove a delay when
certain states are changing, like when you apply DC or not DC and similarly CS.

b) Maybe Our setup with FlexIO for the length of the write signal (when the raising and lowering of the signal) as compared to the data signals, may not be within specification of the display. But works most of the time.

c) Maybe the order of and how different objects is initialized changed. There were a lot of changes for the two TD releases where for example we wanted a class, like Hardware Serial port or maybe SPI or ... to be fully initialized, by the compiler, such that it does not rely on the order the constructors are called. That is where different classes have constexpr declared on their constructor. The rules or how the rules were interpreted
on if this worked changed when we updated to newer compiler and again when we changed to C++17 in the next release.

d) you are using external memory of some type, like PSRAM on T4.1 or SDRAM on some other custom boards, and maybe you are hitting
a timing hiccup. With the PSRAM, much improved when we bumped the speed up

Sorry, probably not much help. Other than to say, I have seen similar things.
 
Sorry I also don't use PlatformIO. Sometimes I will play a little bit with the compiler options, but just a little bit, normally I leave it at the defaults...



As for GCC being root cause, hard to say fully. Yes maybe you ran into some new bug, or the like, but could be many other things like:

a) Maybe timing is just borderline working, that is, I am playing with the NT35510 display, and sometimes I see things like this. Then I find depending on configuration, running it at 24mhz speed has problems, but works at 28, and on some does not work at 30... I have not fully traced things out to know why. Sometimes might be wire length or the like. Maybe a timing issue where you need to add or remove a delay when
certain states are changing, like when you apply DC or not DC and similarly CS.

b) Maybe Our setup with FlexIO for the length of the write signal (when the raising and lowering of the signal) as compared to the data signals, may not be within specification of the display. But works most of the time.

c) Maybe the order of and how different objects is initialized changed. There were a lot of changes for the two TD releases where for example we wanted a class, like Hardware Serial port or maybe SPI or ... to be fully initialized, by the compiler, such that it does not rely on the order the constructors are called. That is where different classes have constexpr declared on their constructor. The rules or how the rules were interpreted
on if this worked changed when we updated to newer compiler and again when we changed to C++17 in the next release.

d) you are using external memory of some type, like PSRAM on T4.1 or SDRAM on some other custom boards, and maybe you are hitting
a timing hiccup. With the PSRAM, much improved when we bumped the speed up

Sorry, probably not much help. Other than to say, I have seen similar things.
Thanks KurtE.

I'm not blaming the compiler per se other than the compiler creates the issue for me and I don't have any indication on where my code could be problematic during runtime.... there are no warnings or pointers when compiling.

a) This runs on my 4 layer pcb with quite good signal shapes and not too much of noise. Yes, I can't go over 20Mhz but I suspect that to be the limit of the LCD driver board layout design. I'm chip selecting the lcd all the time - nothing I can use the FlexIO bus for other than the display. DC/RS is of course needed to flip, but it looks good on my scope. 20 MHZ is fast enough for my project anyways.

b) tried all combinations on the pad settings (DSE, SRE, SPEED etc...) not a big change, I'm staying at 20 MHz anyway, and I think the SRE settings begin to improve things at 50Mhz upwards.

c) good point. but wouldn't that be a static problem then? My issue is clock related, as if cache invalidation or memory alignment changes during runtime, sometimes... as if there is an address offset of a byte, which could explain color inversion. The issue looks very hardware-ish, that's why I lost so much time until GCC was making the difference.

d) no external memory on my project ;-) I'm glad I can rule that one out.

thanks for your pointers. How can we analyze the assembler code with C code annotation so that I could diff both executables to maybe find where to look in?!

Again, my project works on the old compiler, I don't have a show stopper. I just wanted to let you know that and if you have seen that as well, be open for suggestion.
 
Going to jump in here. I believe that the current version of the compiler used for Teensyduino 1.59 is 11.3.1. Compiler flags might be different between PlatformIO and Arduino.

You might want to give your code a try using the arduino IDE instead of PlatformIO or try comparing compiler flags between old version and new version. But I would give it a try with the Arduino IDE.

As @KurtE said I don't use PlatformIO so might be an issue on their end.
 
@All - Have updated all examples to use the config file for default or changed defines. Looks like this now:
Code:
/* RA8876_Config_8080.h
 A file to place user defines and configs.
*/

#ifndef RA8876_CONFIG_H
#define RA8876_CONFIG_H

// Select 8 or 16 for your bus width.
#define RA8876_8080_BUS_WIDTH 8

// Set the bus speed in megahertz.
#define BUS_SPEED 20 //Available settings 2,4,8,12,20,24,30,40,60,120

//External backlight control connected to this Arduino pin
// Otherwise 3.3v
//#define BACKLITE 5 or change to your pin of choice

#if defined(ARDUINO_TEENSY41)
// Hardware defines T4.1
#define RA8876_8080_CS 11
#define RA8876_8080_DC 13
#define RA8876_8080_RESET 12
#define RA8876_D0 19
#define RA8876_RD 37    // FlexIO2:19: RD
#define RA8876_WR 36    // FlexIO2:18: WR

#elif defined(ARDUINO_TEENSY_DEVBRD5)
// Hardware defines DB5 board and Kurt's shield or just DB5 board.
#define RA8876_8080_CS 53
#define RA8876_8080_RESET 54
#define RA8876_8080_DC 55
#define RA8876_D0 40
#define BACKLITE 29
#define RA8876_RD 52    // FlexIO3:10: RD
#define RA8876_WR 56    // FlexIO3:11: WR
#endif

// Uncomment to use FT5206 touch.
#define USE_FT5206_TOUCH

#endif // RA8876_CONFIG_H
Default pin definition file looks like this now:
Code:
//=============================================================================
// Default flexio pins - Can be setup for different teensy 4.x boards
//=============================================================================

#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

#elif defined(ARDUINO_TEENSY40)
// BUGBUG Nibble mode
// Will currently fail
#define DISPLAY_RD 20    // FlexIO3:10: RD
#define DISPLAY_WR 21    // FlexIO3:11 WR

#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 17     // FlexIO3:6 |
#define DISPLAY_D5 16     // FlexIO3:7 |
#define DISPLAY_D6 22     // FlexIO3:8 |
#define DISPLAY_D7 23     // FlexIO3:9 D7

#elif defined(ARDUINO_TEENSY_DEVBRD5)
// BUGBUG Nibble mode
// Will currently fail
#define DISPLAY_RD 52    // FlexIO3:10: RD
#define DISPLAY_WR 56    // FlexIO3:11: WR

#define DISPLAY_D0  40  // 40     B0_04   FlexIO2:4
#define DISPLAY_D1  41  // 41     B0_05   FlexIO2:5
#define DISPLAY_D2  42  // 42     B0_06   FlexIO2:6
#define DISPLAY_D3  43  // 43     B0_07   FlexIO2:7
#define DISPLAY_D4  44  // 44     B0_08   FlexIO2:8
#define DISPLAY_D5  45  // 45     B0_09   FlexIO2:9
#define DISPLAY_D6  6   // 6      B0_10   FlexIO2:10
#define DISPLAY_D7  9   // 9      B0_11   FlexIO2:11

#define DISPLAY_D8  32  // 32     B0_12   FlexIO2:12
#define DISPLAY_D9  47  // 47     B0_11   FlexIO2:13
#define DISPLAY_D10 48  // 48     B0_11   FlexIO2:14
#define DISPLAY_D11 49  // 49     B0_11   FlexIO2:15
#define DISPLAY_D12 8   // 8      B1_00   FlexIO2:16
#define DISPLAY_D13 7   // 7      B1_01   FlexIO2:17
#define DISPLAY_D14 50  // 50     B1_02   FlexIO2:18
#define DISPLAY_D15 51  // 51     B1_03   FlexIO2:19


#else // #if defined(ARDUINO_TEENSY_MICROMOD)
// FLEXIO2 pins.

#define DISPLAY_WR 7  // FLEXIO2:17
#define DISPLAY_RD 8 // FLEXIO2:16

#define DISPLAY_D0 40 // 40      B0_04   FlexIO2:4
#define DISPLAY_D1 41 // 41      B0_05   FlexIO2:5
#define DISPLAY_D2 42 // 42      B0_06   FlexIO2:6
#define DISPLAY_D3 43 // 43      B0_07   FlexIO2:7
#define DISPLAY_D4 44 // 44      B0_08   FlexIO2:8
#define DISPLAY_D5 45 // 45      B0_09   FlexIO2:9
#define DISPLAY_D6 6  // 6       B0_10   FlexIO2:10
#define DISPLAY_D7 9  // 9       B0_11   FlexIO2:11
#endif
Added missing defines for the DB5 pins DISPLAY_D8 to DISPLAY_D15.

Here is the basic minimum needed for a sketch:
Code:
/***************************************************************
 * sketch.ino
 *
 ***************************************************************/
#include "Arduino.h"
#include "RA8876_Config_8080.h"
#include <RA8876_t41_p.h>

// RA8876_8080_DC, RA8876_8080_CS and RA8876_8080_RESET are defined in
// src/RA8876_Config_8080.h.
RA8876_t41_p tft = RA8876_t41_p(RA8876_8080_DC,RA8876_8080_CS,RA8876_8080_RESET);


void setup() {
  //I'm guessing most copies of this display are using external PWM
  //backlight control instead of the internal RA8876 PWM.
  //Connect a Teensy pin to pin 14 on the display.
  //Can use analogWrite() but I suggest you increase the PWM frequency first so it doesn't sing.
#if defined(BACKLITE)
  pinMode(BACKLITE, OUTPUT);
  digitalWrite(BACKLITE, HIGH);
#endif

  Serial.begin(115200);
  while (!Serial && millis() < 1000) {} //wait for Serial Monitor

  // Set 8/16bit bus mode. Default is 8bit bus mode.
  tft.setBusWidth(RA8876_8080_BUS_WIDTH); // RA8876_8080_BUS_WIDTH is defined in
                                          // src/RA8876_Config_8080.h.
 
 tft.begin(BUS_SPEED); // RA8876_8080_BUS_WIDTH is defined in
                        // src/RA8876_Config_8080.h. Default is 20MHz.

}

void loop(void) {
  //
}
As per Kurt's suggestion :D Now you do not need to change all of the examples for buss speed or buss width.

Ran into another problem while testing "ILI_Ada_Fontest4.ino". It is the same issue with the OpenSans24 not displayng properly BUT, this time it was when in 16Bit Bus mode not 8Bit bus mode. Here is the fix I made to to drawPixel():
Code:
//**************************************************************//
/* Write a 16bpp pixel                                          */
//**************************************************************//
void RA8876_common::drawPixel(ru16 x, ru16 y, ru16 color) {
    graphicMode(true);
    setPixelCursor(x, y);
    ramAccessPrepare();
    if(_bus_width == 16) {
        lcdDataWrite16(color);
    } else {
        lcdDataWrite(color);
        lcdDataWrite(color >> 8);
    }
//#if defined(use_lcdDataWrite16bbp)
//    lcdDataWrite16bbp(color);
//#endif
}
I haven't quite figured out what the difference is yet, but it is something.
Also haven't figured out why DMA is failing in 16bit bus mode when the bus speed is above 12MHz. This only happens when the source is from FLASHMEM. If I access the source from the DB5 SDRAM it works fine. See post #341.

Going to start on documentation now:( Still learning markdown...
 
Back
Top