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.

Hello Rudolph,

Glad to see you are making progress with your testing!

Please let us know if there are any specific questions you may have concerning the BT820B protocols or if you run into any issues.

Best Regards,
BRT Community

Chapter 1.4 API Reference Definitions

wr32() -> EVE_memWrite32() - works
rd32() -> EVE_memRead32() - works
cmd() / cmd_*() / dl() - mostly the same as wr32(), all my commands go thru REG_CMDB_WRITE, if I ever would write the display list directly, I would use EVE_memWrite32().

Now for the fun part:
EVE_memRead8() - works, sort of
EVE_memRead16() - works, sort of
EVE_memWrite8() - does not work, memory is not changed
EVE_memWrite16() - does not work, memory is not changed

The rd8()/wr8()/rd16()/wr16() functions are not just omitted from the programming guide of the BT820, these do indeed not fully work.
From the datasheet, chapter 4.5.1 QSPI Host Interface Protocol:

Quote
The transactions are word based, i.e., the data width must be in blocks of 32 bit when accessing the
registers and the DDR memory of the BT820. Addressing to the registers and the DDR memory must also
be word aligned, i.e., the last two bits of the received address are ignored.

And

Quote
The write data is expected to be in blocks of 32-bit. Any incomplete data is discarded when SS_N deactivates.

So, not a surprise, I was expecting this, but I still had to try. :-)

My EVE_memRead8() and EVE_memRead16() work fine as long the address is word-aligned.
For example EVE_memRead8(REG_ID) returns 0x7C since all registers are word aligned of course and the bytes are read from Low-Byte to High-Byte.
Reading is only stopped before EVE is expecting it to.
Edit, EVE_memRead8(REG_ID+1) still returns 0x7C.

Writing, well, damn, the data really is discarded. :-)
Means I need to change some more things for the BT82x, for example writing only a byte to REG_CPURESET as it only uses 3 bit anyways is no longer an option.

Quote from: TreeOone on March 31, 2025, 07:57:34 PM
I was not aware of pixel engine's limitations.

It is more an issue with resolutions beyond 800x480.

Quote
Rudolph, your library is great. Unfortunately for me, it is heavily dependent on SPI communication, which is not ideal for me, because I am using QSPI, which on STM32 works a little bit different, so I had to rewrite all functions in EVE_commands.c.

There shouldn't be a need to rewrite anything in EVE_commands.c, the hardware-abstraction is in EVE_target/EVE_target_STM32.h for example.
Ok, for STM32 in particular there also is EVE_init_spi() in EVE_target.c - but this is nice to have, not must use.

And yes, I have not looked at the QSPI unit in particular, but it should be covered by HAL, if not LL HAL.

And quad SPI? I simply found no use case for it so far, display updates only take xx micro-seconds when you make use of DMA. :-)

Edit: I looked, ok, there does not seem to be LL HAL support for QSPI.
And I have a NUCLEO-G474RE and I am looking at it n STM32CubeIDE, unfortunately the Device Configuration Tool does not seem to allow me to configure the QSPI with a single line and also trying to not use the chip select line under the control of the unit does not work -> really not my cup of tea.