BRT Community

Hello Jerome,

Thank you for your question.

On the following:

Quote from: jipihorn on October 08, 2026, 01:34:05 PMHowever, whatever value I put here, I still get other interrupts like INT_SWAP or INT_CMDEMPTY.

Can I ask if you are seeing the INT_N pin assert for INT_SWAP or INT_CMDEMPTY, or are you simply reading the REG_INT_FLAGS register and seeing these flags are also set when for example a INT_TOUCH interrupt is triggered?

The REG_INT_FLAGS register keeps track of the available interrupt sources on the IC, and will set the flag accordingly for each source irrespective of the flags being masked by REG_INT_MASK. When REG_INT_EN is 1, INT_N is driven low when any of the interrupt flags in REG_INT_FLAGS are high, after masking with REG_INT_MASK. Basically the flag will set for a given interrupt source when the given scenario for that flag happens, the mask is then used to tell the INT_N pin which flags it should assert for.

Best Regards,
BRT Community

Hello,

Thank you for the update!

We are glad to hear that EAB 4.5.0 is working well for you now.

Best Regards,
BRT Community

Hi Rudolph,

Neat design and thanks for sharing, we look forward to seeing your finished design,

Are you going to attach your board to the back of the VM820B10A module?

Best Regards, 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