Hi,

We have some information below on how to use the Append command to recall sections of the display list.

https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_340_FT800_Optimising-screen-updates-with-Macro-and-Append.pdf

You can save different sets of commands in different areas of RAM_G and then recall them depending on what screen you are displaying.

There is sometimes a trade-off between recalling sections and sending the full list (especially if you use a SPI burst write which is quite efficient) depending on how much of the screen changes. If you have enough RAM_G you can have all your images loaded at the start and just display them and so each new screen can be quite efficient already. But if most of the screen is static then this Append technique should help.

Best Regards, BRT Community

Hello,

I’ve had some clarification from the developers regarding Unicode font conversions:

• Only the font metrics table covers the maximum code point of the input characters.
• For the .glyph data,  only the input characters are converted. The characters whose code point are not present are not
  converted.

Then, number of characters is determined by: (max code point + 128 ) & ~ 127. For example if one input character set includes a character whos max code point is 382 (ž), then the .xfont will list 384 characters:

(382 + 128) & ~127 = 384

If another input character set in used which include for example the trademark symbol (™), its max code point would be 8482, and the .xfont would list 8576 characters:

(8482 + 128) & ~127 = 8576


The metric table (.xfont) will include the number relating to the max code point, and will include padding to the relevant code points for a characters width data.
However only the characters included in the input character set will be converted to the .glyph data.

I will need to investigate why you are seeing such large .glyph files when converting these fonts with differing character sets. Could you provide the input char set and font file you are using during conversion?

Best Regards,
BRT Community

Hello,

The code below is an example of writing a file to a flash IC connected to EVE:
int Utils_Write_File_To_Flash(uchar8_t *fileName, uint32_t addr, uint32_t tmp_ram_addr)
{
FILE *fp;
uint32_t fileLen, ret, progress = 0;
uint8_t pBuff[(1024 * 32)];
fp = fopen(fileName, "rb+");

if (fp) {

fseek(fp, 0, SEEK_END);
ret = fileLen = ftell(fp);

fseek(fp, 0, SEEK_SET);
while (fileLen > 0)
{
progress = (ret - fileLen) * 100 / ret;
fprintf(stderr, "Progress PROG %d\n", progress);
fflush(stderr);
int32_t ramlen = 0;
tmp_ram_addr = 0;
while ((ramlen < (1024 * 1024)) && (fileLen > 0))
{
uint32_t blocklen = fileLen > (1024 * 32) ? (1024 * 32) : fileLen;
fread(pBuff, 1, blocklen, fp);
fileLen -= blocklen;
Gpu_Hal_WrMem(phost, tmp_ram_addr, pBuff, blocklen); //write data to RAM_G
tmp_ram_addr += blocklen;
ramlen += blocklen;
}
ramlen = (ramlen + 4095) & (~4095);//to ensure 4KB alignment

Gpu_CoCmd_FlashHelper_Update(phost, addr, 0, ramlen); // CMD_FLASHUPDATE
addr += ramlen;
}
fclose(fp);
}
else {
printf("Unable to open file: %s\n", fileName);
}
return ret; /* File size */
}
Please note, this is from our EAB flash programming utility which requires a USB connection to a module. However the same steps will work when updating a flash IC from an MCU. Unfortunately however you may be required to expand the storage of your MCU if the flash file is significantly larger than the storage available, adding an SD card to your configuration may be a suitable solution.

Best Regards,
BRT Community

Hello,

The developers have noted that every bitmap in BORDER mode has a black border. It's not normally visible, but in bilinear at the edges, the black border pixels get sampled and used. We are looking into modes for future revisions of EVE to mitigate this behaviour, but currently there is the expected behaviour for EVE.

Best Regards,
BRT Community

Hello,

Thank you for the details.
I'm glad you work around is producing much better results currently, I am in discussion with the development team to see if they have any other suggestions for mitigating this behaviour.

Best Regards,
BRT Community

Hello,

Thank you for your question.
Could you give me details on how you have converted the bitmaps you are using with Bilinear filtering, so I can investigate this issue further?

Best Regards,
BRT Community

Hello

Would it be possible for you to share your project with us so we can investigate this issue further?
Can you also give me details on your hardware setup, i.e which MCU are you using?

Best Regards,
BRT Community

Hi,

We have not used that configuration but we're not aware of any issue with using the MCU to do the reset so long as you provide the same sequence to reset the LCD controller on start-up. As you mentioned, we allow for both on the ME810A-HV35R via the OR gate. We normally leave the MCU input unused and use the DISP line from the FT810 when using this module but it should also work if using the MCU only. We're not sure about the timing needed for the ST7789 but you could even use a solder jumper in place of the OR gate to select one source or the other for initial testing.

Best Regards,
BRT Community