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: BT Flash questions...  (Read 7089 times)

iv_pb

  • Newbie
  • *
  • Posts: 6
    • View Profile
BT Flash questions...
« on: December 28, 2020, 02:55:46 PM »

When accessing the BT Flash, do we use the address 0x800000 for access/reference once its been initialized or use a relative address (0x00000) ?
Is the BT Flash persistent, or does it need to be initialized after every GPU reset?
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT Flash questions...
« Reply #1 on: January 01, 2021, 02:49:20 PM »

>When accessing the BT Flash, do we use the address 0x800000 for access/reference once its been initialized
>or use a relative address (0x00000) ?

Yes.  8)
Some commands use a relative address like cmd_flashupdate and cmd_flashrite which start from 0x00000.
And cmd_setbitmap for example uses the number of 32 byte blocks with 0x800000 as offset:
EVE_cmd_setbitmap_burst(0x800000 | (4096/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 344, 48); /* display directly from FLASH */
So in this line 4096 is the address of an image in the flash.

>Is the BT Flash persistent, or does it need to be initialized after every GPU reset?

It is nonvolatile and once it is programmed you need to use cmd_flashfast() after every GPU reset
to actually make use of the content.

I wrote this a couple of days ago as a demonstration for someone else:
Code: [Select]
#include "EVE.h"
#include "tft_data.h"

/* some pre-definded colors */
#define WHITE 0xffffffUL
#define BLACK 0x000000UL

uint8_t tft_active = 0;

void TFT_init(void)
{
if(EVE_init() != 0)
{
tft_active = 1;
EVE_memWrite8(REG_PWM_DUTY, 0x40); /* setup backlight, range is from 0 = off to 0x80 = max */

#if 1
/* this is only needed once to transfer the flash-image to the external flash */
uint32_t datasize;

EVE_cmd_inflate(0, flash, sizeof(flash)); /* de-compress flash-image to RAM_G */
datasize = EVE_cmd_getptr(); /* we unpacked to RAM_G address 0x0000, so the first address after the unpacked data also is the size */
EVE_cmd_flashupdate(0,0,4096); /* write blob first */
EVE_init_flash();
EVE_cmd_flashupdate(0,0,(datasize|4095)+1); /* size must be a multiple of 4096, so set the lower 12 bits and add 1 */
#endif

EVE_init_flash();
}
}


/*
dynamic portion of display-handling, meant to be called every 20ms or more
*/
void TFT_display(void)
{
if(tft_active != 0)
{
EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */

EVE_cmd_dl_burst(CMD_DLSTART); /* start the display list */
EVE_cmd_dl_burst(DL_CLEAR_RGB | BLACK); /* set the default clear color to white */
EVE_cmd_dl_burst(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG); /* clear the screen - this and the previous prevent artifacts between lists, Attributes are the color, stencil and tag buffers */
EVE_cmd_dl_burst(VERTEX_FORMAT(0)); /* reduce precision for VERTEX2F to 1 pixel instead of 1/16 pixel default */

EVE_cmd_dl_burst(DL_COLOR_RGB | WHITE);

EVE_cmd_setbitmap_burst(0x800000 | (4096/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 344, 48); /* display directly from FLASH */

EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl_burst(VERTEX2F(200, 100));
EVE_cmd_dl_burst(DL_END);

EVE_cmd_dl_burst(DL_DISPLAY); /* instruct the graphics processor to show the list */
EVE_cmd_dl_burst(CMD_SWAP); /* make this list active */

EVE_end_cmd_burst(); /* stop writing to the cmd-fifo, the cmd-FIFO will be executed automatically after this or when DMA is done */
}
}


This writes a small flash binary compressed with zlib from the microcontrollers-memory to the external FLASH, initialises the FLASH and displays an picture directly from it.
After the first run the "#if 1" in TFT_init() can be changed to "#if 0" to remove this block.

I used the EVE Asset Builder to convert the picture, generate the flash image, compress the flash image and convert the compressed flash image to a c-style array.
With 1314 bytes for the flash-image this compiles to 4886 bytes for an Arduino UNO.
So like this an UNO could write about 28k of compressed data into the FLASH.

One could use a bigger controller to copy data like this, the limit would be the 1MB of RAM_G then that needs to store the unpacked data before it is written to the FLASH.


https://github.com/RudolphRiedel/FT800-FT813
Logged

iv_pb

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: BT Flash questions...
« Reply #2 on: January 05, 2021, 09:41:13 PM »

Rudolph,

Thank you for the clarification and sample code.

Do you know what the memory between the RAM_G and ROM_FONT is used for?

iv
« Last Edit: January 05, 2021, 09:43:18 PM by iv_pb »
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT Flash questions...
« Reply #3 on: January 06, 2021, 09:02:34 PM »

>Do you know what the memory between the RAM_G and ROM_FONT is used for?

No idea, I was not even aware that there is this nice big gap. :-)
The "Address Space" or memory map in the programming manual is not complete.
For example 0x30900+ is used for registers since FT81x although RAM_REG from 0x302000 to 0x302fff still has plenty of empty space.
And 0x30b000 is where the code for the touch-controller is located at.

I am guessing that this gap of 896k got reserved for future devices to for example expand RAM_G.
But well, embedded SRAM is not cheap to implement which probably is the reason why BRT did not "just" add annother 256k, 512k or 768k to RAM_G so far.
So there should be nothing there currently.
Yes, I am speculating. :-)

And now I am curious what would happen if there is something written to this area. :-)
Logged