BRT Community

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.
ESE 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.

Thanks for the update, I will keep an eye out for it then and play in the meantime with the few patches I found before in your repositories.

Hello,

I just found this:
https://brtchip.com/wp-content/uploads/2025/08/BRT_AN_095_BT82X-Firmware-Update-and-Extension-Guide.pdf

Nice, I was expecting something like this.

But the referenced patches are not available yet as an not yet released EVE Asset Builder is supposed to provide these in a new EXTENSION tab.
Please attach a full .bin here in the meantime for testing, the base patches and all extension patches in one binary.
Or, if that needs to be handled separately for some reason, the mentioned base_patch.bin plus a binary with all extension modules.

I would just drop that on the SD card for the BT820.

Thanks, so it was the "Display list instruction overfetch".
I even already had BRT_TN_005_BT81x_Errata_Technical_Note.pdf.

I just was not looking under https://brtchip.com/document/technical-notes/ , maybe add (Errata) to that one as well?

Oh, and another small thing, "Programming and User Guides" is sorted by date, newest on top, could that perhaps be done on "IC Data Sheets" and "Application Notes" as well?

I recently found this:
https://brtchip.com/wp-content/uploads/2024/04/Errata-notification-2024-R2.pdf

It states:
"We are reaching out to notify an important Errata that has been identified on our BT81x / BT88x series. This
Errata pertains to specific user applications, which may affect the functionality or performance of the product
under certain conditions."


What this does not state is what the actual issue might be.
So, what is it?

Given the date of release this could appear in a version of BT81X programming guide later than 2.4.
But I don't see anything in the 2.5, 2.6 or 2.7 history that indicates an issue.

I vaguely recall seeing extra DISPLAY commands added to the end of the command list to address some issue, is this related to this erratum?

The PCB800099 has arrived and five minutes later I realized that I am not prepared.
I need a cable with 2mm 30pin headers on both side.
And checking the pinout of CN2 on the VM820C and the LVDS pinout on the PCB800099, these are almost the same, except that polarity is different for all signals, so _P and _N swapped.

Unfortunately 30pin to 30pin LVDS cables apparently are rare, could not find any for speedy delivery, looks like I will be soldering tomorrow...

Edit: looking for information for the PCB800099 I came across a list on Alibaba.com for exactly the board I have with the exact same silkscreen and the "30P LVDS Interface connector: Pin definition:" contradicts the silkscreen - oh dear.

Ah, thanks, I have seen this document, but not the update.
I could not find boards with the RTD2513 in my last search I did, only from AliExpress, found two on EBay now as well which did not show before.
I bought a board with a RTD2660 which hopefully arrives by the end of july...
I was about the but one with the RTD2513 as well but it would be delivered in august, damn lazy bike couriers. 

And in regards of the video source, my issue is more with the budget I am willing to spend on this, when you have no application, a camera for 50+ bucks is kind of expensive. 

But looking at stuff like small video players, I just remembered that I have a RaspberryPi Zero somewhere in the office that I bought years ago and never used for anything.
And I just found that there is a RP2350-PiZero from Waveshare, only found it on AlixExpress though.

Edit: I just learned that the PCB800099 I ordered with the RTD2620 has an OSD and delivers a blue screen with a "No Signal" message, getting this to display by the BT820 would be a good start.   

That indicates that you did the touch calibration without rotation.
Either use CMD_SETROTATE which also adjusts the touch transform matrix, or calibrate the touch after setting REG_ROTATE.

Edit: damn, 35s too slow because I had to get up and turn off the washing mashine. 

Quote from: Matrix Orbital on July 09, 2025, 09:46:07 PMFrankly trying to figure out what the point of this new EVE5 is.

Yes, I get that.
I wondered what the target is the BT820 was designed for.
But then I am nowhere near anything that could be considered a business case. :-)

Definately an upgrade over the BT817.

I would buy a 12" just for the heck of it, the 15.6" that was advertized, if that is the only option.
But no idea what to actually do with these.
15.6" is an absolute unit of a freaking monitor, if you are doing embedded.

Heck, just today I finished another CAN-Display for a demonstrator using an EVE3-50G.
Unfortunately still no EVE4-xx in my collection and no feasible way to buy one that I know of.

I could totally see the BT82x replacing the BT81x for resolutions beyond 800x480, but even a 5" with 800x480 would work for me if that meant at least getting the SD card interface.
The board complexity that the BT820 requires might be a bit much for anything less than 10".

Quote from: BRT Community on July 10, 2025, 02:27:28 PMOur new BT820B combines the many benefits of our earlier EVE devices (including their graphics, touch and audio capability) with even more powerful graphics capabilities.
- Directly drive large LVDS panels up to 1920 x 1200 e.g. 15.6" panels
- Use high-resolution live video in your UI easily, and without it passing through the MCU
- Pre-processing to add effects and improve the video stream without MCU workload

Well now, I still have not managed to find a LVDS video source for the VM820C.
I just ordered a AT070TN909294 which converts HDMI or VGA to LVDS or TTL, practically a board that you would expect to find in a monitor.
I am not sure if I can actually use it though, it will be interesting to tinker with.
And I bought a USB/HDMI adapter as my graphics card "only" has a DP free for use, but it turned out to be falsely advertized garbage that does not work with Win11.
I am considering to use a RP2350 to generate the HDMI output to play with.
As I only have a 1024x600 display I would like to use a video source with a reslution lower than that.

Buying a camera turned out to be tough.
The simple ones use MIPI-CSI or USB and MIPI-CSI to LVDS converters do not seem to exist.

So, "live video" "easily" is something I can not confirm at this point and without input to play with there was no exploring for me what could be done with the video.

Well, I do not have an application for video input, for me personally a BT82x with reduced features would do, embedded DDR3, no LVDS input, no flash interface in favour of the SD card interface.
But again, no business case, unfortunately, would love to work on products that sell in numbers, would make sourcing displays a lot easier. 

Both the NHD-7.0-800480AF-LSXP-CTP and the RVT70HSLNWC00 should work.

Adapting either of these to the VM820C is a bit of a challenge though.
The 30-position 2mm header CN2 on the VM820C has no pins for the backlight-LEDs.
And the pins for the backlight-controller on the VM820C are only connected to CN4.

The 45-postion FFC header CN4 is not compatible with the display connectors and is missing a couple of signals, so you need an adapter board to connect to either of these.

Connecting to the NHD-7.0-800480AF-LSXP-CTP might be a bit easier as it does not require VGL and VGH signals, but the RVT70HSLNWC00 does.

Both display have a 40pin FFC connector and the pinout is almost the same.
The NHD-7.0-800480AF-LSXP-CTP however deviates a little from one of the de-facto standard pinouts and has LED-K on pins 36/37 instead of 31/32.

The RVT70HSLNWC00 could be connected to a PCB800182 LCD adapter which I also used to connected my 1024x600 7" to, I reverse-engineered these adapters here: https://github.com/RudolphRiedel/PCB800182_LCD_Adapter
See above in this thread, I ended up not using the backlight-controller on the VM820C.

Now for the touch controller, both should work with the BT820, logically.
However, the NHD-7.0-800480AF-LSXP-CTP is using a 6-pin FFC that is not compatible with CN9 on the VM820C.
And RVT70HSLNWC00 uses a 10-pin FFC.
-> you need adapter boards to connect to either CN9 on the VM820C, or, what I found easier to do, connect to CN8 on the VM820C with wires using a cheap generic FFC breakout board on the display side.


Yeah, I wonder what the holdup is, I would be in the market for a fully integrated BT820 display module.

polo? 

Ok, with the post from marketing, I kind of have to ask. :-)

I saw the IDM2040-21R a while ago and found it interesting.
Round, IPS, capacitive touch, rotary dial.

A bit too small for me, 2,1" is 53mm in diameter, but unfortunately this seems to be the upper end of round displays.
I also found 3.4", but only with MIPI DSI.

However, the FT800 puzzles me.
Why does the IDM2040-21R use a FT800?
The FT800 does not even use capacitive touch, it is the resitive touch variant, so the firmware needs to be patched. Why not use a FT801?

And then, why not use a BT881?
The FT800 could be used with I2C instead of SPI, but it is connected by SPI on the IDM2040-21R.
The BT881 would be a drop-in replacement with GPIO2 on pin 10 instead of MODE.


And personally, the RP2040 is a bit of an odd choice for me.
This controller has close to nothing that would make it exciting, except maybe, the PIOs which are not used here.
And so the IDM2040-21R has I2C or RS485 as communication interface and neither would the interface I would choose to run things thru my home.
Ah yes, there is USB, but that is an even worse fit for home automation.

I would rather go for a small controller that has a CAN-FD interface, like an ATSAMC21E - which could also do RS485 and I2C.
Or use an ESP32 and add WLAN, but you need to run a cable to the unit anyways and there are already enough things in our homes sending out radio waves.

A modular approach with a second PCB on top of the EVE PCB would help with size limitations.
And would not only make more room for more features, but also would add the flexibility to use different controller boards.

I implemented High Level Analyzers for Saleae Logic 2: https://github.com/RudolphRiedel/Saleae_Logic_HLA
There are two variants, EmbeddedVideoEngine is for FT81x/BT81x and EmbeddedVideoEngine5 is for BT820.

Not perfect or complete, but well, it decodes some stuff, when saving the .csv from the trace I get extra data like this for BT820:

BOOTCFGEN   
SETTBOOTCFG   
SETDDRTYPE   
BOOTCFGEN   
SETPLLSP1   
SETSYSCLKDIV   
ACTIVE   
READ REG_BOOT_STATUS   Decompressing rom asset image to DDR
READ REG_BOOT_STATUS   Attempting to attach to flash
READ REG_BOOT_STATUS   Normal running
WRITE REG_PWM_DUTY   0x00000020
WRITE REG_HSIZE   0x00000400
WRITE REG_DISP   0x00000001
WRITE RAM-DL+0x0000   DL_CLEAR_COLOR_RGB  0x000000
WRITE RAM-DL+0x0004   DL_CLEAR  0x000007
WRITE RAM-DL+0x0008   DL_DISPLAY  0x000000
WRITE REG_DLSWAP   0x00000002
WRITE REG_SO_EN   0x00000001
READ REG_CMDB_SPACE   0x3FFC
WRITE REG_CMDB_WRITE   CMD_INFLATE
WRITE REG_CMDB_WRITE   0xD8E5DA78
READ REG_CMDB_SPACE   0x3F6C
READ REG_CMDB_SPACE   0x3FFC
WRITE REG_CMDB_WRITE   CMD_LOADIMAGE
WRITE REG_CMDB_WRITE   0xE0FFD8FF
READ REG_CMDB_SPACE   0x3FFC
WRITE REG_CMDB_WRITE   CMD_NEWLIST
WRITE REG_CMDB_WRITE   DL_TAG  0x000000

BRT_AN_086_BT82X-Series-Programming-Guide is out in version 1.1 and I am going over it now.

Here are my observations:

1) The memory region RAM_ERR_REPORT was renamed to RAM_REPORT.

2) The "BT82X data flow" was updated and one detail is that RAM_CMD and RAM_DL are documented to use SRAM.
Which has no user-level implications, but makes me wonder if the whole region from 0x7F000000 to wherever is SRAM.

3) RAM_G is documented to go from 0x00000000 to 0x7EFFFFFF, DDR3 "only" goes to 8Gbit, so RAM_G can "only" go to 0x3FFFFFFF.
4) Host command RESET_PULSE was added.

5) The Initialization Sequence given in the programming guide is different to what the Bridgtek examples are using.
https://github.com/Bridgetek/Eve-MCU-Dev/tree/bt82x-dev
https://github.com/Bridgetek/python-bt82x-dev/tree/development

Not fundamentally, but this is still a bit strange.

from EVE_HAL.c:

// Reset the display
MCU_Delay_20ms();
HAL_PowerDown(1);
MCU_Delay_20ms();
HAL_PowerDown(0);
MCU_Delay_20ms();

// Set System PLL NS = 15 for 576MHz
HAL_HostCmdWrite(0xFF, 0xE4, 0x0F, 0x00, 0x00);
// Set System clock divider to 0x17 for 72MHz
HAL_HostCmdWrite(0xFF, 0xE6, 0x17, 0x00, 0x00);
// Set bypass BOOT_BYPASS_OTP, DDRTYPT_BYPASS_OTP and set BootCfgEn
HAL_HostCmdWrite(0xFF, 0xE9, 0xe1, 0x00, 0x00);
// Set DDR Type - 1333, DDR3L, 4096
HAL_HostCmdWrite(0xFF, 0xEB, 0x08, 0x00, 0x00);
// Set DDR, JT, AUD and WD in Boot Control
HAL_HostCmdWrite(0xFF, 0xE8, 0xf0, 0x00, 0x00);
// Clear BootCfgEn
HAL_HostCmdWrite(0xFF, 0xE9, 0xe0, 0x00, 0x00);
// Perform a reset pulse
HAL_HostCmdWrite(0xFF, 0xE7, 0x00, 0x00, 0x00) ;
// Set ACTIVE
HAL_HostCmdWrite(0x00, 0x00, 0x00, 0x00, 0x00) ;

// Delay ~100 mS
for (i = 0; i < 5; i++)
{
    MCU_Delay_20ms();
}


The order should not really matter, but I do wonder why RESET_PULSE is in there and why it is placed directly before ACTIVE.

6) REG_LVDSTX_PLLCFG
Following the updated register description for REG_LVDSTX_PLLCFG my code works now.
LVDSPLL_NS went from "Progammable loop divider" to RESERVED with a fixed value of 7, whatever this actually does.
And "Table 21 - LVDSTX Clock Configuration" also has "(scanclk_2x / 2)" under "LVDSTX clock (MHz)".

So, the multiplier is actually the system-pll multiplier which means that for the pixel clock you can only setup 576MHz / (TXLDVIV + 1) - unless you change the system-pll multiplier.
That is pretty bad in regards of the resolution of the pixel-clock, especially after the BT817.
The target for the 1024x600 I am currently using is 51.2MHz with min = 45MHz and max = 57MHz.
And practically the only options are 48MHz or 57.6MHz, as I really do not like the idea of lowering the system clock.
800x480: >25.2/25.4/37.2MHz -> set TXCLKDIV = 10 for 26.2MHz
800x480: >23/25/27MHz -> set TXCLKDIV = 11 for 24MHz
1024x600: >45/51.2/<57 MHz -> 48MHz
1024x768: >52/65/<71 MHz -> 57.6Mhz
1280x720: >57.1/58.1/85MHz -> 57.6MHz or 72MHz
1280x768: >55/60/<65 -> 57.6MHz
1280x800: >66.3/72.4/78.9 MHz -> 72MHz
1366x768: >66.9/72/<80 MHz -> 72MHz
1366x768: >63/76/<96 MHz -> 72MHz

Ok, getting these to work would not be an issue, only hitting 60Hz might.
And no, I do not have these, sourcing inexpensive displays with touch is still a major pain.

7) REG_TOUCH_MODE was removed from the Programming Guide
8 ) Microchip and TI touch controllers were removed from REG_TOUCH_CONFIG
9) REG_CTOUCH_TOUCHn_XY registers are still named 0/A/B/C/4 and not 0/1/2/3/4.
10) new register: REG_LVDSRX_CORE_FRAMES - LVDSRX frame counter - 8 bit value
11) REG_SYS_STAT had bit definitions removed
12) REG_I2S_CFG definition has LENGTH removed, 16-bit is the only supported format
13) REG_GPIO_DIR Bit 15 – 9 changed from "Unused" to "These bits control the direction of GPIO8 to GPIO15." -probably was meant to say GPIO9 to GPIO15
14) REG_GPIO Definition Bit 15 – 9 changed from "Unused" to "General purpose Input/Output pins"
15) The description for REGION has been greatly improved, but there still is no warning that the "dest" parameter is absolute which prevents display list fragments that were built from commands like CMD_TEXT to be used with CMD_APPEND since the translation to display list commands by the co-processor uses REGION for a couple commands now and the generated snippet is very unlikely to be placed at the exaxt same display list address.
16) the C prototypes of several commands are still wrong and use int16_t instead of uint16_t for parameters like width, height, radius and font which must not be negative
17)  the C prototype of CMD_TEXTDIM still has this: void cmd_text( uint32_t dimensions ...
18 ) I only briefly checked this, but it looks like the inconsistencies I reported here: http://www.brtcommunity.com/index.php?topic=585.0 are still in place


Oh yes, what I did not mention so far is that there are indeed numerous improvements in the 1.1 version of the BT82x programming guide.
For example the explanation of the Swap Chains.