Closed The-Experimentalist closed 9 years ago
Ok, Thanks for reporting this. I'm working hard on this library, in a week I'm pretty sure to release a major update with a lot of speedups. Actually the 6.6Mhz limit of the old SPI code it's breaked and it's over 20Mhz but apart that I have managed to use less calls and send more data at once in some part. I have also ordered 3 weeks ago the same display you are using, now I'm stuck with a 'almost working' 272x480 but should arrive very soon. Since I have changed something in the initialization, can be related to this if you get a blank screen! Try this, replace:
const uint8_t initStrings[4][15] = {
{0x17,0x02,0x03,0x27,0x00,0x05,0x04,0x03,0xEF,0x00,0x05,0x00,0x0E,0x00,0x02},//0 -> 320x240 (0A)
{0x17,0x02,0x82,0x3B,0x00,0x01,0x00,0x05,0x0F,0x01,0x02,0x00,0x07,0x00,0x09},//1 -> 480x272 (10)
{0x17,0x02,0x01,0x4F,0x05,0x0F,0x01,0x00,0xDF,0x01,0x0A,0x00,0x0E,0x00,0x01},//2 -> 640x480
//{0x0B,0x02,0x81,0x63,0x00,0x03,0x03,0x0B,0xDF,0x01,0x1F,0x00,0x16,0x00,0x01}// 3 -> 800x480 (10)
{0x17,0x02,0x81,0x63,0x00,0x03,0x03,0x0B,0xDF,0x01,0x20,0x00,0x16,0x00,0x01} //3 -> 800x480 (fixed?)
};
with
const uint8_t initStrings[4][15] = {
{0x17,0x02,0x03,0x27,0x00,0x05,0x04,0x03,0xEF,0x00,0x05,0x00,0x0E,0x00,0x02},//0 -> 320x240 (0A)
{0x17,0x02,0x82,0x3B,0x00,0x01,0x00,0x05,0x0F,0x01,0x02,0x00,0x07,0x00,0x09},//1 -> 480x272 (10)
{0x17,0x02,0x01,0x4F,0x05,0x0F,0x01,0x00,0xDF,0x01,0x0A,0x00,0x0E,0x00,0x01},//2 -> 640x480
{0x0B,0x02,0x81,0x63,0x00,0x03,0x03,0x0B,0xDF,0x01,0x1F,0x00,0x16,0x00,0x01}// 3 -> 800x480 (10)
//{0x17,0x02,0x81,0x63,0x00,0x03,0x03,0x0B,0xDF,0x01,0x20,0x00,0x16,0x00,0x01} //3 -> 800x480 (fixed?)
};
and set SPI_MULT in RA8875.h from 2.7 to 1
For Layers problem, I'm investigating just now.
After changes, perform a cold boot.
Thanks, I can confirm that with the update you suggest above I do get back to a working screen but I also get back the same issue I have had for all versions after 0.68, it all goes wrong when I call writeTo(L1) as mentioned.
That's something! I confirm my display should arrive this week so I can finally fix the 640x480 and 800x480 init (it really increase the speed a lot). Can you test if changing the multiplier to an higher value you get some speedup? (SPI_MULT to 2 for example should double SPI speed). I'm gonna explore what's wrong with writeTo function right now. The 480x272 works perfect and fast now, I did resolve also the SD compatibility (with the new circuit in wiki) so now works with standard SD and Greyman SD even at fast settings.
Try also this and tell me if something changes: in void RA8875::writeTo( function replace:
uint8_t temp = readReg(RA8875_MWCR1);
to
uint8_t temp = readReg(RA8875_MWCR1);
if ((d == L1 || d == L2) && (_displayType > 0 && _color_bpp > 8)){//[Debug helper]
// if you try to use L1 or L2 with a 640x480 or 800 x 480 at 16 bit resolution
// At this resolution layers are not supported so this function will trigger an error
// to help me debug
setColorBpp(8); //1) try to switch the color depth to a resonable value
useLayers(true);//2) try to set _useMultiLayers = true
}
Can try what you suggest but not expecting any change. If you look at the code above (and below)you can see I already initialise at 8bpp and set useLayers(true).
I have just realised it is not the first call to writeTo(L1) that has the issue. I will follow the code through and then report back with more detail, sorry for the confusion. FYI In the sketch where I am having the issues I am using buffered scrolling, the effective initialisation code:
tft.begin(RA8875_800x480, 8);
if(tft.useLayers(true))
{
Uart.println("Layers successfully enabled");
}
else
{
Uart.println("FAILED TO SET MULTIPLE LAYERS");
}
// Allow 2 layer concatenated scrolling
tft.setScrollMode(BUFFERED);
I just tried another layered sketch where I am only scrolling layer 2 and that is working fine it seems. That uses:
setScrollMode(LAYER2ONLY);
I will update with some more information as soon as I have some, going to try and have a look now.
Got the 800x480 display today. In a few days I will solve the issues with this display and also get a better integration from the capacitive touch. The 480x272 works almost perfect now, fast and 0 issues (until now)
Great, not had a chance to properly get to the bottom of the issues yet but will try and create an example sketch to demo when I do
I'm pretty sure it's about initialization sequence, impossible to fix without the specified hardware so I got the display. I just finish any possible test with 272x480 and works perfect, it init correctly at 8 bit, etc. I've tried to force as 1 layer so the new code forced the card to work at 8 bit, simply perfect. The new code deal as it should with 8 bit colors so there's no visual differences (thanks to the internal hardware 16bit to 8 bit color hardware accellerated and optimized macro). With new code a lot of commands are now useless so it's pretty similar to any other color display (apart the unique features like layers, etc.). I just need some hour of spare time to play with my new display and fix the 800x480 initialization.
The last version works as it should be, I got the same display you have and everithing works perfect, including layers. So the init sequence has not issue, you probably using another SPI device in the same line that it's not SPI transaction compatible or similar, remember that RA8875 use SPI mode 3 and most SPI devices uses SPI mode 0 plus there's some documented problem with pullup resistors.
What little was working for me with 0.69b3 has now stopped working altogether with 0.69b8. When I upload now my screen just goes black.
I had recently found some time to try and understand what it is that breaks my sketch for all versions of your library from 0.69 onwards.
My problems all seem to be related to layers. It all works fine with 0.68 still. My code breaks with 0.69+ as soon as I call writeTo(L1), but as I say at 0.69b8 it just no longer works at all.
I have only spent a few minutes investigating but the following code is in setup. I see the ("8bpp Colour resolution support enabled" message but nothing after: