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

Author Topic: Using Custom Font in RAM  (Read 6554 times)

Qrenz

  • Newbie
  • *
  • Posts: 15
    • View Profile
Using Custom Font in RAM
« 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

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

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 733
    • View Profile
Re: Using Custom Font in RAM
« Reply #1 on: June 09, 2020, 05:27:31 PM »

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
Logged