BRT Community

Hi Rudolph,

Thanks for your feedback and observations,

We'll review with our R&D team and standardise the recommendation and will keep you informed of the updates on this,

Best Regards, BRT Community

Hello Jerome,

Thank you for your question.

It is common for portrait displays to take larger LCD panels and effectively 'cut' these down to the desired size. As you have noticed this results in some 'hidden' pixels being clocked to the screen where the original LCD pixels would have been. This happens because the display driver on the LCD panel usually expects to be driven with the RGB/timing signals for the size of the original LCD panel to ensure the pixel data is latched correctly onto the remaining pixels.

Typically the datasheet for the LCD will provide the timing details for the original display panel size (in your case 360x960). And these are the settings that the BT817 display registers should be configured to use.

However as the BT817 in such a case is clocking data out for pixels that are not physically present on the LCD panel, this can affect where the (0,0) point is on the screen depending on the orientation of the remaining pixels on LCD panel. In your case it sounds like the have remove pixels on the left hand side of the original LCD panel (in portrait orientation), these would be the first to be clocked out by EVE. so in a sense what you see as the (0,0) point on the screen is actually (120,0) in regards to the RGB signals being clocked to the display.

There is no register setting similar to REG_ROTATE which would adjust for this, however it may be possible to adjust the display timing settings such as HOffset or VOffset to shift the RGB signal clocking to align with the pixels available on your display. Please note however this is not possible with all LCD panels.

The best approach to mitigate this behaviour in this case would be to add an offset in code, by either:

• Using a global variable with your required offset and add this to all of positioning variables used in your display list
• Or calling VERTEX_TRANSLATE_X and/or VERTEX_TRANSLATE_Y at the beginning of your display lists to let the BT817 compute the required positional change for placing items on the screen

Best Regards,

BRT Community

Yes agreed, the zlib compression would reduce storage on the SD card (or MCU flash) but still needs to be inflated to the original size in RAM_G to display it.

As you mentioned, it is good to encode the properties as they are not encoded. Unlike some specific formats such as png, the zlib can be used for different types of file and so does not have the full properties encoded inside.

Best Regards, BRT Community

Hi Toby,

Could you advise what type of images you will use? Are they full photos or mainly logos etc.

Normally if you would like to use images directly we would suggest png or jpg and then inflate via CMD_LOADIMAGE. However, png normally decompress to a format such as RGB565 (full colour) or ARGB4 (if image has transparency) which give good quality colour images.  Both of these take 2 bytes per pixel and so the image would be bigger than then RAM_G.    Mono png images would be L8 (1 byte per pixel) or in some cases an indexed image may be palleted. However, if you want to allow users to use most images without too many restrictions it would likely be the 2-bytes-per-pixel formats.

1024 x 600 x 2 = 614400 x 2 = 1,228,800 and so more than the 1MBytes RAM_G

If your image is a logo then you may be able to load it as smaller one with a background colour defined by EVE, or you could consider to load and scale up a slightly smaller image.

ASTC would be ideal for this but if you want to avoid the conversion then these options above may be good.

If you could send details of the typical image style we can see what else we can advise thought too,

Best Regards, BRT Community



 

Hello Redolph,

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

Best Regards,
BRT Community

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

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

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

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

Our R&D team will be updating the tool to use the latest driver and we'll let you know when the version is released,

Best Regards, BRT Community

Hello,

Thank you for the update, I'm glad to hear that you have managed to get the conversion to work via the command line.

Yes the -q option in ffmpeg.exe relates to the quality of the conversion:
-q q                use fixed quality scale (VBR)
Best Regards,
BRT Community

Hello,

Thank you for sharing the source video file.

Unfortunately the development team were not able to recreate the issue on their test machine.
They have asked for some logs of the EAB conversion process

QuoteCan we recommend the user open EAB's command prompt (by clicking the bottom button in left-side panel), run these command lines in turn and share the result log:

eab_tools video -i path/to/VAN.mp4 -r 798:450 -o "path/to/output" -q 4 -s 48000 -f 3 -c MIX -t 29.97

ffmpeg.exe -i "path/to/VAN.mp4" -threads 16 -hide_banner -y -s 798:450 -pix_fmt yuvj420p -r 29.97 -c:v mjpeg -q:v 4 -c:a pcm_s16le -ar 48000 -ac 1 "path/to/output/VAN.avi"

Best Regards,
BRT Community

Great to see your new module with Power Delivery support

We'll request our R&D team to update the DLL in our software tools to the latest one so that your PD-based will work and we'll let you know here when it is available,

Thanks for reporting this,

Best Regards, BRT Community

Hello,

The SW team are requesting a copy of the source video for the conversion.
Would you be able to share a link to an upload of the video file or alternately email in a copy to support.emea@brtchip.com?


Best Regards,
BRT Community

Hello,

Thank you for the details, i have shared these with the SW development team, and i hope to be back with an update soon.

Best Regards,
BRT Community