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

Hello,

Thank you for your post.

Quote from: ashrey on December 09, 2025, 06:05:55 PMAs the other thread asks, it also appears that the ST7789V needs to be configured via SPI before it will work in RGB mode, but then after that, SPI communications to the display are no longer needed, is that correct?

Yes, generally this is correct for such parts (but please verify the in the datasheet) that you would configure the display driver during boot, and once this ahs been completed you wouldn't communicate with it again. After which you can perform the FT81x initialization routine.

For reference, here is some example code that would be called for the ILI9488 configuration on the ME810A-HV35R:
https://github.com/Bridgetek/EveApps/blob/master/common/eve_hal/EVE_ILI9488_FT9XX.c

In regards to the configuration of parts such as the ST7789V, there are two approach's you can utilise.

• The first approach would be to utilise the SPI interface on your MCU to perform the configuration, using a spare CS# signal.

As noted in the previous thread you can get an example of the hardware we use in the ME810A-HV35R datasheet.

But it would also be acceptable to use the approach you has suggested to MUX the CS# line to the ST7789V and the FT811 and control this via a GPIO.

• The second approach would be to bit bang the configuration data from your MCU over spare GPIO pins if you have these available.

This would remove the need for the MUX IC if you have some spare GPIO pins available.


Best Regards,
BRT Community