BRT Community
General Category => Discussion - EVE => Topic started by: Qrenz on June 08, 2020, 01:53:09 PM
-
I want to use custom font in my application, and I'm following this App Note "BRT_AN_014_FT81X_Simple_PIC_Library_Examples".
In the section 6.2, I got a little confused, when it calculate the raw data address, why the value is negative?
(Address of data in RAM_G) + (Metric Block size) – (32 characters worth of (stride * height))
1000 + 148 – (32*(3*25))
= 1000 + 148 – 2400
= -1252
and then -1252 is fed to BITMAP_SOURCE
API_LIB_BeginCoProList();
API_CMD_DLSTART();
API_CLEAR_COLOR_RGB(0, 0, 0);
API_CLEAR(1,1,1);
API_BITMAP_HANDLE(14);
API_BITMAP_SOURCE(-1252);
API_BITMAP_LAYOUT(L1,3,25);
API_BITMAP_SIZE(NEAREST, BORDER, BORDER, 18,25);
The BITMAP_SOURCE command has 22-bit address as parameter, so -1252 will be 0x3FFB1C after clipped to 22-bit address.
But the RAM_G on FT81x device only from 0x000000 to 0x0FFFFF, it's out of range.
Can help me understand this?
Another thing is, after we set the custom font, and we want to call CMD_TEXT or CMD_NUMBER and use the custom font,
do the character that we use must be included in the converted character in our font?
For example i call CMD_TEXT with text string "abc", but my custom font is in UTF-8 format and i don't have 'a', 'b', 'c' in the converted font index, will it work?
Thank you
-
Hello,
The raw data address is calculated as an offset which points to where the 0th character of the font
data would have been. The actual data loaded begins with the first printable character (i.e. the address for the data in RAM_G)but since this would be the 32nd character in an ASCII data set, the virtual value of the raw data address of
the 0th character would have been at, this is why the address is negative.
And yes, the character must be included in your converted font if you wish to use CMD_TEXT or CMD_NUMBER with the desired font handle. in your example the 'a/b/c' characters wouldn't display as they haven't been converted.
Best Regards,
BRT Community