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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - BRT Community

Pages: 1 ... 42 43 [44] 45 46 ... 49
646
Discussion - EVE / Re: Is it possible to display several lists on one screen
« on: September 20, 2019, 03:07:56 PM »
Hello,

You can only display one display list at a time with EVE although you can use the append technique as you have done to allow screen updates without re-sending all data. There is a limit of 8Kbytes for the display list.

Note that this is the actual RAM_DL content rather than the number of bytes of co-processor commands as some co-processor commands generate more bytes of RAM_DL instructions than the command itself. Also, note that this total also includes any appended commands and so ensure to count any appended data too.

You can send several blocks of co-processor instructions but you should only have your DISPLAY and SWAP at the end of the last block and begin the first block with a DL_START. Therefore even if you split the commands into several blocks, the result will still be one list in RAM_DL.

If you want to check if you are running out of RAM_DL, you can check the REG_CMD_DL register after executing a set of one or more commands. This register defines where the next RAM_DL entry will be put by the co-processor and so you can check when your list is approaching the limit.

RAM_DL always defines what is actually on the screen whereas RAM_CMD commands will be executed and will result in RAM_DL instructions being generated.

If your issue is running out of RAM_DL, you could consider making some lines or other items into bitmaps as these can be displayed with only a few commands. Your entire table could be make with an L1 bitmap and then just add the text values afterwards.

Best Regards, BRT Community




647
Discussion - EVE / Re: BT815 and custom fonts in SPI flash
« on: September 13, 2019, 02:31:03 PM »
Hello,

The .xfont should be loaded into RAM_G, while the .glyph should loaded into the flash.
Given an appropriately sized flash chip, you can load all your .glyphs onto there during start-up and access them when needed in your application. Copying the desired new .xfont files to RAM_G when you wish to change the font being used.

Best Regards,
BRT Community

648
Discussion - EVE / Re: BT815 and custom fonts in SPI flash
« on: September 12, 2019, 01:05:55 PM »
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.

Code: [Select]
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

649
Thanks, we will try it here and report back,
Best Regards, BRT Community

650
Discussion - EVE / Re: How to detect CMD_FLASHERASE completion?
« on: September 11, 2019, 11:55:03 AM »
Hello,

Yes, that is correct.

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

Best Regards,
BRT Community

651
Discussion - EVE / Re: BT815 and custom fonts in SPI flash
« on: September 11, 2019, 11:53:45 AM »
Hello,

Unfortunately, you must load any custom font data from the flash into RAM_G before it can be used by EVE.

Best Regards,
BRT Community

652
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

653
Discussion - EVE / Re: How to detect CMD_FLASHERASE completion?
« on: September 10, 2019, 01:38:33 PM »
Hello,

Yes, after issuing the CMD_FLASHERASE command, waiting until the REG_CMD_READ and REG_CMD_WRITE pointers are equal will let you know the command has completed.

Best Regards,
BRT Community.

654
Discussion - EVE / Re: Migrate from ft811 to bt815
« on: September 04, 2019, 03:43:12 PM »
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

655
Discussion - EVE / Re: Migrate from ft811 to bt815
« on: September 04, 2019, 11:05:13 AM »
Hello,

If REG_ID is reading 0x7c and REG_CPURESET is reading 0x00 the IC is initialized correctly.
 
Again I would double check the settings for your screen are correct.
I would also not attempt to write a Display List until after you have set REG_PCLK.

I suspect the issue is with the writing of the Display List, can you get SPI capture of the transactions from your MCU to EVE?

Best Regards,
BRT Community

656
Discussion - EVE / Re: Migrate from ft811 to bt815
« on: September 03, 2019, 10:53:50 AM »
Hello Florian,

It is recommended that you implement the following start up sequence (including the checks for REG_ID and REG_CPURESET):
Code: [Select]
    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

657
Discussion - EVE / Re: Abort pending swap
« on: August 29, 2019, 01:51:10 PM »
Hello

Curious as to what you are trying to achieve, is there any particular reason you wish to :
Quote
abort all pending operations and begin populating the command FIFO in less than the frame interval?

You are correct there is no register which will give you the current scan out position. You can probably do the maths given the display parameters of the screen you are using the PCLK frequency being used. For a given 60 Hz refresh rate you are looking at 16ms for a frame, is there a necessity in your application to update a frame in an interval that is less than 16ms?

Best Regards,
BRT Community

658
Discussion - EVE / Re: Abort pending swap
« on: August 28, 2019, 03:11:02 PM »
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

659
Hello,

The HY4635 is not listed as compatible with EVE, you will need to use Touch Host mode as describe in section 6.7 of the following:
https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_336_FT8xx-Selecting-an-LCD-Display.pdf

I believe enabling touch host mode for the BT81x aligns with the procedure for the FT81x series of ICs, but I will double check with the development team.

Best Regards,
BRT Community

660
Discussion - EVE / Re: EVE3 - Asynchronous display-list updates
« on: August 22, 2019, 10:29:33 AM »
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:

Code: [Select]
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



Pages: 1 ... 42 43 [44] 45 46 ... 49