RA8875 library

Status
Not open for further replies.
I got the display to at least power up, but with white colors and they change over time to more black when I set the video mode to 480x272 even though it's a 800x480 display.
Whenever I run test_Initialization sketch it says "RA8875 initialized!" (it even says this when the display is not attached). But the screen is still almost all white and corrupt with black fading in over time. It's like the backlight never turns on.

The display does have "J15 Open,J16 Short: Select Backlight Control Signal with RA8875 'PWM’ " for whatever that's worth.
 
Last edited:
Hi MrTom, I'm still outside my country for work but just get a decent internet connection (even through iphone with just 1 bar signal, sigh), .
The test initialization sketch just test if you are using the right pins of your CPU but cannot access any data inside RA8875 to check if it's correctly inited, I will add a feedback in the future to see if there's almost a reliable link.
Inside RA8875 there's a 2 PWM generators, in adafruit one it's hardware with one of them to turn on display backlight, on buydisplay stuff this is user configurable by jumpers, in your case leave as described above, should be fine.
I will see later how you have connected the display, consider that RA8875 based display looks as dead if are not correctly inited so if you have an 800x480 you should init as RA8875_800x480.
Another issue I got in the past is that some display uses a lot of current when backlight it's on, this happen at the end of initialization and in some case the current it's so high that voltage drops and causes display RA8875 reboot of other unwanted stuff so check if this happen to you (connect a tester and check if the voltage it's constant for all initialization process).
So when you turn on it's all white then turn in black? This means that RA8875 controls with PWM the display as it should so there's a kind of SPI connection working, as I said later I will look how you have connected and see if there's any other issue.
 
Success!

I had to use RA8875 tft = RA8875(RA8875_CS, RA8875_RESET, 7, 14, 8) to set my ALT pins of MOSI=7, SCK=14, MISO=8. I also used CS=20, RESET=2.

If I used the standard RA8875 tft = RA8875(RA8875_CS, RA8875_RESET) in the example program then set alt pins from SPI.set****(#) before tft.begin(RA8875_800x480), it just didn't work.

Now I need to investigate why it's shutting down after a random amount of time. I'm using the 3.3v edge pin from the Teensy to power the display, which I'm assuming is not providing enough current from my USB port through the Teensy to the display. I suppose an external 3.3v source would fix the issue.

EDIT: I've measured the voltage to the display and it's 3.17 volts (within the limit of 3 to 3.6). When the screen goes off the voltage jumps to 3.26, I guess because of no load. I even tried with an 850mA and a 2A USB AC adapter, same thing. Maybe it's just pulling too many amps through the Teensy's 3.3v supply even though it's a 5" LCD and not the power hungry 7".
It looks like the display will draw about 450mA looking at the specs. I'm trying to figure out a way to tap into the supply 5 volts to convert it to 3.3 volts for the display. I tried a voltage divider using 2 resistors, but it seems to draw too much current through the resistor heating it up a lot.
Think I could use this 1117 voltage regulator?
 
Last edited:
The library has it own initialization, set pin before or after begin will not work, there a kind of wiki online, I will promise to write a complete wiki when 1.0 it's out. RA8875 library has tons of commands because RA8875 has tons of features!
About voltage drops, can you take a picture of the back of your display?
Some buydisplay (not all) have a regulator that can be feeded by 5V (by changing JP18) but some models have TFT too large and factory doesn't mount the regulator because it just won't fit.
The backlight of a 5" it's really large (I have some 7" as well that consume really a lot), expecially when driving backlight at full brightness, try use the command tft.brightness(80); after begin to check if goes better, this will drop consume (the backlight will dim of course but it's just for test).
The 1117 regulator should be fine but depends of input supplyl,it's an LDO, easy solution but not really efficent and have a dropout of 1.2V, this mean that your input supply must be at list 4V and not less and going over 5V or LDO cannot provide full current and provide some kind of heatsink. I don't know how much your TFT consume, I have noticed that chinese change TFT from time to time so it's impossible read this data from datasheet (not reliable at all).
Here's a solution that has 90% of efficency pololu
 
Last edited:
That pololu looks great. I bought some of these from amazon. I didn't want to mess with additional caps that they say should be used with the 1117. We'll see how this goes.

Here's a picture of the back of my display.
bdisplay.jpg
 
Last edited:
As you can see at the bottom left should be present a 3 pin LDO regulator (there's a placeholder) but it's missed so your display it's a 3v3 only.
The reason it's the display has bigger connector.
 
Okay, got the 1117s in. Works like a champ. Tapped into my 5 volts and it outputs 3.3. While the display is running, it actually measures about 3.1.

At initial power on when there's still nothing on the display because it's not initialized yet, it draws 200mA. Right when the screen turns on it draws 460mA. Not sure if that will change with full white displayed, as my test is the basicTextFunctions which has a black background with little text.

Measured power draw at the AC outlet for the display and Teensy using a Kill A Watt was 50mA and 2.29 Watts.

The temperature of the 1117 chip without a heatsink was around 46ºC. It's rated at 125ºC.
 
How can you power the LCD screen with external power and still have the Teensy powered from the computer's USB? I'm trying and it doesn't seem to work. The LCD doesn't initialize.
 
what about power teensy externally (by using the 5V you are providing for feeding 1117 regulator) and cut the usb supply pcb trace on teensy?
There's a small trace that Paul provided on the back of Teensy that can be easily resoldered (if you change mind in future)
Why you are getting 3.1V from 1117? It should be 3v3! Have you put a 10uF(minimum) on regulator input (very near regulator terminal) and a 47uF (or 10uF tantalum) on output?
 
Last edited:
what about power teensy externally (by using the 5V you are providing for feeding 1117 regulator) and cut the usb supply pcb trace on teensy?
There's a small trace that Paul provided on the back of Teensy that can be easily resoldered (if you change mind in future)
Why you are getting 3.1V from 1117? It should be 3v3! Have you put a 10uF(minimum) on regulator input (very near regulator terminal) and a 47uF (or 10uF tantalum) on output?

I'm using one of those premade 1117s from the link above, I think it already has caps. I do measure exactly 3.300 volts on the 1117 module output without a load. With the LCD load it does measure about 3.1 - 3.2 volts, which is fine because I believe the minimum for the LCD is 3v.

This all works perfectly okay when I power the Teensy and the 1117 with just an AC to USB power adapter.

I tried taking 5 volts from my 4 pin molex power in the computer and put that to the 1117 which powers the LCD. Then I plug the USB cable from the computer's USB port to the Teensy. I figure it's all the same ground so at least that should help. But it's the same thing. The LCD will power up and initialize sometimes, and the demo runs displaying text & numbers. But then it's like the screen never clears the original text and characters start appearing in random areas. Maybe the reset line isn't functioning.

I can't access the 5v pcb trace because I already have my Teensy mounted on top of the Audio Shield, 28 solder points to remove.

I'll try cutting into a USB extension cable and remove the 5v wire, this way I don't have to damage a USB cable that I use for other purposes. Then I'll power the Teensy and LCD using the AC to USB power adapter which seems to work okay.
 
Hi. Regarding the LPGO fast fonts. Is there a special command I need to use to get fast fonts in 0.70b11? Do I require a font chip? I don't have a font chip.

I modified the basicTextFunctions to loop with no delay, without delay(1) function. I have it loop 99999 times while printing numbers then display the difference in milliseconds.

With version 0.69.65 I get 20524 milliseconds. With version 0.70b11 I get 23016 milliseconds, it's actually printing slower than the older library.
I took out the setTextColor functions and I get 14998 with 0.69.65 and 16678 with 0.70b11.
 
Last edited:
LPGO font are much faster than older render font method, I have done massive testing but are external font and should be rendered as pixels or lines, internal font's are much limited but much faster since are internally handled by RA chip, you can use both in a sketch.
External font chip it's fast too since it uses an RA8875 high speed secondary SPI dedicated line and uses DMA but font are limited to oriental/chinese/exotic font glyphs so are quite useless for me unless you need these languages, I know that one of the external font chip has anglo support but I never tried.
 
Hi. There seems to be a slight bug in the function:
Code:
void RA8875::fillRect(int16_t x, int16_t y, int16_t w, int16_t h, uint16_t color)
{
	//RA8875 it's not out-of-range tolerant so this is a workaround
	if (w < 1 || h < 1) return;//it cannot be!
	if (w < 2 && h < 2){ //render as pixel
		drawPixel(x,y,color);
	} else {			 //render as rect
		_rect_helper(x,y,(x+w)-1,(y+h)-1,color,true);//thanks the experimentalist
	}
}

When I use tft.fillRect(0, 0, 1, 2, RA8875_WHITE) it does not work. But when I use tft.fillRect(10, 10, 1, 2, RA8875_WHITE) it works.

It's because of the line _rect_helper above:
Code:
void RA8875::_rect_helper(int16_t x, int16_t y, int16_t w, int16_t h, uint16_t color, bool filled)
{
	if (w < 1 || h < 1) return;//why draw invisible rects?
	if (w >= _width) return;
	if (h >= _height) return;
	
	if (_portrait) {swapvals(x,y); swapvals(w,h);}

	_checkLimits_helper(x,y);

	if (_textMode) _setTextMode(false);//we are in text mode?
	#if defined(USE_RA8875_SEPARATE_TEXT_COLOR)
		_TXTrecoverColor = true;
	#endif
	if (color != _foreColor) setForegroundColor(color);
	
	_line_addressing(x,y,w,h);

	writeCommand(RA8875_DCR);
	filled == true ? _writeData(0xB0) : _writeData(0x90);
	_waitPoll(RA8875_DCR, RA8875_DCR_LINESQUTRI_STATUS);
}

With the above example that doesn't work it basically sends: _rect_helper(0,0,0,1,color,true). It's sending a width of 0 and gets rejected in _rect_helper because of if (w < 1 || h < 1) return;.

It'll work okay with tft.fillRect(0, 0, 1, 1, RA8875_WHITE) because it ends up using drawPixel(x,y,color).

So whatever the reasoning for the -1 in fillRect, I'd recommend moving it inside _rect_helper so it doesn't return before it gets to draw the rectangle or just altering the boundary check. It looks like it's a problem in drawRect too, and not sure of any other functions since I haven't used them yet.

drawRoundRect & fillRoundRect have the same -1 calling _roundRect_helper, but that function doesn't seem to do any boundary checks like _rect_helper.

EDIT:
Setting if (w < 0 || h < 0) return in _rect_helper did the trick.
 
Last edited:
Ok, this an exception I wasn't consider, thanks to point this. The reason of all those checks is that RA8875 has unpredictable results with out of range data, in this case _rect_helper(0,0,0,1,color,true) you phisically write one pixel by using _rect_helper that uses more parameters than drawPixel so maybe the best approach it's reroute this exception to drawPixel, I will look into this later, thanks again to point me this.
 
Ok, this an exception I wasn't consider, thanks to point this. The reason of all those checks is that RA8875 has unpredictable results with out of range data, in this case _rect_helper(0,0,0,1,color,true) you phisically write one pixel by using _rect_helper that uses more parameters than drawPixel so maybe the best approach it's reroute this exception to drawPixel, I will look into this later, thanks again to point me this.

Well that won't fix it because if you call fillRect(0,0,1,10,color) to draw a rectangle that is 1 pixel by 10 pixels it still will return because it calls _rect_helper(0,0,0,9,color,true) and it will return from code if (w < 1 || h < 1) return because of the -1 that is in _rect_helper(x,y,(x+w)-1,(y+h)-1,color,true).

Because fillRect is sending 0's into _rect_helper, changing the code to if (w < 0 || h < 0) return inside _rect_helper is a fix. I've tested it and it works perfectly with minimal code change. The check is still there because sending a width or height of 0 using fillRect(0, 0, 0, 0, color), if it were to get past the out-of-range check in fillRect, then it would actually call _rect_helper(0,0,-1,-1,color,true) and if (w < 0 || h < 0) return will reject the 0 width or height.
 
Last edited:
Did some interesting speed tests. I found that drawing a Rectangle (as a line) is faster than actually drawing a line.

Code:
  unsigned long TimeTest = millis();
  //  Draw 800 vertical lines 100 times
  for (int t=0; t<100; t++) {
    for (int x=0; x<800; x++)
      tft.drawLine(x, 0, x, 479, RA8875_WHITE);
  }
  Serial.printf("Time = %d\n", millis()-TimeTest);
  TimeTest = millis();
  for (int t=0; t<100; t++) {
    for (int x=0; x<800; x++)
      tft.drawRect(x, 0, 1, 480, RA8875_WHITE);
  }
  Serial.printf("Time = %d\n", millis()-TimeTest);
}

Using an 800x480 LCD:
Drawing 800 vertical lines 100 times using drawLine resulted in 13156 milliseconds. Using drawRect was 8455 milliseconds.
Drawing 480 horizontal lines 100 times using drawLine resulted in 9947 milliseconds. Using drawRect was 5142 milliseconds.
 
Last edited:
Oh well, this is interesting since both macros should be hardware accellerated, btw I have tested as well and surprisily I got the opposite results! I have some RA8875 here so I checked with different ones and the newest one as results very near to yours.
This mean that there's some differences between RA8875's, probably RAiO have updated something (I haved to fight with many hardware bugs during development), I will be surprise if they have finally fixed something so I can get rid of some code workaround.
I'm actually writing a small version detector to check this.
Can you propose a pullup in github for the first issue?
Maybe better continue the discussion for the other things on github since all this is strictly RA8875 and nothing to do with Teensy
 
Hey, I got some code suggestions on the RA8875 library on github. That damn site is too confusing. How do I made a code suggestion? When I try a pull it only asks for a comment.
 
ok, I'm just back but have another plane trip tomorrow, sigh, I'll take a look tomorrow nigh.
 
Okay, I've done a few pull requests. I may have selected build 0.70 for the first pulls. Hopefully you can figure it out and get the changes into the current build 0.70b11?.

I've changed code in, drawLine, one of the circle functions, and _rect_helper.

The whole process is still very confusing. Github is not user friendly to newbies to Github. There's many different areas to select different builds and different ways to select pull requests.

EDIT: I also just edited both drawLineAngle functions to fix lengths and calculations.

Not sure what you're trying to do in drawLineAngle() with if (start - length < 2) {//NEW.
I like the idea of starting a line at a specific point in an angle and going out for a certain length, but I think the IF statement may be wrong in doing that. Maybe if you had only (length < 2) might achieve the goal?
 
Last edited:
I already udpated to 0.70b11p9 with some of your pull suggestions, cannot apply direct pulls because I updated the code a bit and added support for some other MCU.
 
Is it just me or does anyone else get some type of corruption from some of the functions?

Fairly quickly using fillTriangle and fillRect I can get misc corruption from getPixel. And getPixel doesn't even seem to work, it never returns the color on the screen. The corruption comes from getPixel after a while I end up getting random colors and sometimes a stream of colors, like 1C1C or E007 when I'm not even drawing those colors.

I seem to be getting some other corruption too that may be related to trying to draw off screen. I get random vertical green lines in the center of the screen. Not sure if the two issues are related. I may have bad or too long of wires and may be getting corruption on the wires.

Can anyone test this code? With fillTriangle and fillRect I start getting random colors after about 1 minute. The fillCircle can take a lot longer to get corruption. DrawLine does it too eventually, but takes a lot longer.

I have some other code where I'm drawing a lot of triangles really fast and I'm getting some corruption, like vertical lines.


EDIT: Hmm, the speed it takes to start corrupting is related to how close the object is to x,y (0,0). Test each fillRect() below.

Code:
#include <SPI.h>
#include <RA8875.h>

RA8875 tft = RA8875(20, 2, 7, 14, 8);

void setup()
{
  tft.begin(RA8875_800x480);
}

void loop() {
  int i, x, y, color;

  x = tft.width()/2;
  y = tft.height()/2;
  tft.fillTriangle(x,y-50, x+50,y+50, x-50,y+50, RA8875_GREEN);
  //tft.fillRect(x-50,y-50, 100,100, RA8875_GREEN);
  //tft.fillRect(0,0, 100,100, RA8875_GREEN);
  //tft.fillCircle(x,y, 100, RA8875_GREEN);
  //for (i=0; i<100; ++i)
  //  tft.drawLine(x-50,y-50+i, x+50,y-50+i, RA8875_GREEN);

  color = tft.getPixel(x, y);
  if (color)
    Serial.printf("Got a pixel, color = %4X\n", color);
}

With the below code I can reproduce the same vertical line corruption every time because the random function is not using a seed, so it's same with every run and the same colored lines appear. Also getPixel should be returning black all the time since it's reading (0,0), but it's not.

Code:
#include <SPI.h>
#include <RA8875.h>

RA8875 tft = RA8875(20, 2, 7, 14, 8);

void setup()
{
  tft.begin(RA8875_800x480);
}

void loop() {
  int x1, y1, x2, y2, x3, y3, color;

  x1 = random(50, tft.width()-1);
  x2 = random(50, tft.width()-1);
  x3 = random(50, tft.width()-1);
  y1 = random(50, tft.height()-1);
  y2 = random(50, tft.height()-1);
  y3 = random(50, tft.height()-1);

  color = random(RA8875_BLACK, RA8875_WHITE);
  tft.fillTriangle(x1,y1, x2,y2, x3,x3, color);

  color = tft.getPixel(0, 0);
  if (color)
    Serial.printf("Got a pixel, color = %4X\n", color);
}
 
Last edited:
I found an interesting situation where one triangle can corrupt the display with vertical lines. I looks like at this angle it's actually a line and I'm guessing the triangle registers don't like drawing lines.
Change any point by 1 pixel and the corruption goes away. I'm guessing it would be impossible to make a function that can capture every possibility of a line at any given angle.

ickapw.jpg

Code:
#include <SPI.h>
#include <RA8875.h>

RA8875 tft = RA8875(20, 2, 7, 14, 8);

void setup()
{
  tft.begin(RA8875_800x480);
  tft.fillTriangle(393,41, 400,40, 20,94, RA8875_WHITE);
}

void loop() {

}
 
Status
Not open for further replies.
Back
Top