Hi Rudolph,

Thanks for your results, we'll look into that on ESE,

Hi Chadpham75,

I think you are missing the "| 128" in your address,   this is 0x800000 | 4096/32 where 4096 is the address in flash that you loaded the image

    Cmd_SetBitmap(0x800000 |128, COMPRESSED_RGBA_ASTC_8x8_KHR, 480, 272);

Best Regards, BRT Community

Hello,

Thanks for your feedback, I will result that the development team look into adding features to support language switching in the upcoming revisions of ESD.

Best Regards,
BRT Community

Hello,

I have split this topic just for clarity as the previous topic was concerning bug reports with EAB.

I don not have any examples specifically for the EVE3-43G utilising the USB2SPI adapter board from matrix oribital (they may have some on their website), however if you can share the code you are using to display the image I can review this.

Some generic examples of how to convert and display images can be found in section 7 of the following application note:
BRT_AN_014 FT81X Simple PIC Library Examples

Could you also show me distortion you are seeing in the corner of the image?

I had a quick look at the EVEBitmapViewer source code and it looks like this expects images to be in the RGB565 format, what options are you using in EAB to convert your new image?

Best Regards,
BRT Community

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