BRT Community

🚀 Just 1 Day Left – Bridgetek Webinar!

Traditional MCUs can't keep up with today's graphics demands — leaving developers stuck with complex code, slow performance, and limited user experiences.

✨ Discover how EVE (Embedded Video Engine) changes the game:

- Integrated graphics power for faster workflows
- Less coding, quicker time‑to‑market
- Smooth, engaging interfaces across industries

From smart appliances to industrial systems, EVE helps you break free from MCU limits and design the future of embedded UI.

📅 15 April 2026 
🕒 3PM GMT / 9AM CST / 10AM EST

Link : https://42bmw.share.hsforms.com/24P6cvmRSRXiyttQhXDfvPw

Traditional MCUs often hit their limits when faced with today's demanding graphics and touch requirements. Complex code, sluggish performance, and limited user experiences can hold back innovation.

Join our upcoming Bridgetek webinar to discover how EVE (Embedded Video Engine) transforms development:

Simplify design workflows with powerful integrated graphics capabilities.

Reduce code complexity and accelerate time-to-market.

Deliver smoother, more engaging user experiences across applications.

Whether you're building smart appliances, industrial interfaces, or next-gen IoT devices, EVE helps you move beyond the constraints of traditional MCUs.

👉 Reserve your spot today and see how Bridgetek EVE can design seamless interfaces - moving beyond MCU limitations.



LIMITED SEATS! REGISTER NOW

I am just getting "Error: Invalid value for '-c' / '--command'" when adding -cw 1 0 0 0

Hello Redolph,

Can i ask what the command line output was when attempting to use the the -cw option?

Best Regards,
BRT Community

Excellent, a viable workaround and a fix incoming then. 
I just went with the ASTC 4x4 for now, I should be pretty much done with the UI and still have not filled half of RAM-G.
Interesting that ASTC has no direct support for grey textures.
I tried to use the -cw" option from astcenc.exe, but eab_tools does not accept it.

Hello Rudolph,

Tank you for your post.

After internal review, we have identified that the difference in font rendering quality is related to the BITMAP_SWIZZLE setting used in different EAB versions.

In EAB v2.13/v4.0.1, the swizzle setting was:
BITMAP_SWIZZLE(ONE, ONE, ONE, RED)

In newer versions (e.g., v4.1.x / v4.2), the default is:
BITMAP_SWIZZLE(RED, GREEN, BLUE, ALPHA)

This difference can affect how the ASTC font bitmap channels are interpreted, which may result in the washed-out appearance.

If you would like to reproduce the same visual result as v4.0.1/v2.13, you can manually add:
BITMAP_SWIZZLE(ONE, ONE, ONE, RED)

before CMD_TEXT() or other font drawing commands.

If RAM_G space allows, R&D also recommends using a higher-quality ASTC format such as ASTC 5x5 to improve rendering quality.

The next version of EAB scheduled for release will reset to the previous BITMAP_SWIZZLE configuration for conversions.

Best Regards,
BRT Community

I am working on a project and needed a font, mostly for extra characters, but I also modified Roboto to have a dot in the zero.
Anyways, I noticed artifacts in the font. I am always using "exhaustive" and in "auto" the output log shows the format is ASTC_8x8.
As I did not recall having seen this before, I went back thru the EAB versions I have.
4.1.0 - exact same binary
4.0.1 - result is different, quality is better
2.13 - best quality with the same settings

Taking fotos from the display is not the best option and so I also used ESE to verify this - only to find that the result in ESE is different than on the display.

As a last step I set the mode to 4x4 which improved the quality even more. With this I do not see a difference between EAB 2.13 and 4.2.0 - the .glyph files are not the same though.
I have plenty of RAM-G left in this project, using a 136kiB .glyph file instead of a 43kiB .glyph file does not affect me for this project - but that is practially no compression.

I tried ASTC 6x6 with EAB 4.2.0 and the result is still good while the .glyph file went down to 57kiB. There are artifacts though if you look for them.

Looks like there is an issue with the EAB 4.x font converter, getting this level of artifacts on 8x8 is not what I am used to.
And I am also using a 792x792 image in the project that I converted to ASTX 8x8 with EAB 4.2.0. And there are almost no artifacts on it.

The command lines are:

eab_tools pre82x font -f extended -i ../Roboto-Subset_mod.ttf -o .../Font -s 26 -E ASTC -b 8x8 -e exhaustive -d 0 -R -u .../Fonts/!CharMap_UTF8_min.txt -S

eab_tools font -f extended -i .../Roboto-Subset_mod.ttf -o .../Font -s 26 -E ASTC -b 8x8 -e exhaustive -d 0 -x ".../EVE Asset Builder2/tools/astcenc.exe" -R -p -u .../Fonts/!CharMap_UTF8_min.txt -w

Ok, there is a small difference, EAB 4.2.0 uses the option "-S" and the end and EAB 2.13 has "-w", this appear to be options for eab_tools, "-w" does not seem to exist for eab_tools from 2.13 though.

Thanks for your reply.
I had similar ideas and did some checks along those lines as well.

PCLK seems to be OK and aligned with the display datasheet. I also tried changing it, but it didn't have any visible effect on the issue.
I checked the REG_UNDERRUN yesterday in both projects. In both cases it is increasing, but it looks like in the large display project it increments much faster. That could explain the observed problems — in the smaller display project I didn't notice anything wrong because everything appeared to render correctly.

I ran a few tests on a very minimal setup and everything works fine as long as I don't use fonts or large images from flash. For example(displaying form flash):

• 800×480 image in ASTC 12×12 works fine
• 580×480 image in ASTC 4×4 causes the underrun counter to increase, but the display still looks correct

For images this is manageable since I can load and display them from RAM_G, but the real issue is with fonts. I need a relatively large font with a wide character set, and my tests show that even a standard Calibri font at 45pt with only basic Latin characters already causes the underrun counter to increase.

Do you have any recommendations for handling larger fonts or fonts with more glyphs when reading from flash, without increasing underrun or causing display issues?

In my experience, using the external flash for display list contents is an issue. And it gets worse with higher resolutions.
The reason is simple, the bandwidth for the external flash is limited and the higher the resolution, the less time the BT817 has to fetch data.
And it gets worse with lots of random access reads when using fonts.

So, rule of thumb, avoid displaying from flash as much as you can, use it as a last resort. This does not render the external flash useless, you can still copy assets to RAM-G when you need them.

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMImportantly, the issue also occurs with minimal code using only CMD_TESTCARD(), which is sometimes stable and sometimes shows artifacts.

That might be two things, incorrect initialization or an electrical issue with unstable supply.

Which library are you using?
I am working on a project right now which uses a 10" with 1280x800 and BT817, I just changed my project to use CMD_TESTCARD on startup for five seconds. And while there was a slight flicker initially, this was from the supply still stabilizing. When I just reset without power down it does not happen and after I changed the code to initially wait 2s, it stopped, so electrical issue.

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMWhat is the practical maximum size/resolution of images that can be displayed smoothly on BT817 (especially when using ASTC 4×4 or assets from flash)?

Apart from that I recommend using ASTC 8x8 as I only observed artefacts beyond that, it is less the resolution as the amount of images and therefore the random accesses necessary per scan line.
Years ago I ran into issues when trying to display 64x64 color icons, the limit was like 12 from external flash - but this is 8kiB per image, there is not really a reason to load these from flash.

Right now I am using a 720x720 ASTC 8x8 in my project and since it is "only" 126kiB it just sits in RAM_G. For the last iteration of the project I was using three ASTC 8x8 with 624x624 each and rotated two of these, 95kiB each, RAM-G, no problem.

Last year I did a project in which I had to emulate a TV for a demonstrator, my task was to display pictures from one particular american football team on a 5" with 800x480, in the end I used two RAM_G buffers to copy the images to from the external flash, 96000 bytes per image. But I tried, the double-buffer was not even necessary, I only kept it as there is no use saving RAM-G. The copy with CMD_FLASHREAD was so fast that I did not notice any issues from switching the images while there were displayed.

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMIn flash FULL mode, is the SPI clock fixed by EVE, or can it be increased to improve throughput?

No, there is no API to change the flash clock, the only way would be to overclock the BT817 and that would also ruin the display settings, apart from other side effects that might occur.

Hmm, what clock speed is your BT817 configured to?

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMFor very large fonts (~400–500 pt), EVE Asset Builder seems to hit limits (glyph width issues) — what are recommended approaches to handle large fonts while keeping full character support?

500? Wow.
Yes, I am also getting a warning: "WARNING: Characters with widths exceeding 255 pixels have been filtered out."
The limit for the reduced character Roboto I used was 290px.
The full font lost a couple of glyphs, out of 901 "only" 856 got converted to the size.
But the Roboto-Regular_280_ASTC.glyph for that is 28.3MiB...
What do you mean by "keeping full character support"?
Tried 400px, the glyphs converted went down to 587 - 35.4MiB.

At this size a tile approach should make more sense, I am not sure though if there are actually tools for that.

The BT820 could probably handle that as a font.
It still has the same limitation, if that can be called a limitation.

The output from the font converter in EAB 4.2.0 is not the same though:
Characters submitted by the user: 901
Accepted characters for conversion: 587
   Success: 587
   Fail   : 0

The relocatable asset Roboto-Regular_400_ASTC.reloc needs to be loaded by
cmd_loadasset. It will take 37536544 bytes of RAM_G after decompression.

Font conversion is now complete!

That is an issue, EAB in BT82x mode just silently refuses to convert glyphs without telling why.

Hi Maciej,

Just one initial suggestion to check the PCLK polarity setting compared to your display datasheet as that can also lead to visual corruption.

One way to check if the issue is performance related (such as due to ASTC 4x4 assets from Flash) is to check the REG_UNDERRUN to see if it counts up. You can do a read of the register after you do the swap at the end of your new display list and print the value the next time round the loop via CMD_NUMBER.

Best Regards, BRT Community