BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: BT817 / BT818 new features  (Read 9100 times)

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
BT817 / BT818 new features
« 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:
Code: [Select]
#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. :-)
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT817 / BT818 new features
« Reply #1 on: October 31, 2020, 06:36:06 PM »

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.
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 732
    • View Profile
Re: BT817 / BT818 new features
« Reply #2 on: November 09, 2020, 09:17:28 AM »

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

Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT817 / BT818 new features
« Reply #3 on: November 09, 2020, 06:29:56 PM »

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:
Code: [Select]
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.
« Last Edit: November 09, 2020, 08:53:16 PM by Rudolph »
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT817 / BT818 new features
« Reply #4 on: November 10, 2020, 08:21:30 PM »

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.
Logged