BRT Community

Hi,
I'm working with BT817 (STM32 + EVE-MCU-Dev) and multiple displays. On a 480×272 panel (PH480272T015-IAA15), everything works reliably — ASTC images from flash, fonts, stable rendering.
After moving to larger panels (MI0700COT-1 800×480 and LMT070WS027C 1024×600), I'm seeing unstable and non-deterministic behavior. The initialization and overall approach are analogous, but results are inconsistent. Depending on reset, the display may work correctly or show flickering, corrupted fonts/images, or ghosting (previous screen content partially visible).
Importantly, the issue also occurs with minimal code using only CMD_TESTCARD(), which is sometimes stable and sometimes shows artifacts. This suggests the problem is not related to display lists or assets.
Given that even testcard is affected, I suspect RGB timing (porches/sync), PCLK (frequency/polarity), CSPREAD, possible underruns, or signal integrity issues at higher pixel clocks. I've tried multiple timing configurations (both from datasheets and library defaults) as well as different PCLK settings, but without consistent improvement.
Has anyone seen similar behavior when moving from 480×272 to higher resolutions? Are there known-good timing settings for these panels?

Additionally, I have a few related questions:

• What 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)?
• In flash FULL mode, is the SPI clock fixed by EVE, or can it be increased to improve throughput?
• For 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?

Any suggestions or best practices would be greatly appreciated.
Thanks!

🚀 Just 1 more day to Embedded World 2026 in Nuremberg, Germany!
Join us at Hall 4A / Booth 4A-100 and experience our live demos showcasing the future of Graphics UI with EVE technology.
Don't miss the chance to see innovation in action — we look forward to welcoming you!

So, anything? 

Well, see you at Embedded World in Nürnberg. 
I have my train ticket, I plan to attend on wednesday, might check out your booth around 1pm.

Hi Rudolph,

We have one of those modules available now so will give it a try here and let you know if we can see it happening,

Best Regards, BRT Community

Challenge Date : 12 Jan – 31 May 2026

Mission: Create an impactful project on the EVE platform.
Prize: Bridgetek Evaluation Kit +15.6" display
Action: Show us your creativity—bring your ideas to life!

Submit your Project : https://42bmw.share.hsforms.com/2t2Ic1en9SEKxbwRMKdLebg

This issue just came back to me: https://github.com/RudolphRiedel/FT800-FT813/discussions/163

I reduced my display list to this:

EVE_cmd_dlstart();
EVE_clear_color_rgb(WHITE);
EVE_clear(1, 1, 1);
EVE_tag(0);
EVE_color_rgb(BLACK);
EVE_cmd_number(100, EVE_VSIZE - 65, 26, EVE_OPT_RIGHTX, cmd_fifo_size);
EVE_cmd_number(100, EVE_VSIZE - 50, 26, EVE_OPT_RIGHTX, display_list_size);
EVE_cmd_number(104, EVE_VSIZE - 35, 26, EVE_OPT_RIGHTX|6U, num_profile_a);
EVE_cmd_number(104, EVE_VSIZE - 20, 26, EVE_OPT_RIGHTX|6U, num_profile_b)
EVE_display();
EVE_display();
EVE_cmd_swap();

And with EVE_cmd_setrotate(0); the text is fine, with EVE_cmd_setrotate(1); it is barely readable.
With EVE_cmd_setrotate(2); it is fine.

The display settings I am using:
#define EVE_HSIZE (1280L)
#define EVE_VSIZE (800L)
#define EVE_VSYNC0 (0L)
#define EVE_VSYNC1 (10L)
#define EVE_VOFFSET (23L)
#define EVE_VCYCLE (838L)
#define EVE_HSYNC0 (0L)
#define EVE_HSYNC1 (20L)
#define EVE_HOFFSET (88L)
#define EVE_HCYCLE (1440L)
#define EVE_PCLK_FREQ (0x08C1U) /* value to be put into REG_PCLK_FREQ -> 72MHz, REG_PCLK is set to 1 */
#define EVE_SET_REG_PCLK_2X
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 4
#define EVE_BACKLIGHT_FREQ (4000U)


Is there anything I can do to fix this?

To add a minor detail, FT8xx and BT81x "only" support 32 bitmap handles, so 0 to 31.
15 is used as a scratch bitmap by a couple of commands.

BT82x has 64 bitmap handles and 16 to 34 are assigned to the fonts.
Unfortunately it still uses the same fonts, but at least there are all directly useable.

Hi,

For these fonts, it is required to use CMD_ROMFONT. Please see section 5.70 in the Programming Guide for examples.
https://brtchip.com/wp-content/uploads/2025/07/BRT_AN_033_BT81X-Series-Programming-Guide.pdf

Here we set the font 34 to user handle 1.

cmd_romfont(1, 34);
cmd_text(60, 32, 1, 0, "34");

Hope it helps, Best Regards, BRT Community

Hi,
I'm working with a BT817 and I've encountered a strange issue with ROM fonts.
According to the documentation, the BT817/8 has built-in ROM fonts with handles 16–34, and fonts 31–34 are large ROM fonts encoded in ASTC 8x8 format.
However, on my system:
EVE_CMD_TEXT(20, 10, 31, 0, "BT817 Flash Image");  // works
EVE_CMD_TEXT(20, 10, 32, 0, "BT817 Flash Image");  // BT817 freezes
Font 31 works correctly, but as soon as I use font 32 (or any handle >31), the BT817 co-processor appears to hang (command FIFO stops progressing).
External flash is working correctly and is in FAST/FULL mode — I can read images from it without any issues.
I'm not sure whether I'll actually need these ROM fonts since I'll probably use custom fonts anyway, but I'd like to understand whether this is a known issue, a configuration mistake on my side, or possibly a silicon/firmware bug.
Thanks in advance for any advice.

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