BRT Community

Hi, I am still having this issue and it just made me publish my first youtube video ever.


Fortunately, while I had to rotate the display for my last project to landscape (EVE_cmd_setrotate(2) ), this was fine while EVE_cmd_setrotate(3; shows the same distortion.
Since the panel is IPS the viewing angle is the same from all sides anyways.

Hello, will this be made available later? Like on your Youtube channel?

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

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.

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.

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.

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.

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.

Just saw that EAB 4.1.0 is finally: out https://brtchip.com/eab/

While that is impressive, that does not really solve the availability of BT82x modules.
Yes, buying panels turned out to be a pain by itself, but usually that is a problem that can be solved with throwing money at it - thinking about single units here for evaluation or to play with, thinking in production level amounts I would send a suit from procurement to get me what I want (and I wish I was there).

However, the fun starts when adapting the panel to the VM820C - and the touch.
That is why I am also thinking about designing a board for the MN820.

So I prefer integrated modules.
And based on the experience with the VM820C so far, I would go for the option with 1GBit DDR3L and even no external flash (the option to solder a SOIC-8 would still be nice), as long as there is a micro-sd socket.

So, I got myself a ACD-110DHTT which is a 10.1" industrial touch monitor that I got used for only 23€ from
EBay, 1280x800.
The panel is a G101EVN01.0 from AUO, LVDS, single channel, 6 bits per color.
The display was fairly easy to adapt to the VM820C, but I gave up on playing with the eGalax touch controller.
I bought a 10.1" touchscreen digitizer on EBay for €6.99, I selected this one for clearly having a controller chip visible on the supplied fotos, although I could not identify the specific chip.
Some other parts that are sold do not have a touch controller integrated and apart from no chip visible these have way more pins on the cable than the 6...12 you will find with a touch-panel + CTP combi.

The one I bought was advertized as replacement part for a "ICOO ICOU10G 10.1 inch" tablett and also is labeled as "ENERGY Neo" - getting of one of these tabletts might be interesting.

Anyways, the digitizer arrived and the touch chip turned out to be a FT5506 - bingo.
I used a 12pin FPC adapter to connect to CN8 on the VM820C.

Oh, btw., the 7" I was using before had a FT5316.

Unfortunately the touch digitizer does not match mechanically, it is wider in X and smaller in Y.
So I just taped to the outside of my display.

I calibrated the thing and now I have working touch.


I am thinking about designing a minimal adapter board for the MN820.

Yes, the 15.6" really is some large unit of a monitor, I have no idea why that is still the only option.
I am generally interested in buying a RVT156HKBNWCA0-B, despite the price and despite that I have no idea what to actually do with it.

I do have a couple of issues with it though that I asked Riverdi about and I did not get an answer.

First of all the backlight, that cable that is sticking out to the side on the top.
Why? If I would order displays in any meaningfull quantity, I would tell the supplier to redesign that.
Riverdi did the same with the 12.1", which is one of the reasons I never bought one.

My second issue with the RVT156HKBNWCA0-B is the barrel connector to supply it.
Not only is a barrel connector not locking, that thing has a height of 11mm.
I would have preferred a 662102145021 from WE or a 505578-0271 from Molex.

So, yes, I would buy a 10" version, or even a 12.1" version if the backlight connection is fixed.
And I would opt for a way smaller external flash, like 64MBit, using the external SD card is nice.
Same with the DDR3 SRAM, 4GBit seems excessive.

What's up? 
It has been three weeks again since the last post while there are 75+ daily visistors listed.

I implemented all of the BT822 patch functions, or at least these that are documented so far.
Actually testing these still is difficult since the new EAB has not been released.

I would like to buy a BT82x based display module, but the options are still very limited.

Today I received a ACD-110DHTT which is a 10.1" industrial touch monitor that I got used for only 23€ from EBay, 1280x800.
And of course I only took it apart, really nice build quality, the case is machined from a block of aluminium, I do not want to know how much these cost before they were phased out back in 2019.
The panel is a G101EVN01.0 from AUO for which I even found a datasheet, LVDS, single channel, 6 bits per color.

The touch is a separate unit and will provide more challenges, it uses an eGalax Touch controller.
On the outside the interface is USB, but it does support I2C as well.


Now, what is everyone else here up to?

Edit: I really have no idea why this site is practically dead, 144 views of this post and no reaction?
Ok, stay positive. :-)


I just spent some time to check the wiring of the ACD-110DHTT and adapt it the VM820C.
As it turned out, the wire harness of the display is using the exact same 6 pin / 2mm header for the backlight than the VM820C, I only had to swap two pins. 
And for LVDS the wire harness connects to the conroller board with a 32 pin / 2mm header which uses the same crimps than the 30 pin / 2mm headers I have for the LVDS TX of the VM820C.
The pinout was slightly different, but taking out the pins from the old header and putting it in the 30pin header was really easy.

Next I put in a 1280x800 profile, checked the data format, which is JEIDA / Format 1 for 18-bit RGB, checked the clock frequency range and configured REG_LVDSTX_PLLCFG accordingly.
And, yeah, it worked on the first try. 
Even the backlight control is working, as the panel has the backlight controller integrated and takes a PWM signal to control it.

I do not have touch, did not even try to connect it, so far I have no idea if the eGalax touch controller is compatible to anything the BT820 supports.

I realized it has been a while since I updated this blog, hrmm, thread. :-)

I was discussing the LVDS input over on Github and to make that short, turned out that PCB800099 I bought is garbage, or at least the firmware on it for the RTD2660H is garbage.
The HDMI input is not working.
At least the OSD was working, but only for a few seconds and then it froze.

So I bought an inexpensive AV camera: "Car HD Reversing Camera" - mostly lies in the product description, as expected.
I tore it apart and found an analog camera module with 3.3V supply inside.
I soldered that to the AV2 input of the PCB800099 and since then I have continuous video input without freezes, sort of, the video is rather distorted and the PCB800099 reports "NTSC" for the input.

Whatever, the LVDS input to the BT820 is working fine now.

Fast forward, I am exploring the ability of the BT820 now to patch the firmware with both updated functions and additional functions.

I implemented CMD_LOADPATCH and copied a bunch of patchfiles to the SD card I am using with the VM820C.
EAB 4.1.x will have a new panel to supply these patches, but that is not yet released, so I converted patches from the BRT repositories to .bin.
And I just noticed that the "patchb2tf" that is shown in the screenshot is outdated, the patch_b2tf2.py this is taken from was updated a couple of days ago.
So I just updated my patch and to make a second screenshot more interesting, I also implemented CMD_SEVENSEG - only to find it not working properly which I will report next on Github.