And I am celebrating the first stable output on a LCD from the BT820! 

I am still having a weird timing issue, the output of the 1024 x 600 image is only to 3/4 of the width of the screen.
And nothing I did to the timing parameters so far made that smaller or wider, it only changes from stable to chaos.

Edit:
And now I have the image stretched across the complete display area. 

Looks like my PixelClock was too low.
With some trial and error I ended up with NS = 7 and DIV = 4 - REG_LVDSTX_PLLCFG = 0x00300874
NS = 7 and DIV = 2 is not working.
NS = 7 and DIV = 3 to DIV = F is working, although it starts to flicker at DIV = B.
NS = 8 and DIV = F is not working, although this should only be a little higher than NS = 7 and DIV = F.

My guess is that the description of REG_LVDSTX_PLLCFG is not correct.
But I can not measure the resulting pixel clock directly, I do not have an oscilloscope here.

I am getting closer,but the output on my LCD still is corrupted.
But at least I can see that there is something going on now, I am using CMD_LOGO and there is some movement in the chaos for a couple of seconds.

I found that my function of calculating the value for REG_LVDSTX_PLLCFG was completely broken.
But after fixing it, it still does not work.
As it turns out, the description for REG_LVDSTX_PLLCFG in the programming guide is wrong.
The reset default value is 0x00300877 - and that is correctly stated.
"Table 18 – LVDSTX Clock Configuration" can not be correct though, first indication is that 15 and 8 are not the default values.

And in the datasheet I finally found this:

Quote
4.12.2 Phase Locked Loop
There are 4 Phase Locked Loops (PLLs) inside the chip; the system PLL (PLL1), LVDSPLL (PLL2), DDRPLL
(PLL3) and the DDR PHYPLL (PLL4)
The system PLL receives the input clock from the oscillator and produce both the system clock and the
LVDSTX clock.
The LVDS PLL takes the input clock from the LVDSTX clock and generates the LVDS fast clock.
The DDRPLL and the DDR PHYPLL are used to generate clock for the DDR interface.

And while this not quite cleary written, it shows that that input for the LVDSPLL (PLL2) is not the Oscillator with 38.4MHz,
but the system clock that is generated by the system PLL (PLL1) and which defaults to 72MHz.

So when I tried to use NS = 8 and CLKDIV = 5 in order to setup the LVDSTX clock to 51.2MHz, I was setting it up to 96MHz instead,
which is out of spec for the LCD I have.

The default value of 0x00300877 should result in a pixel clock of 63MHz, however LVDSPLL_CK is configured incorrectly to 0b01, if I am understanding the
programming guide correctly, that would be for a CTLCLK range of 200MHz to 400MHz, NS = 7 and input = 72MHz results in 504MHz though.
So a valid default value should have been 0x00301077.

And with 72MHz as input for the LVDSTX PLL I can not set the clock to 51.2MHz - pretty close to 51.43MHz though.

There is no maximum range given for either SYSPLL_CKS or LVDSPLL_CK, according to REG_SYS_CFG and REG_LVDS_PLLCFG it might be
400MHz to 800MHz for SYSPLL_CKS and 200MHz to 800MHz for LVDSPLL_CK.
That would put the valid range for NS of system clock to a range of 11 to 20 while 72MHz might be the the highest Systemclock allowed.

And with 72MHz system clock the allowed range for NS of the LVDSTX PLL would be 3 to 12.
But well, the allowed range for the system clock might be 36MHz to 72MHz.

If I am correct on this, please provide updated versions of both the DS_BT820 and BRT_AN_086_BT82X-Series-Programming-Guide
with more and accurate information.

Oh yes, I also found BRT_AN_092-BT820-Hardware-Design-Example, unfortunately there is nothing in there on setting up LVDSTX.

Another source of information could have been EVE Screen Editor.
However, v5.0.0 only shows a fraction of the the registers in RAM_REG and there are no built-in settings for connecting to a 1024x600 LCD.

Hi,
Yes, RGB565 is a commonly used 16-bit image format, but it does result in some loss of color information — especially for neutral tones like grayscale.
This is because RGB565 allocates only 5 bits for red and blue, and 6 bits for green. The imbalance in bit allocation can cause color distortion, which may lead to grayscale areas appearing bluish on the display.
If you want to preserve better color fidelity, we recommend using the ASTC compression format.
You can use our EVE Asset Builder tool to convert images into ASTC format.
For example, using 8×8 ASTC compression typically provides visually good quality while producing a smaller data size than RGB565.


Best Regards, BRT Community

thx for these precisions.

If I want to display an image 24 bits (compressed or not) which format is recommended for my 18 bits/pixel screen?
RGB565? Is there any loss of color information?

I've tried with a 16 bits image and RGB565 and gray part has turned blue on display. Why?

Hi,
Yes, REG_OUTBITS = 0x01B6 is correct for 6 bits per color (R:G:B = 6:6:6).
We recommend connecting your screen's D17–D0 lines to BT816 as follows:
•   D17–D12 → BT816 R7–R2
•   D11–D6 → BT816 G7–G2
•   D5–D0 → BT816 B7–B2
This maps the highest 6 bits of each color output from BT816 to your LCD input, ensuring better color accuracy.

Best Regards, BRT Community

A new milestone. :-)

I got to the point in reverse engineering the PCB800182 deep enough to be confident to attach my LCD to - and nothing bad happened, no magic smoke. :-)
I also modified the 20pin LVDS cable that came with the PCB800182 to use a 30pin connector with a single LVDS channel to attach to the VM820C.

So I tried to wiggle my way thru the initialization sequence.
First issue, there are no timing parameters in the "datasheet" of the ER-TFT070-3 I bought - argh.
Well, I checked what I have used for the BT817 7" with 1024x600.

To configure the LVDS output I came up with this:


void configure_lvds(void)
{
    EVE_memWrite32(REG_RE_DEST, EVE_SWAPCHAIN_0);
    EVE_memWrite32(REG_RE_FORMAT, EVE_ARGB8);
    EVE_memWrite32(REG_RE_W, EVE_HSIZE);
    EVE_memWrite32(REG_RE_H, EVE_VSIZE);
    EVE_memWrite32(REG_DISP, 1);

    EVE_memWrite32(REG_LVDSTX_PLLCFG, setlvdspll_value(0, PLL_LOCK_PERIOD, 1, 10, 7)); /* 38.4 MHz * 10 / 8 = 48MHz */
    EVE_memWrite32(REG_LVDSTX_EN, LVDS_CH0_EN);

    EVE_memWrite32(REG_SC0_RESET, 1);
    EVE_memWrite32(REG_SC0_SIZE, 2);
    EVE_memWrite32(REG_SC0_PTR0, 10 << 20);
    EVE_memWrite32(REG_SC0_PTR1, 20 << 20);

//    EVE_memWrite32(REG_SC1_SIZE, 2);
//    EVE_memWrite32(REG_SC1_PTR0, SC1_PTR0_STARTADDR);
//    EVE_memWrite32(REG_SC1_PTR1, SC1_PTR1_STARTADDR);

//    EVE_memWrite32(REG_SC2_SIZE, 2);
//    EVE_memWrite32(REG_SC2_PTR0, SC2_PTR0_STARTADDR);
//    EVE_memWrite32(REG_SC2_PTR1, SC2_PTR1_STARTADDR);

    EVE_memWrite32(REG_SO_EN, 0);
    EVE_memWrite32(REG_SO_MODE, EVE_SO_MODE_2);
    EVE_memWrite32(REG_SO_SOURCE, EVE_SWAPCHAIN_0);
    EVE_memWrite32(REG_SO_FORMAT, EVE_ARGB8);
    EVE_memWrite32(REG_SO_EN, 1UL); /* enable scanout */

    DELAY_MS(10);

}


But I am not sure if I got all the necessary register, if the order of writing them is correct and if I chose
values for all registers that actually make sense.

And it is not working, or only somewhat a little bit working.
I do get a white screen with some artifacts in the end.

I am not even sure how this all makes sense so far.
Why is there a REG_RE_FORMAT and a REG_SO_FORMAT?

Making this all configureable will be a challenge. :-)


Edit: I modified things a bit, changed the timing, switched the clock to 51.2MHz as suggested in the display controller datasheet of the LCD I have.
I also added:
EVE_memWrite32(REG_LVDSTX_CTRL_CH0, 1); /* JEIDA/Format 1 Mapping for 24-bit, Single Pixel per Clock */

And I am reading REG_LVDSTX_ERR_STAT and REG_LVDSTX_STAT now.
REG_LVDSTX_ERR_STAT reads as 3 which means: UNDERFLOW_CH0 + OVERFLOW_CH0

Hmm? Schroedingers LVDS, empty and full at the same time? :-)

The value of REG_LVDSTX_STAT changes with the value I put in REG_LVDSTX_CTRL_CH0
REG_LVDSTX_CTRL_CH0 = 0 -> REG_LVDSTX_STAT = 0x000015d1
REG_LVDSTX_CTRL_CH0 = 1 -> REG_LVDSTX_STAT = 0x00001791
REG_LVDSTX_CTRL_CH0 = 2 -> REG_LVDSTX_STAT = 0x00000fd1
REG_LVDSTX_CTRL_CH0 = 3 -> REG_LVDSTX_STAT = 0x00000e31

Bit 0 set = LVDSPLL_LOCK / PLL locked - that sounds correct
Bit 4 set = LVDS_CH0_ACTIVE - looking good
Bit 5 to 8 = LVDS_CH0_UNDFCNT - 14/12/14/1
Bit 9 to 12 = LVDS_CH0_OVFCNT - 10/11/7/7

The display is configured to 8 bit per color, SELB is set to GND, so REG_LVDSTX_CTRL_CH0 should be set to 1 or 2 (default).

What am I doing wrong?

Hi,
I'd like to connect my screen with d0 to d17 data pins to BT816 chip.
So I have D17-D12 for Red, D11-D6 for Green and D5-D0 for blue, 6bits/color.
Which pins should I connect to BT816 R0 to R5 or R2 to R7?
If I remember I must set REG_OUTBITS to 0x01B6. Right?

Thanks.

Ok, I am trying to figure out how to configure the display output and I doubt now that my display will show anything by tomorrow.

With host command RST_PULSE removed, is using the pin PD_N / RST_N mandatory now?

What is the minimum recommended time to wait after raising RST_N?

Any suggestions on what to do if rd32() fails to read due to not receiving 0x01?

How to actually configure the display output? There is close to nothing so far in the programming guide.
What needs to be configured and in what order?
How do the older register like REG_HSYNC0 interact with the LVDSTX settings?
How do the REG_RE_ and REG_SO_ registers interact with this?

Where in the initialization sequence is setting up the Swap Chains supposed to be placed?
How is the size of a SwapChain buffer calculated? REG_SCx_SIZE holds the number of buffers, not their size. From REG_RE_FORMAT, REG_RE_H and REG_RE_W?

Why do the examples use different names for the registers than the programming guide? e.g. REG_LVDS_* -> REG_LVDSTX_*

How is the watchdog used?

With REG_TOUCH_RZTHRESH gone, how to configure the sensitivity of resistive touch?

Bridgetek is excited to announce the launch of our BT820B, the 5th Generation Embedded Video Engine (EVE), at the Embedded Exhibition in March 2025.

The launch includes our BT820B IC, as well as a range of development modules and supporting software toolchains. As industry trends lean towards larger displays with more complex User Interfaces (UI), it often involves a requirement to incorporate live video streaming too.

The BT820B's enhanced features and capabilities provide designers with an effective solution to implement these advanced UIs easily and get their product to market in a short time.

Elektor Interview with Bridgetek
https://youtu.be/-w9iqicyvJs

Yeah, thank you! I am having fun here. :-)
And there is no need to rush things as no ready-to-use modules are available to far.

I just found this though: https://riverdi.com/product/15-6-eve5-display
For "Embedded" this is nutz, they even added "External DDR3 SDRAM: 4Gbits".
Can't wait to use this with an Arduino UNO. :-)
Anyways, I put my name on the waiting list.
I wouldn't mind 7" or 10", I still have no idea where to put a 15.6" on my desk - desperately need to spring-clean.

I am hoping to use the panel I bought by the end of the weekend, can not connect touch so far though.

Edit: turns out that the "driver-board" I bought to adapt between VM820C LVDS and the 40pin FFC on the LCD is a bigger issue than I anticipated.
It is a "PCB800182" and there is very little real information for it available.

After a bit of reverse-engineering I know that the board uses a PT4103 as step-up converter for the backlight.
The image on EBay from the seller I bought from shows a feedback resistor of 1R which would mean about 100mA backlight current.
Populated however is a 0.68R -> 150mA - and the LCD I bought specifies 120mA max.

And since the backlight driver is supplied with the 3.3V from the LVDS connection and the backlight voltage is 9.6V typical,  the current drawn is about 2.9 x of the backlight current, 435mA might be a bit much.
I will populate 4.7R for 22mA, that should be more reasonable.

Why am I not using the backlight driver on the VM820C? I would like to, but there is no header for LEDA / LEDK on the VM820C, these are only connected to CN4 which is the 45pin LCD header.
There is CN7 which has BKLIT_PWM and DC_IN, but there is no indication what make and model CN7 actually is beyond that it is a 2mm connector.
And since it uses DC_IN, this would remove the option to only power the VM820C from USB or the HOST interface.
Well, the PT4103 is only rated for 2.5V to 6V anyways, so using CN7 would mean to limit DC_IN to below 6V.

And then I am not sure yet what the extra pins on the TFT side of the PCB800182 are configured to.
It is very likely setup for 8 bit operation.
RESET and STBYB should be connected to 3.3V.
That leaves VCOM, DIMO, AVDD, L/R, U/D, VGL, CANCEN0, CABCEN1 and VGH.

Well, the pinout on the 40pin FFC of the PCB800182 is the same as on the ER-TFT070 LCD.