Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BRT Community]

Hello Rudolph,

Thank you for a further example of the issue, I have passed this back to the development team for investigation, and will update you when they get back to me.

Best Regards,
BRT Community

[Rudolph]

Annother minor thing I would like to mention again is that there is no verify function in EAB.
Sure, there is "UPDATE&VERIFY" now but what if someone needs to verify the content that already is on the chip?
There is the option to read the content and that is definately the way to go for a more detailed analyses.
But a simple "VERIFY" option would be helpfull.

[BRT Community]

Hello Rudolph,

I agrees a flash verification feature would be useful, I have suggested adding this to the next release of EAB.

Best Regards,
BRT Community

[Rudolph]

Thank you for a further example of the issue, I have passed this back to the development team for investigation, and will update you when they get back to me.

Hello,

as I was just reminded of UTF-8 fonts, any update on the font converter?
And I would apreciate a few answers to my questions. :-)

I also would not mind giving the "v2.2.0" of EAB a spin that you took the screenshot from in the "Atmel CTP Support" thread.
Or as that is from february, what about a "v2.2.1" or "v2.3.0"? :-)
The last version released so far is "v2.1.0" from early november.
 

[BRT Community]

Hello Rudolph,

Sorry I had passed this onto the development team for some clarification, but they are quite busy recently. I will chase them up on this.

I believe the v2.2.0 release is intended as an internal release for some bug updates, while the next official release will be v2.3.0.

However the release note does mention the following:

Code: [Select]

Feature updates
- Improve flash programming utility to work with 128 Mbytes flash chip
- Improve font utility:
  + Report only valid characters
  + Calculate the number of characters in each unicode ranges

As such I believe this will resolve some of the issues you have been seeing.

EDIT: please use the following link: EVE-Asset-Builder-setup-2.2.0-rc2.zip

Best Regards,
BRT Community

[Rudolph]

Hello,

EDIT: please use the following link: EVE-Asset-Builder-setup-2.2.0-rc2.zip

Nice, thank you!

- Improve flash programming utility to work with 128 Mbytes flash chip

I wish I had the issue with 128 MBytes of flash. :-)

- Improve font utility:
  + Report only valid characters
  + Calculate the number of characters in each unicode ranges

That looks promising indeed.

You you left out the RC1 changes:

RC1:
Feature updates
-   Upgrade to astcenc.exe v2.0 for faster encoding
-   Adjust the compiled custom touch firmware to make it patchable
-   Add option for FT80x chip in Font Converter
-   Change generated function name for Legacy Font Converter
-   Add option to optimize JPEG file by using 'jpegtran'
-   Adjust font metrics output

The supplied astcenc.exe does not work on my system though as it is the AVX2 version and my FX-8320E does not support AVX2.
So I downloaded the  astcenc-2.5-windows-x64.zip release package from here: https://github.com/ARM-software/astc-encoder
I copied the astcenc-sse4.1.exe file, renamed it and it works. :-)

The difference in performance compared to the previous 1.x is just amazing!
A font is converted in seconds now!!


Regarding font conversions, the reporting is a lot better and fixed:
Number of characters in xfont file     : 9728
Number of characters in user input file: 132

How the font converted to 9728 chars though, no idea.

This is the additional "Font Block Info":
Number of glyphs: 132
Basic Latin U+0000-U+007F 97/128
Latin-1 Supplement U+0080-U+00FF 18/128
Spacing Modifier Letters U+02B0-U+02FF 3/80
General Punctuation U+2000-U+206F 11/111
Currency Symbols U+20A0-U+20CF 1/32
Letterlike Symbols U+2100-U+214F 1/80
Geometric Shapes U+25A0-U+25FF 1/96

So this should convert to no more than 7 blocks of 128 chars and I would
expect a maximum of 896 characters as a worst case in the xfont file.
And it should be even less since four blocks are rather short and would definately not need a full block of 128.
 
In addition the conversion of full fonts does result in even bigger files now from the same fonts.

EAB 2.2.0: notosans-regular-webfont2_32_ASTC.glyph 449088 bytes
EAB 2.1.0: notosans-regular-webfont2_32_ASTC.glyph 377280 bytes

So the display is fixed but in return there are even more empty glyphs in the .glyph file than before.


Okay now, it looks like the way to go is to work with a charmap-file.

!CharMap6.txt
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~°±²³µ¼½¾ÄÖÜßäöü"
Pixel Width   : 48
Pixel Height  : 48
Number of characters in xfont file     : 256
Number of characters in user input file: 110
NotoSans-Regular_32_ASTC.glyph 145472 bytes

!CharMap10.txt
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûü"
Pixel Width   : 48
Pixel Height  : 48
Number of characters in xfont file     : 256
Number of characters in user input file: 187
NotoSans-Regular_32_ASTC.glyph 145472 bytes

So as long as the charmap includes chars for the same number of blocks and the last char in a block is the same,
the resulting .glyph has the same size.

There is annother bug:

!CharMap9.txt
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ"
Pixel Width   : 48
Pixel Height  : 48
Number of characters in xfont file     : 384
Number of characters in user input file: 190
NotoSans-Regular_32_ASTC.glyph 201344 bytes

!CharMap11.txt
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþ"
Pixel Width   : 48
Pixel Height  : 48
Number of characters in xfont file     : 256
Number of characters in user input file: 189
NotoSans-Regular_32_ASTC.glyph 146624 bytes

The difference between !Charmap9.txt and !Charmap11.txt is the "ÿ" at the very end.
This introduces a whole new block for !Charmap9.txt.
However, this is U+00ff so it should be the last char of the second block.

Okay, annother one:

!CharMap15.txt
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûü€"
Pixel Width   : 48
Pixel Height  : 48
Number of characters in xfont file     : 8448
Number of characters in user input file: 188
NotoSans-Regular_32_ASTC.glyph 299584 bytes

So this is the same as !CharMap10.txt but with a single "€" at the end.
My expectation would be 384 characters in the xfont file as this should only add a single block.
And the size should be in the range of 250000 bytes as "€" is U+20ac, so near the end of an otherwise empty block.

8448 chars is 66 blocks, so there are 63 completely empty blocks? Why?

[BRT Community]

Hello,

thank you for your feedback and testing!

I have passed this back to the develoers so they can take account of this for the next official EAB release.

As for the number of characters in the .xfont file, it is my understanding that this is because the .xfont file contains a width table for all Unicode characters up until the last Unicode character included in the input character set. For unconverted characters these font widths would of course be 0 for their Unicode position. however it still appears that you are seeing discrepancies with this in your testing.

Best Rergards,
BRT Community

[Rudolph]

I messed up a little in the test with "!CharMap9.txt".
The last char is "ÿ" and not "þ" but "ÿ" is indeed U+00FF.

And the numbers of characters in the .xfont file itself is not really important as it does not seem to affect
the length of the .xfont files or at least not by much. This is just odd.
The number of empty glyphs in the .glyph file really are something else.

Why can't the invalid characters not simply point to the exact same glyph?

I would really like to know what is actually going on the .xfont files and how to calculate
the address of a given character.

[BRT Community]

Hello Rudolph,

There is some pseudo code in the programmers guide which covers how the address's are calculated:

Code: [Select]

struct xfont {
 uint32_t signature,
 uint32_t size,
 uint32_t format,
 uint32_t swizzle,
 uint32_t layout_width,
 uint32_t layout_height,
 uint32_t pixel_width,
 uint32_t pixel_height,
 uint32_t start_of_graphic_data;
 uint32_t gptr[];
 uint32_t wptr[];
};
uint32_t cp_address(xfont *xf, uint32_t cp)
{
 uint32_t bytes_per_glyph;
 bytes_per_glyph = xf->layout_width * xf->layout_height;

 if (xf->start_of_graphic_data >= 0x800000)
 //if the graphic data is in flash
 return (xf->start_of_graphic_data +
 xf->gptr[cp / 128] +
 bytes_per_glyph * (cp % 128) / 32);
 else
 //if the graphic data is in RAM_G
 return (xf->start_of_graphic_data +
 xf->gptr[cp / 128] +
 bytes_per_glyph * (cp % 128));
}
uint32_t cp_width(xfont *xf, uint32_t cp)
{
 return *(
 (uint8_t*)xf +
 xf->wptr[cp / 128] +
 (cp % 128));
}
I am still trying to clarify the other issues with the developers.

Best Regards,
BRT Community

[Rudolph]

Well, that pseudo-code has a number of errors.

Starting with the structure for the .xfont file.
Of course this is a mean one since the structure actually is different for the amount of pages
as the size of the arrays gptr[], wptr[] and the amount of chars changes with the number of pages.
In case of the 2 page / 256 chars version it looks like this:

Code: [Select]

struct xfont_type
{
uint32_t signature;
uint32_t size;
uint32_t format;
uint32_t swizzle;
uint32_t layout_width;
uint32_t layout_height;
uint32_t pixel_width;
uint32_t pixel_height;
uint32_t start_of_graphic_data;
uint32_t number_of_chars;
uint32_t gptr[2];
uint32_t wptr[2];
uint8_t width_data[256];
} xfont;

So the example left out the number_of_chars and the width_data[].

Next it completely fails to mention that the codepoint somehow needs to be calculated from the UTF-8.
I also skipped that part for now since I am only using the first two pages for which the codepoints are only 0x00 to 0xff.

Calculating the address of a glyph for a codepoint in the example has the maths wrong.

Code: [Select]

char_address = xfont.start_of_graphic_data + ((xfont.gptr[char_cp / 128] + (xfont.layout_width *  xfont.layout_height * (char_cp % 128))) / 32);

So the offset data from xfont.ptr needs to be added to (width*height*(cp%128)) and then this needs to be divided by 32 before this is added to the start of graphic data.

I am printing out the glyphs in a loop right now from 0x00 to 0xff and it works.
The glyphs are just images of the same pixel_width and pixel_height.
And every glyph that there is not actually a character for is an empty picture, like for example
all the images from 0x00 to 0x31 are just blanks.
The compression is "hidden" in the layout_width and layout_height.
And these values likely also are adapted to meet the requirement of the 32 byte alignment for an image from flash.

The values for gptr and wptr are interesting:
xfont.gptr[0] = 0x00009bc0
xfont.gptr[1] = 0x00000000
xfont.wptr[0] = 0x000000b5
xfont.wptr[1] = 0x00000038

So somehow the glyphs for the second page are stored first.
Nothing wrong with that, just interesting.

The width data seems to be even stranger.
The offsets in wptr[0] and wptr[1] are not for the array of the width_data bytes but rather for the
start-address from the structure itself.

So as I have two pages the array starts at offset 56 and the data for with widths
can be read this way:

Code: [Select]

char_width =  xfont.width_data[(xfont.wptr[char_cp / 128] - 56) +  (char_cp % 128)];

The result printing this out alongside the code-point and the glyph for the codepoint is that
all the empty chars have a width of zero.

Well, I guess that does not leave much unxplained about the format of the .glyph data.
Mostly it is pretty much inefficient.

[BRT Community]

Hello,

Thank you for your feedback, I will strive to get the datasheet updated accordingly, and I have chased up the developers again for your previous points.

Best Regards,
BRT Community.

[amaul]

Quick note, I can't seem access to the link: EVE-Asset-Builder-setup-2.2.0-rc2.zip.

Thanks,

Alex

[Rudolph]

Quick note, I can't seem access to the link: EVE-Asset-Builder-setup-2.2.0-rc2.zip.

It is still there and accessible.
But what is gone is FTP-support in FireFox for example, I am using FileZilla now.

[nico]

I can also not download it even with FTP client. I think user / password are not correct anymore. Can someone update the link to get the newest version?

[BRT Community]

Hello,

We are currently migrating our FTP site to an SFTP server.
If you wish to test the beta version of EAB (2.2.0-rc2), please send an email into: sales.emea@brtchip.com and I can provide you the installer.

Best Regards,
BRT Community