RA8876LiteTeensy For Teensy T36 and T40

@...

I may not look at this for awhile, but as mentioned in last PR for the font test, we avoided using the system font in any other rotation than 0...

But I think in theory it should be supportable in one of the portrait rotations (not sure yet if that is 1 or 3). But if you look at section 14.4 in the RA8876 manual it sort of shows the setting that maybe should support this...

I thought I might have tried this awhile ago. May need to look through this thread again. But for those who want/need the system font. May be something to look at.
 
All
I think i had tried this awhile ago but didn't have much luck in rotating the font. Think it had something to do with mixing and matching TextMode needed to rotate the font and then GraphicMode need to rotate the graphics. Think it was conflicting as as result of active screen dimensions. Maybe if you want to use pip for rotated system font? But think this is more trouble than its worth.
 
@mjs513 - I did a quick and dirty attempt again, and sure enough did not work... So will stay with option 1) Punt
 
Hi. I see that my pull request for the ER-TFTM0874 was backed out. Will you be able to merge it back in now? Or do you need me to update something?

Also, I've been trying to port over a decent-sized ILI9431-based project, working through some issues. The first one is that I've found that putPicture() seems to work fine with rotation(0), but not at rotation(1). Any tips on on making this work?
 
My guess is putPicture maybe only setup to handle rotation 0...

I have never tried/used these, so not sure. Also only just played a little with the one RA8876 I have.

I do know that when we ported the function writeRect to the RA8875 we had to handle portrait mode and sort of walk the image and convert the pixel order to the write order and then we output one row of pixels at a time...

Not sure if this is something we should try porting over for the RA8876. Or if there is other magic already built in to the RA8876 to handle this.
 
Sorry just getting on line again to read what is happening.

As @KurtE said putPicture uses some internal magic. It uses bteMpuWriteWithROPData8 which eventually calls bteMpuWriteWithROP. Looks like the way its set up is that it may destroy the effect of screen rotation that we set up. The only other way is use writeRectangle method which we never ported over to the RA8876.

Have a feeling though if we try to use its built in functions to rotate the image it may destroy any screen rotation stuff that we put in. But would have to play with a test case to see.
 
Hi. I see that my pull request for the ER-TFTM0874 was backed out. Will you be able to merge it back in now? Or do you need me to update something?

Also, I've been trying to port over a decent-sized ILI9431-based project, working through some issues. The first one is that I've found that putPicture() seems to work fine with rotation(0), but not at rotation(1). Any tips on on making this work?

Sorry about the backtrack. I think that maybe I need to create a separate branch for testing with the ER-TFT0784 to keep things pure for us that do not have that particular display. I have downloaded your version of the library and was able to spend some time going through what you did. The main thing I see is in tft.begin() you abstracted displayDimensions(). For me not being a well adjusted c or c++ programmer I only work with what I am learning from you guy's. @KurtE and mjs513 have far better pay scales than me:) I will help where and when I can. I do not have access to your type of display but can test with what I have.

I have two other libraries I am working on so I guess it's just a matter of time and priorities.
 
Hi. I see that my pull request for the ER-TFTM0874 was backed out. Will you be able to merge it back in now? Or do you need me to update something?

Also, I've been trying to port over a decent-sized ILI9431-based project, working through some issues. The first one is that I've found that putPicture() seems to work fine with rotation(0), but not at rotation(1). Any tips on on making this work?

@blackketter - I created a second branch in the Ra8876LiteTeensy repository the link is here:

https://github.com/wwatson4506/Ra8876LiteTeensy/tree/Ra8876LiteTeensy-ER-TFTM0874

Even though I do not have your type of display maybe others that do can test it.
 
@blackketter - I created a second branch in the Ra8876LiteTeensy repository the link is here:

https://github.com/wwatson4506/Ra8876LiteTeensy/tree/Ra8876LiteTeensy-ER-TFTM0874

Even though I do not have your type of display maybe others that do can test it.
Thanks for letting me know. My changes shouldn't break the support for the existing display, except for the removal of some global constants. Have you tried my changes on your display?

If it's working, I think it would be good to keep support for both displays in the main branch and work together from there.
 
Thanks for letting me know. My changes shouldn't break the support for the existing display, except for the removal of some global constants. Have you tried my changes on your display?

If it's working, I think it would be good to keep support for both displays in the main branch and work together from there.

I hope to have time to test this weekend. I am really curious how works on my 10.1" display. As far a rotation with putPicture() goes probably need to study the guru's code before I can even begin to play with it:)
 
I hope to have time to test this weekend. I am really curious how works on my 10.1" display. As far a rotation with putPicture() goes probably need to study the guru's code before I can even begin to play with it:)

The one thing that i noticed and as i have posted, is that when you use any text like the ILI or Adafruit fonts the first text line is shifted up and off the screen, this is especially noticeable when you run the fonttest4. As for graphic elements like rectangles didnt really pay attention. Since I don't have a landscape screen can't really sort out where the issue is.
 
I will try to get around and pull out my RA8876 display and see about a quick and dirty port/test of the draw an image (drawRect) and see if it will work in the 4 orientations.
 
The one thing that i noticed and as i have posted, is that when you use any text like the ILI or Adafruit fonts the first text line is shifted up and off the screen, this is especially noticeable when you run the fonttest4. As for graphic elements like rectangles didnt really pay attention. Since I don't have a landscape screen can't really sort out where the issue is.
Quick update - I updated sources and tried out the font test 4 with the branch Ra8876LiteTeensy-ER-TFTM0874 and it is showing the fonts again going off the top of the screen.

May look at this later.

I may instead go back to master to look at adding the drawing a rect function.
 
@mjs513, @wwatson, @blackketter and ...

I put up a new branch based off of master (https://github.com/KurtE/Ra8876LiteTeensy/tree/writeRect)

Which put in a first pass at a writeRect that may work OK for now. With this I also have a test sketch that shows 3 or 4 images and cycles through the 4 orientations.

Some of this code can/should be cleaned up. Especially rotation 3... But the test sketch appears to work.
Code:
void RA8876_t3::writeRect(int16_t x, int16_t y, int16_t w, int16_t h, const uint16_t *pcolors)
{
	uint16_t start_x = (x != CENTER) ? x : (_width - w) / 2;
	uint16_t start_y = (y != CENTER) ? y : (_height - h) / 2;

	// BUGBUG:: Should check if > this size and do multiple outputs.
	static uint16_t rotated_row[1024]; // max size.


	switch (_rotation) {
		case 0: // we will just hand off for now to 
				// unrolled to bte call
				//Using the BTE function is faster and will use DMA if available
			    bteMpuWriteWithROPData8(currentPage, width(), x, y,  //Source 1 is ignored for ROP 12
                              currentPage, width(), x, y, w, h,     //destination address, pagewidth, x/y, width/height
                              RA8876_BTE_ROP_CODE_12,
                              ( const unsigned char *)pcolors);
			break;
		case 1:
			pcolors += (w - 1);
			for (uint16_t x = start_x + w - 1; x >= start_x; x--) {
				const uint16_t *pimage = pcolors;
				for (uint16_t i = 0; i < h; i++) {
					rotated_row[i] = *pimage;
					pimage += w;
				}
				//Serial.printf("DP %x, %d, %d %d\n", rotated_row, h, start_x, y);
			    bteMpuWriteWithROPData8(currentPage, height(), start_y, x,  //Source 1 is ignored for ROP 12
                              currentPage, height(),  start_y, x, h, 1,     //destination address, pagewidth, x/y, width/height
                              RA8876_BTE_ROP_CODE_12,
                              ( const unsigned char *)rotated_row);
				pcolors--;
			}
			break;
		case 2:
				// unrolled to bte call
				//Using the BTE function is faster and will use DMA if available
				// We reverse the colors in the row...
				while (h) {
					for (int i = (int)w - 1; i >= 0; i--) {
						rotated_row[i] = *pcolors++;
					}
				    bteMpuWriteWithROPData8(currentPage, width(), x, y,  //Source 1 is ignored for ROP 12
                              currentPage, width(), x, y, w, 1,     //destination address, pagewidth, x/y, width/height
                              RA8876_BTE_ROP_CODE_12,
                              ( const unsigned char *)rotated_row);
				    y++;
				    h--;
				}

			break;
		case 3:
			pcolors += (w - 1);
			for (uint16_t x = start_x + w - 1; x >= start_x; x--) {
				const uint16_t *pimage = pcolors;
				for (uint16_t i = 0; i < h; i++) {
					// cleanup..
					rotated_row[h-i-1] = *pimage;
					pimage += w;
				}
				//Serial.printf("DP %x, %d, %d %d\n", rotated_row, h, start_x, y);
			    bteMpuWriteWithROPData8(currentPage, height(), start_y, x,  //Source 1 is ignored for ROP 12
                              currentPage, height(),  start_y, x, h, 1,     //destination address, pagewidth, x/y, width/height
                              RA8876_BTE_ROP_CODE_12,
                              ( const unsigned char *)rotated_row);
				pcolors--;
			}
			break;
	}
}
Rotation 0 is OK, it just calls off to the bte operation. But if you look example at case 1, I call the bte function once per width of the image and I use function without the data and then stuff out the data. This may be good or not, as the data may be output by block text output.


Also code wise:
I see that the code is setup to use the SPI Async transfer code. which is fine. In many cases may not buy us anything. In this case I may hit an issue as I call the bteMpuWriteWithROPData8 and then I call off to start refilling that buffer again, so I could be overwriting memory before it has a chance to be transferred by SPI. Will take a look.
May need to alternate buffers.
 
Thanks, @KurtE! I'll give it a try.

I do see one issue, though, as the max size for all displays is not 1024 (it's 1280 in the ER-TFTM0784) so the size of rotated_row will be an issue. Also, it probably shouldn't be static as that will use up memory even when the function isn't called.
 
writeRect and putPicture are pretty much the same. Just happens we have writeRect in several libraries. In fact the writeRect for rotation 0 is a copy of that function.

Yes the static data needs to change. Could remove static, but then people will complain that the stack usage goes way up when you call it and can crash your program if you run low on memory. So some prefer static as they can see the sizes as part of link... Other options is to malloc it when the function is called and either free it at end of usage or hold on to it. Also at minimum couild define as DMAMEM to in the case of T4.x will put into other memory region...

But as I mentioned, wondering if instead it should simply try to stuff out the words to SPI as it figures out the next ones to output. But just calling SPI.transfer16() would be slower as it waits for the transfer to complete before it completes...

Now in other drivers. we get around this by we actually talk directly to the SPI fifo queue, so we keep feeding it as fast as we can... But then the code has to be different depending on which Teensy is working with it.

I was going to try a couple of experiments to see if I can get this to work better. Starting off with Rotation 1 (rotation 0 is fine).

EDIT: I should also mention that the other rotations are significantly slower than rotation 0...
 
Last edited:
Crazy idea for for saving space and time:

Remove the "const" for the declaration to pcolors, then rotate the data within the source buffer in place, call bteMpuWriteWithROPData8 and then rotate it back.
 
In my case the images are stored in flash memory so they are const...

Still playing around
 
Hi Again,

FYI - I reworked some of the code including the test sketch.

I went ahead and issued a PR as well - It only added functionality so if does not work 100% well it hopefully got most the way there ;)

Anyway I did away with the larger static array. Only in Rotation 2 did a I need a buffer, so I resorted to malloc... There could be an issue with DMA on some machines in this case as I reuse the buffer for each scan line and if the underlying code by chance overwrites the memory before it is output, could cause it maybe not to output correctly. Should probably unplug my T4.1 from the board and try T3.5/6 and see.
Actually find that it won't compile for T3.x... Not related to these changes, but the setup code was setting a variable that is not defined (or used) so commented out the setting and Pushed up fix.

In the other Orientations I output one Row or Column per output. In most of them I could do this without having to copy the data. Just had to order which end am I starting from and work from there.
 
The one thing that i noticed and as i have posted, is that when you use any text like the ILI or Adafruit fonts the first text line is shifted up and off the screen, this is especially noticeable when you run the fonttest4. As for graphic elements like rectangles didnt really pay attention. Since I don't have a landscape screen can't really sort out where the issue is.

I thought I would take a look at this again with the Branch that supports the larger landscape branch to see if I can see what it going on...

So far looking through differences in code, I am seeing some differences that might makes some issues, which I am starting to look at to see if they make a difference, first one not:

First is writeStatusLine: I think there maybe was a merge problem:
Code:
void  RA8876_t3::writeStatusLine(ru16 x0, uint16_t fgcolor, uint16_t bgcolor, const char *str)
{
	[COLOR="#FF0000"]_height = _screenHeight-STATUS_LINE_HEIGHT;[/COLOR]
	
	uint16_t tempX = _cursorX;
	uint16_t tempY = _cursorY;
	uint16_t tempBGColor = _TXTBackColor;
	uint16_t tempFGColor = _TXTForeColor;
	uint8_t tempScaleX = _scaleX;
	uint8_t tempScaleY = _scaleY;
	uint8_t tempFontWidth = _FNTwidth;
	uint8_t tempFontHeight = _FNTheight;
	uint16_t temp_height = _height;
	[COLOR="#FF0000"]_height = _height-STATUS_LINE_HEIGHT;[/COLOR]
The Master code only has the later adjust to _height... Did not effect font test, commenting out the first one...

Next ones I am looking at: Code changed from:
Code:
	currentPage = PAGE1_START_ADDR; // set default screen page address
to:
Code:
	currentPage = pageStartAddress(1); // set default screen page address

Where before we had hard coded start addresses:
Code:
#define PAGE1_START_ADDR  0
#define PAGE2_START_ADDR  1024*600*2   // 1228800 bytes
#define PAGE3_START_ADDR  1024*600*2*2 // 2457600 
#define PAGE4_START_ADDR  1024*600*2*3
#define PAGE5_START_ADDR  1024*600*2*4
#define PAGE6_START_ADDR  1024*600*2*5
#define PAGE7_START_ADDR  1024*600*2*6
#define PAGE8_START_ADDR  1024*600*2*7
#define PAGE9_START_ADDR  1024*600*2*8
#define PAGE10_START_ADDR  1024*600*2*9

#define PATTERN1_RAM_START_ADDR 1024*600*2*10
#define PATTERN2_RAM_START_ADDR (1024*600*2*10)+(16*16*2)
#define PATTERN3_RAM_START_ADDR (1024*600*2*10)+(16*16*2)+(16*16*2)
New code is computed:
Code:
uint32_t RA8876_t3::pageStartAddress(uint8_t pageNumber) {
	return (uint32_t)_screenHeight * _screenWidth * 2 * pageNumber;
}
So looks like the addressing is off by a page:
That is old code: currentPage = 0
is 0

New code: currentPage = 1024*600*2... Will try decrement page number

Then after that wondering about difference in RA8876Registers, like:
XPCLK_INV 1 -> 0
HPW 70 -> 24

VPW 10 -> 2
VND 23 -> 10

Again not sure if any of these will find the visual differences where most of the first line of text is off the screen with the font test on the 1024x600 display
 
@KurtE
Cool that you tracked it down. Had a feeling the big problem was with the Status Line height adjustment. Too busy with other issues. Didn't notice any issue with the timing at least with my display.

Did see that you issued the PRs to @wwatson.
 
As you probably know I pushed up a new branch based off the the 1280x400 branch with the changes I mentioned.

The main thing was all of the settings, were causing the issues of stuff off the screen. The other stuff was sort of superficial like it wasting the first one page of memory and not sure about status text stuff. I did not test out if it effected things or not... Just looked like a merge issue, so I did an update to newer stuff (moved line down farther) and but used the new way to get size...

Anyway would be good for others to try out and if it works maybe merge into that branch and then that branch into master.... Then maybe my other branch that adds writeRect for the 4 orientations, including the two other hacked APIS that allow you to pre-rotate image and then use it where it can all go in one bte operation...
 
Back
Top