BRT Community
General Category => Discussion - EVE => Topic started by: Rudolph on October 29, 2020, 06:07:26 PM
-
As the BT817 / BT818 are officially released now, let's talk about it. :-)
https://github.com/RudolphRiedel/FT800-FT813
These are the new registers:
#define REG_UNDERRUN 0x0030260c
#define REG_AH_CYCLE_MAX 0x00302610
#define REG_PCLK_FREQ 0x00302614
#define REG_PCLK_2X 0x00302618
#define REG_ANIM_ACTIVE 0x0030902C
This are the new commands:
#define CMD_ANIMFRAMERAM 0xFFFFFF6D
#define CMD_ANIMSTARTRAM 0xFFFFFF6E
#define CMD_APILEVEL 0xFFFFFF63
#define CMD_CALIBRATESUB 0xFFFFFF60
#define CMD_CALLLIST 0xFFFFFF67
#define CMD_ENDLIST 0xFFFFFF69
#define CMD_FLASHPROGRAM 0xFFFFFF70
#define CMD_FONTCACHE 0xFFFFFF6B
#define CMD_FONTCACHEQUERY 0xFFFFFF6C
#define CMD_GETIMAGE 0xFFFFFF64
#define CMD_HSF 0xFFFFFF62
#define CMD_LINETIME 0xFFFFFF5E
#define CMD_NEWLIST 0xFFFFFF68
#define CMD_PCLKFREQ 0xFFFFFF6A
#define CMD_RETURN 0xFFFFFF66
#define CMD_RUNANIM 0xFFFFFF6F
#define CMD_TESTCARD 0xFFFFFF61
#define CMD_WAIT 0xFFFFFF65
The first thing to note for me was that the BT817 / BT818 do have a second PLL now for the pixel clock.
The easiest way to setup the second PLL is using CMD_PCLKFREQ.
I have this in my code-library now:
#if EVE_GEN > 3
uint32_t frequency;
#if defined (EVE_PCLK_FREQ)
frequency = EVE_cmd_pclkfreq(EVE_PCLK_FREQ, 0);
if(frequency == 0) /* this failed for some reason so we return with an error */
{
return 0;
}
#endif
#endif
EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD panel */
EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD panel */
Note, EVE_PCLK has to be defined to "1" to use PLL2.
With a define like this:
#define EVE_PCLK_FREQ (51000000L)
The resulting pixel-clock is 51MHz and the 1024x600 display I configured this for runs at 60Hz.:-)
What also got my attention is CMD_NEWLIST, CMD_ENDLIST, CMD_RETURN and CMD_CALLLIST.
Looks like we can expand display list now. :-)
And now I go on reading. :-)
-
The new programming manual states for CMD_GETPROPS:
"ptr
Source address of bitmap. (At API level 1, after loading a PNG image this field contains the
first unused location after the bitmap) ."
I thought this must be an error in the documentation and this should read "API level 2".
Also I wondered why this would be limited to PNG images.
But as it turns out, it is limited to PNG images and it works as described.
JPG image, API level 1 or level 2: cmd_getprops() returns the start of the image
PNG image, API level 1: cmd_getprops() returns the first address after the image
PNG image, API level 2: cmd_getprops() returns the start of the image
So I tested this with a BT815 and I would never have guessed it, the behaviour of the cmd_getprops() in the BT817 is actually consistent with the behaviour of the BT815, even though the programming manuals never stated that cmd_getprops() would return the next address of the data for PNG files.
So this is a bug in the BT815 at least, maybe even FT81x that cmd_getprops does not do for PNG images what it is documented to do.
And for BT817 it was decided to fix this by returning the completely useless information on API level 2 to which start address the data was written to?
Okay, fine, keeping the API level 1 behaviour makes it consistent.
This would have been the perfect opportunity to turn this command into being usefull for loading unknown images.
With cmd_getpr() on API level 2 returning the first unallocated memory location for cmd_loadimage as well as cmd_playvideo, cmd_videoframe and cmd_endlist, why is cmd_getprops() on API level 2 not returning the format of the image that has been loaded instead of the source address? You know, the one *property* that is not reported so far.
And the most obvious change in behaviour would have been cmd_getprops() on API level 2 returning the address after the image for JPG images.
-
Hi Rudolph,
That's correct, the level 2 API makes the command the same for both formats.
However, one thing to note is that the new CMD_GETIMAGE which provides additional details for the image and so replaces this functionality. Please see section 5.109 in the Programmers Guide,
https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/BRT_AN_033_BT81X_Series_Programming_Guide.pdf
Best Regards, BRT Community
-
Dang, you are right, I missed CMD_GETIMAGE, probably because I implemented it almost two months before the programming manual was released which involved quite some guessing. :-)
Okay, this is much better than CMD_GETPROPS.
I do wonder though what "source" is good for, same as I wondered what it was good for in CMD_GETPROPS.
The one thing we already do have after a CMD_LOADIMAGE is where we asked the command to put it.
And looking at the new examples, I wonder if these really do work.
This is not limited to CMD_GETIMAGE but the example for this command is this:
uint32_t source, fmt, w, h, palette;
uint16_t ram_fifo_offset = rd16(REG_CMD_WRITE);
cmd_getimage(src, fmt, w, h, palette);
src = rd32(RAM_CMD + ram_fifo_offset + 4);
fmt = rd32(RAM_CMD + ram_fifo_offset + 8);
w = rd32(RAM_CMD + ram_fifo_offset + 12);
h = rd32(RAM_CMD + ram_fifo_offset + 16);
palette = rd32(RAM_CMD + ram_fifo_offset + 20);
cmd_setbitmap(src, fmt, w, h);
if (palette != 0) PaletteSource(palette);
First of all this implies how cmd_getimage() is actually implemented, this function does not only need to send the command but execute it with the command co-processor and wait for its completion.
And this example fails with values for ram_fifo_offset of 0xfec or higher.
Reading from RAM_CMD + 0xff0 + 20 would mean to read from REG_TRACKER_1.
I am not even aware that consecutive reads from RAM_CMD would automaticallly wrap around the same way as consecutive writes do but the example is using separate rd32 commands anyways.
Other commands with these faulty examples are:
CMD_FONTCACHQUERY, CMD_GETPTR, CMD_MEMCRC, CMD_REGREAD
And these would be hell to debug as well since most of the time everything is fine.
Edit: I just tried it out like it is in the example and it really does not work this way.
-
What also got my attention is CMD_NEWLIST, CMD_ENDLIST, CMD_RETURN and CMD_CALLLIST.
Looks like we can expand display list now. :-)
No, actually not.
If I got this correctly now this is an alternative to CMD_APPEND.
It requires less memory as the co-processor list is stored, not a fragment of pre-calculated display-list.
It does not require CMD_MEMCPY since the commands are written out to RAM_G directly.
And the command-list fragment is terminated by a CMD_RETURN, automatically so when using CMD_ENDLIST, this means that the new CMD_CALLLIST does only need an address but unlike CMD_APPEND it does not need the length of the fragment.