Hello,

Also, as Rudolph mentioned, the BT81x can use font .glyph flies directly from FLASH. But the .xfont file should be copied to RAM_G. This can either be stored on the MCU or can be stored on flash and then copied by your code to RAM_G.

void SAMAPP_ExtendedFormat_Font()
{
SAMAPP_API_Screen("Unicode Font");
#define UNICODE_HANDLE 30
Gpu_FontsExt_t font;
uint32_t fontAddr = RAM_G;
//Load glyph file into BT815's flash
//Load xfont file into graphics RAM

/* Switch Flash to FULL Mode */
Gpu_CoCmd_FlashHelper_SwitchFullMode(g_phost);
Gpu_Hal_LoadImageToMemory(g_phost, TEST_DIR "\\mssong_20.xfont", fontAddr, LOAD);
Gpu_Hal_WaitCmdfifo_empty(g_phost);

Gpu_CoCmd_Dlstart(g_phost);
App_WrCoCmd_Buffer(g_phost, CLEAR(1, 1, 1));
App_WrCoCmd_Buffer(g_phost, COLOR_RGB(255, 255, 255));

Gpu_CoCmd_SetFont2(g_phost, UNICODE_HANDLE, fontAddr, 0);
Gpu_CoCmd_Text(g_phost, 0, 0, UNICODE_HANDLE, 0, u8"BRT的EVE技术是一个革命性的概念，");
Gpu_CoCmd_Text(g_phost, 0, 30, UNICODE_HANDLE, 0, u8"利用面向对象的方法创建高质量的人机界面（HMI） 同时支持显示，");
Gpu_CoCmd_Text(g_phost, 0, 60, UNICODE_HANDLE, 0, u8"音频和触摸功能。");
App_WrCoCmd_Buffer(g_phost, DISPLAY());
Gpu_CoCmd_Swap(g_phost);
App_Flush_Co_Buffer(g_phost);
Gpu_Hal_WaitCmdfifo_empty(g_phost);
Gpu_Hal_Sleep(4000);
}
Best Regards,
BRT Community

Hello,

Yes, that is correct.

Thanks for the suggestion, I will pass it on to the document team.

Best Regards,
BRT Community

Hi,

Could you advise which code you use to load the file, to check the end address, and to display the image? Could you also attach (or send to our support address support.emea@brtchip.com) an example folder with the pre- and post- converted files.

Best Regards,
BRT Community

Hello,

We find in cases where the screen exhibits the behaviour you are seeing that there is a disparity between what you think you have sent EVE over SPI and what you have actually sent from your MCU to the EVE IC.

To debug this properly you will need to find a way to capture the SPI transactions, MOSI/MISO/CS/SCLK are all pertinent.

Best Regards,
BRT Community

Hello Florian,

It is recommended that you implement the following start up sequence (including the checks for REG_ID and REG_CPURESET):
    MCU_PDlow();                                                                // PD low to reset device                                                               
    MCU_Delay_20ms();
    MCU_PDhigh();                                                               // PD high again
    MCU_Delay_20ms();

    // ---------------------- Optional clock configuration ---------------------   

    // Un-comment this line if using external crystal. Leave commented if using internal oscillator.
    // Note that most FTDI/BRT modules based on FT800/FT801 use an external crystal
    // EVE_CmdWrite(0x44, 0x00);           // 0x44 = HostCMD_CLKEXT

    // You can also send the host command to set the PLL here if you want to change it from the default
    // of 48MHz (FT80x) or 60MHz (FT81x)
    // The command would be called here before the Active command wakes up the device   
   
    // ---------- Wake FT8xx and delay to allow device to start-up -------------   
   
    EVE_CmdWrite(FT81x_ACTIVE, 0x00);                                           // Sends 00 00 00 to wake FT8xx
    MCU_Delay_500ms();                                                          // 500ms delay (EVE requires at least 300ms here))
   
    // --------------- Check that FT8xx ready and SPI comms OK -----------------
   
    while (EVE_MemRead8(REG_ID) != 0x7C)                                        // Read REG_ID register (0x302000) until reads 0x7C
    {
    }
     
    while (EVE_MemRead8(REG_CPURESET) != 0x00)                                  // Ensure CPUreset register reads 0 and so FT8xx is ready   
    {
    }

Can you also try using a slower SPI rate until you have set the display settings, I would suggest 11Mhz, after which you can up the SPI rate again. Finally please ensure the settings you are using are correct for your given display.

Best Regards,
BRT Community

Hello,

The REG_DLSWAP register should not be written to 0 as explicitly stated in the documentation.
Ignoring this could result in unpredictable behaviour of the IC.

Best Regards,
BRT Community

One thing to add regarding buttons is that we find using bitmap icons is often a good way where you have lots of buttons. If your icons are all the same size, using bitmap cells (where you create a large bitmap image which is one button wide and many buttons high) is a really handy way of doing this with minimal display list content plus you can give the icons your own desired appearance. You then place the icon by VERTEX2II which includes the handle and the specific cell number you want to place. Or by the CELL instruction followed by VERTEX2F.

There are several ways to implement this including:

• Having one image per icon and use conditional code to do one of the following when a variable indicates the button should be 'pressed'

- using the bitmap transform to re-size slightly
- add a slightly larger rectangle behind to give a glow round the edges
- set COLOR_RGB before the icon is placed and re-color to indicate pressed

• Having more than one image per icon which you select using the cell number using similar conditional code:

TAG_MASK(1);
BEGIN(BITMAPS)
COLOR_RGB(255,255,255)  // white displays following bitmaps in their original colours
TAG(Button_0);
If(Button0_Pressed == false)  // Button0_pressed is a local Boolean in your code
VERTEX2II(100,100,5,0)  // display cell 0 which is your button 0 unpressed
Else
VERTEX2II(100,100,5,1)  // display cell 1 which is your button 0 pressed
With most of these methods you can also keep the display list size the same regardless of button state.

As you mentioned, it is often quite efficient to re-send the entire list especially when using SPI burst writes when something on the screen changes if you have a lot of dynamic objects. For anyone looking to use the append in the original way (with RAM_DL content rather than commands) then you may also find using icons rather than buttons along with using multiple appended sections as smaller building blocks helps to minimise variation in length of the DL.

Thanks for your inputs Rudolph and Jesse, I'm sure your experiences here will help other users too,

Best Regards,
BRT Community

Hello,

Thanks for pointing that out, we will update the documentation.

Best Regards,
BRT Community