BT82x

[Rudolph]

Ok, this got lost in the forums update, so I am trying to re-post.

On the programmers guide point, this is currently going through the final review stages and we hope to have it released shortly.

Hmm, how do I put this in writing? Just remember that I am not in a bad mood over here.
I has been over three weeks now with me checking every day if there had been an update.

And I was promised answers to my questions but this thread practically went on as a blog with close to no answers.
In the meantime you use for example the undocumented host command E7 in your own code - which I had not seen when it was put in 5 months ago since I try to barely look at your code, following the mantra that if it is not documented, it does not exist.
This is a tad bit frustrating.

Well now, there still is an unfortunate lack of available ready-to-use EVE5 display modules, none to be precise and I wonder why that is.

Anyways, here is something for the FAQs, maybe:

Can I use the dual channel LVDS output of the BT820B with two single channel LVDS displays?

No, first of all the output in dual-channel mode is interleaved, so one channel is sending the even pixels, the other channel is sending the odd pixels.
Then there is only one clock setting and one set of REG_SO_ registers, so even if the scanout engine could be convinced to output non-interleaved, it could only output the same information in parallel to two LVDS channels, so the same image on two identicle displays.

Is this an accurate assesment?
There is more, but this is probably enough on the question of using two displays with the BT820B.

[BRT Community]

Hi Rudolph,

Sorry for the delayed reply, Our new Programmers guide will be ready soon,

You are correct, the LVDS output is for one display only. We use two channels to allow us to support the high resolution panels such as 1920 x 1200, but the two channels work together to provide the bandwidth required. Therefore, they are not designed to support two separate display panels on one BT820B IC.

Best Regards, BRT Community

[jori]

What's happening with BT822 ?

[Rudolph]

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:

Code Select Expand


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

[maria@dsg-id.com]

Good morning:

I am beginning to investigate the BT820 to change the micros that we have ft-813 and bt817, found the vm820c development board, the only thing that today not found a screen that can connect, I could give me examples I would be interested to start one in 7 "but if there is not and there is 10" there would be no problem.

Edition: I found by researching a little on my own that these two models could be compatible:

1.- RIVERDI/SOMLABS SL-TFT7-TP-600-1024-LVDS
2.- NEW HAVEN NHD-7.0-800480AF-LSXP-CTP

If they are really compatible, could you please specify which one would be better.

Thank you very much

Translated with DeepL.com (free version)

[Rudolph]

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.

[Matrix Orbital]

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.

Frankly trying to figure out what the point of this new EVE5 is.

[maria@dsg-id.com]

Hi Rudolph:

Thank you very much for your clarification, the problem is that there is still no module integrated with the BT820, on the RIVERDI page it announces that one is coming out but with a 15'' screen but they don't say for when, and I need to start studying this micro.
Before buying anything I'm going to pass to my hardaware department what you tell me about the screens and they will look at me to see which is the best fit to start working.
Thank you very much

[BRT Community]

Hi Rudolph, Maria,
 
Thanks for your inputs on these items, please note that there will be some integrated modules coming soon for BT820B and so we'll keep you posted here.
 
Hi Matrix Orbital,
 
We have to say, the ability to make a stunning full-colour touch-enabled GUI on an LVDS 15.6" panel with high-resolution images and fonts, touch icons overlaid and live video (with pre-processing) driven by some very cost-effective MCUs is really quite impressive.
 
Our 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
- The ability to render very complex graphics by combining the above with a frame buffer
- and many more...
 
These make the BT820B ideal for all kinds of products and applications embracing the latest UI trends including large hi-res displays, more complex UIs with lots of waveforms and controls, and in some cases live video etc.   The BT820B is therefore ideal for both new product designs and existing EVE designs being updated.

Best Regards, BRT Community

[Rudolph]

Frankly 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".

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

[BRT Community]

Hi Rudolph,

We use an HDMI to LVDS board here for testing too, you can find details of the board that we use in chapter 9 of this new application note below,

https://brtchip.com/wp-content/uploads/2025/06/BRT_AN_092-BT820-Hardware-Design-Example.pdf

You can use a camera with HDMI output or even a laptop with HDMI monitor output to input video to the BT820B,

Best Regards, BRT Community