Ok, a datasheet is released now, but this leaves me a little confused.
So far EVE5 was anounced as BT822 with 1Gbit of embedded DDR3L.
And now we got a datasheet for a BT820 with up to 4GBit of external DDR memory?
The clock source is a 38.4MHz crystal, but the system clock is 72MHz?
The fonts remained unchanged - really?
As I predicted, the SPI host interface has been updated from 22 bit adressing.
But I am not 100% sure how it is working so far.
Ok, the BT820 has 31 bit adressing with the MSB beeing the "WR" bit, so writing when it is set to '1'.
Also it is Addr3, Addr2, Addr1, Addr0, followed by Data0, Data1 and so on.
As it always was since FT800, address and data use different byte orders, ok then.
When reading from the BT820 there no longer is a simple dummy byte though, first the address is send, then data is read untill 0x01 is returned, when 0x01 was returned the following transfers are for the actual data bytes.
Well, at least reads are less common and usually short.
I wonder how long that polling can last though.
"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 is ignored"
"The write data is expected to be in blocks of 32-bit. Any incomplete data is discarded when SS_N deactivates."
Ok, I guess implementing rd8, rd16, wr8 and wr16 functions won't be necessary then.
That seems to be pretty clear so far.
Then we have host commands.
Ok, host commands are always 5 bytes long.
The ACTIVE command is just 0x00 0x00 0x00 0x00 0x00.
And writing parameters such as the the memory configuration is done with:
0xff Command Parameter 0x00 0x00
And then we still have POWERDOWN, STANDBY and SLEEP, at least.
So the host controller will do 32 bit transfers for the most part but still has to be able to do 8 bit tranfers,
for the host commands at startup and to poll for 0x01 during every read sequence, correct?
Now for the touch engine, turns out that resistive touch is not supported directly after all.
It is supported by using an external resistive touch controller that is connected via I2C.
Interesting.
A memory map is missing from the first revision of the datasheet.
And speaking of memory, that 1Gbit still is a surprise for me, I have no idea what this could be filled with.
Well, more can't really hurt, that "24-bit RGB framebuffer up to 2048 x 2048 pixels" would be 16Mbyte.
The registers, fonts, FIFO, ROM(s) and display lists likely also use regions in RAM.
The most interesting question is still when I can buy anything with a BT82x on it though. :-)
Hi Rudolph,
The BT820 will be launched at the EW2025 show in March and so not long to go now...
We'll have a development module too.
Great to hear that you're looking at the protocol etc. with a view to supporting BT82x in your code, and we'll keep everyone updated here as new documents / example code become available that will help with that.
Yes, you can use resistive and capacitive touch, with both using I2C connection to an external touch controller.
The memory map is actually in the Programmers guide for this device this time instead of the datasheet, and so we'll let you know once that document is available.
As you said, the frame buffer will use up some of the RAM and leaves plenty of RAM even with 1Gbit.
Best Regards, BRT Community
With the release of the BT820 getting closer, I did a analyses of the BT820 commands in comparision with the BT81x commands.
Display-List commands:
Mostly compatibel from the command number to the bits, with a few exceptions.
TAG, CLEAR_TAG - use 24 bits now instead of 8
BITMAP_HANDLE - uses 5 bits now instead of 4
CALL, JUMP - new valid range is 0...4095
PALETTE_SOURCE - uses 24 bits now instead of 22
New commands:
0x31 BITMAP_SOURCE_H, 0x32 PALETTE_SOURCEH - for the high byte of the extended address
0x33 BITMAP_ZORDER - "Set the z-order address pattern for a bitmap" - whatever this is, found chapter 2.17, still not sure
0x34 REGION - this is for a rendering optimization in the display list, by default all the co-processor widgets are using this
"missing" is the display-list command that would use 0x30 as identifier.
What I am missing:
There is no new graphics primitive to be used with BEGIN.
There is no VERTEX3F or VERTEX2F2 command using code 0x60 that uses a pixel precision of 1 pixel and 12 bits for the encoding with a range of -2048 to 2047 while encoding y in bits 0...11 and x in bits 16 to 28 to address the bottleneck that VERTEX2F and VERTEX2II are imposing.
Co-Processor commands:
Unfortunately except for CMD_DLSTART, CMD_SWAP and CMD_INTERRUPT, the command numbers are completely incompatible.
I really would have apreciated it if the new commands would have used numbers 0xFFFFFF71 and up.
A large number of commands moved back to using int16_t and in32_t types in the BRT_AN_086_BT82X-Series-Programming-Guide
while actually requiring uint16_t and uint32_t types: TEXT, BUTTON, KEYS, PROGRESS, SLIDER, SCROLLBAR, TOGGLE, GAUGE, CLOCK, CALIBRATE, ROTATE, SETMATRIX, TRACK, DIAL, NUMBER and ROTATEAROUND
The description for CMD_GETMATRIX still does not help me to understand what this is supposed to do.
CMD_MEDIAFIFO notes in the example: "0x100000 is the top of RAM_G"
Commands with incompatible changes to the API:
CMD_SETFONT is actually CMD_SETFONT2
CMD_INFLATE is actually CMD_INFLATE2
CMD_VIDEOSTART added options
Odd:
CMD_SNAPSHOT is not using the old CMD_SNAPSHOT2
CMD_APPENDF, never noticed this, applies to BT81x as well, documented to use REG_CMD_WRITE in contrast to CMD_APPEND which uses REG_CMD_DL, can't be true.
Removed:
CMD_ANIMFRAMERAM - the new CMD_ANIMFRAME plays from RAM_G, the original played from flash
CMD_ANIMSTARTRAM - the new CMD_ANIMSTARTRAM plays from RAM_G, the original played from flash
CMD_CLEARCACHE - why?
CMD_VIDEOSTARTF - somehow CMD_VIDEOSTART plays video from flash though
CMD_APILEVEL, CMD_FONTCACHE, CMD_FONTCACHEQUERY, CMD_PCLKFREQ
CMD_HSF - why?
New:
CMD_DDRSHUTDOWN, CMD_DDRSTARTUP
CMD_WAITCHANGE, CMD_GRAPHICSFINISH, CMD_WAITCOND, CMD_SKIPCOND, CMD_REGWRITE - unlikely to be used in real display lists?
CMD_FENCE - not sure what this is actually good for, yet
CMD_I2SSTARTUP - sounds like CMD_I2SSHUTDOWN might be missing
CMD_FSOPTIONS, CMD_FSREAD, CMD_FSSOURCE, CMD_FSSIZE - looks like a way to write files to SD card is missing
CMD_FSDIR - looks like a CMD_CHGDIR is missing?
CMD_SDATTACH, CMD_SDBLOCKREAD - looks like CMD_SDDETACH might be missing
CMD_PLAYWAV - oddly does not allow to play from RAM_G, a loophole would be to configure the MEDIAFIFO, does only complete when the playback ends
CMD_LOADWAV - oddly loads the sound into memory, sets the loop flag but does not play the sound
CMD_SAVECONTEXT / CMD_RESTORECONTEXT - no idea why these are commands, sending display-list commands to the co-processor works fine and all other display list commands are not added as co-processor commands
CMD_ENABLEREGION - allows to disable the render optimization for widgets
CMD_LOADASSET - loads files in new .reloc format, likely a EAB generated file which has a header before ZLIB / ZOPFLI compressed data - ah, yes, found chapter 2.12
CMD_WATCHDOG - the watchdog description is missing vital information, what the default timeout is after activation during system reset, how to actually reset the counter and what happens when the time runs out
CMD_TEXTDIM - calculates length and height in pixel for UTF-8 encoded texts
CMD_ARC - still specifies "If the angles specify a complete circle, a disc is drawn."
CMD_COPYLIST - not sure what this is good for and why it would be used with CMD_CALLIST and not CMD_APPEND
CMD_RESULT - hmm
CMD_CGRADIENT
CMD_GLOW
CMD_RENDERTARGET - found chapter 2.11, still not sure what this is about
Next part, registers.
I went thru the programming guide and put all registers in a spreadsheet to first get a kind of explicit memory map and to be able to sort the lines by register name for the export to a header file.
Just some bits of statistics.
There are fewer registers than I expected, a total of 155 are documented.
The documented memory regions have room for 1792 registers of 32 bits width.
There are at least three more undocumented memory regions that may have registers and have room for 320 more registers.
region/address/space for registers/registers used
EVE_REG_CORE_R1 0x7F006000 1024 114
EVE_REG_CORE_R2 0x7F004000 512 15
Odd, why not just use the region starting from 0x7F004000 for all registers and be done?
Some register groups are oddly spread over the memory like the REG_CMD registers:
REG_CMD_DL 0x7F006154
REG_CMD_READ 0x7F00614C
REG_CMD_WRITE 0x7F006150
REG_CMDB_SPACE 0x7F006594
REG_CMDB_WRITE 0x7F010000
Not that there is anything wrong with this, it just make me wonder why.
Some "holes" in the memory obviously have undocumented registers, like 0x7F006030 or 0x7F800308.
And then there are larger regions like 0xFf0061B8 to 0x7F006590.
Does this matter? No, of course not, it just leaves me curious.
And I wonder what is planned for alle the unused registers.
Then there a few odd things.
REG_TOUCH_SCREEN_XY and REG_CTOUCH_TOUCH0_XY use the same address
REG_TOUCH_RAW_XY and REG_CTOUCH_TOUCHA_XY use the same address
This is not exactly new, I just wonder why this is still a thing and also why "Compatibility mode"
is the default setup in RED_CTOUCH_EXTEND when there is nothing to be compatible with and
the two supported resistive touch I2C controllers should be outliers and not the standard to be expected.
Well ok, single touch might not be the same as multi-touch and only using the first touch.
Then there is this:
REG_CTOUCH_TOUCH0_XY
REG_CTOUCH_TOUCHA_XY
REG_CTOUCH_TOUCHB_XY
REG_CTOUCH_TOUCHC_XY
REG_CTOUCH_TOUCH4_XY
And this:
REG_TOUCH_TAG
REG_TOUCH_TAG_XY
REG_TRACKER
REG_TOUCH_TAG1
REG_TOUCH_TAG1_XY
REG_TRACKER_1
REG_TOUCH_TAG2
REG_TOUCH_TAG2_XY
REG_TRACKER_2
REG_TOUCH_TAG3
REG_TOUCH_TAG3_XY
REG_TRACKER_3
REG_TOUCH_TAG4
REG_TOUCH_TAG4_XY
REG_TRACKER_4
Please consider renaming the first set in the programming guide to this:
REG_CTOUCH_TOUCH_XY
REG_CTOUCH_TOUCH1_XY
REG_CTOUCH_TOUCH2_XY
REG_CTOUCH_TOUCH3_XY
REG_CTOUCH_TOUCH4_XY
I have a question about the VM820C.
Quote
6.2 Selecting Power Source
When powering the system via USB-C (FT4222H interface) or 5V_Host (MPSSE or Host_MCU),
the maximum power supply is limited to 500mA at 5V. In cases where large LCD panels are used
or the power demand exceeds the available supply, it is strongly recommended to provide a 12V
power supply through the DC jack connector for the development module.
Ok, the limit on the USB-C probably is there because it is hardwired to USB-2.
But why is the host supply limited to 5V and 500mA?
From the schematic it looks to me that HOST_5V is only connected to VSYS which can also be powered by DC_IN.
So shouldn't it be HOST_DC with the same limit of 5...12V as for the DC_IN?
The RVT101 for example uses a higher voltage for the backlight to bring down the current on these lines.
So I do have a MCU board for this interface that uses a dedicated buck converter to provide 9.6V at these pins.
Edit: and a few question about the BT820 itself
Going over the host commands and the initialization sequence I noticed that the host command RST_PULSE has been removed from the BT820.
And instead of PD_N there is a RST_N pin now which pretty much does the same thing.
Does this mean that using RST_N with the BT82x is pretty much mandatory when doing a warm-start?
Then I am wondering when to raise RST_N again, there is a minimum time provided of 214µs to trigger a reset and that would be sufficent for a warm-start.
But then there also is this:
Quote
The RST_N signal must be de-asserted at least 5ms after the power rails from Group 4 have powered up.
Well, there is no way to tell for the host controller that the voltage rails are indeed powered up.
Given that the host controller also needs some time to boot, power up the oscillator and so on, is it save to assume that setting RST_N as early
as possible to low and raising it in the init function after an extra 6ms would be ok?
And the last question for the moment, FT81x and BT81x needed 20ms after raising PD_N before issuing the first host command.
I can not find such timing for the BT820 - any suggestions?
My idea is to initially try 1ms before sending BOOTCFGEN and see what happens.
But seeing "Figure 28 - Power State Transition" in the datasheet, there is actually a state after RSN_N = 1 : POWER UP INITIALIZATION.
Perhaps I am overthinking this but the initialization sequence in the programming guide might need a few extra steps to be complete.
Edit2:
With nothing (yet) to test against (but soon), I started implementing.
My initialization is sending out five host commands and apart from the timing (see above), at least the SPI traffic looks correct in the logic analyzer.
Now I am at the point in the initialization that suggests to read REG_BOOT_STATUS untill 0x522E2E2EU is returned.
I am looking at my EVE_memRead32() which is of course the implementation of the rd32() function mentioned in the programming guide.
Switching to 31 bit adressing was the easy part.
Adding the loop to read bytes untill 0x01 is returned or a break occured, done.
But looking at the logic analyzer trace with the failed read attempts as I have no BT820 attached so far,
I do not like this new read protocoll.
What is the supposed reaction when reading fails?
Ok, fair enough, I have no error detection up to BT81x either, if there is catastrophic failure, like when there is no EVE chip at all,
then the initial reading of 0x7c fails and my initialization would return EVE_FAIL_REGID_TIMEOUT.
So I guess I could add a REG_FAIL_BOOT_STATUS_TIMEOUT.
And then I am using a flag in my application module to indicate that initialization worked.
I previously observed that invalid data is read when the SPI clock is too high to properly work with my host interface setup,
so I had to reduce the clock or reading touch data would not work.
But what about the possibility of non catastrophic failures?
What drives the delay that prevents the BT820 from responding with 0x01 immediately?
Why is a BT82x even potentially slower in answering the SPI than FT80x, FT81x and BT81x?
Is a response guaranteed and what is the maximum acceptable number of bytes read that are not 0x01?
I would prefer a more deterministic read protocoll, even the need to send two dummy bytes instead of one would have been better.
Oh yes, SPI clock, is it true that there is no longer a limitation of 11MHz on the clock speed during initialization?
And it is alive. :-)
I have the BT820 on the VM820C running thru the boot sequence. :-)
Doesn't really do much so far, host commands are working, EVE_memRead32() is working.
The whole thing compiles with just two warnings for unused functions.
Still a long way to go.
I can not connect a display right now, an ER-TFT070-3 with cap touch arrived last week, it uses a 40pin LVDS connector which seems to be quite common.
Then I got myself a "Universal LVDS Signal Interface Converter DF14 20Pin to FPC 40Pin Connector" board to connect the display to.
I am still waiting on connectors and I just noticed that I might have forgotten to order an apapter PCB to connect the touch from the display to.
Right now I am running on a STM32F407, mostly for conveniance as I had a STM32CubeIDE project up and running and the Nucleo board was already connected to one of my boards with the FFC-20 connector I usually connect displays to.
Oh yes, and I have pins for the logic analyzer on my adapter boards.
So far everything for EVE2/EVE3/EVE4 is still in the library, maybe I keep it this way.
What did I learn from looking at the logic analyzer so far?
I just removed the delay between raising RESET_N and issuing the host commands and the BT820 seems to be booting fine, but I added 2ms delay there to be safe.
From the end of the ACTIVE command to the first response on the SPI are <34ms and this does not change with the delay between the raising of RESET_N and the host commands.
The very first response is 0x55 0xaa 0x55 0xaa.
The time from the start of the next SPI transfer that reads 0x2e 0x2e 0x2e 0x49 - which surprisingly means "coprocessor is running" - to the end of the boot when 0x2e 0x2e 0x2e 0x52 is returned takes around 27ms.
So maybe I will give the BT820 like 60ms to boot before checking the REG_BOOT_STATUS register.
On the unusual SPI read-protocol, I did continous reads thru the complete boot-sequence now.
And all the responses after the initial first answer had a 0x01 returned on the sixth byte after the address.
So for some odd reason the BT820 needs 5 dummy bytes when reading.
Just an observation, waiting for 0x01 returned is the documented way to go.
Oh, I just noticed, I enabled only DDR in SETBOOTCFG, not touch, audio or the watchdog.
Well, I could not use the watchdog as there is no hint in the programming guide so far on how to reset the timer.
Enabling touch and audio added about 100µs - but then there is no I2S chip on the board and I do not have a touch CTP connected.
Hmm, I just noticed that enabling audio has a side effect, the currect from my PSU nearly trippled.
I have my PSU set to 8V and the VM820C + my board are drawing 78mA without audio enabled.
And 220mA with audio enabled - strange.
This here feels like a blog, but I still would like to get a few answers out of this. :-)
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.
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
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.
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?
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?
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.
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.
How do I use the touch engine?
As far as I understand it, setting bit 6 in SETBOOTCFG should be enough, this should enable the touch system and
during boot the touch system should do an auto-discovery to determine the touch controller connected.
My LCD does have a FT5316 and after connecting it to the VM820C it does nothing at all.
Reading REG_TOUCH_CONFIG returns 0x00000000, writing 0 or 0x381 does nothing either.
I can not calibrate and reading REG_TOUCH_RAW_XY returns 0xFFFFFFFF.
It should not be necessary to setup CTP_SCL/GPIO5, CPT_SDA/GPIO6, CTP_INT/GPIO7 or CTP_RST/GPIO8 in order to use the touch engine.
But then I can not find how to actually set this up anyways, how to configure them for alternate function or GPIO.
Edit: I soldered pins and to the FFC adapter I am using for the touch controller and looking at SCL, SDA and Reset with the logic analyzer.
And while the pins wiggle like expected for their function, the touch controller does not seem to answer.
What is odd though, when I write 0x381UL to REG_TOUCH_CONFIG to setup a FocalTech device, the lines are just dead.
SCL is Low - really odd for an open collector ouput with pullup-resistor, SDA and Reset are high.
When I write 0x380UL to REG_TOUCH_CONFIG, which should not do much according to the register description,
apparently auto discovery is triggered, Reset is pulled low, then there is a pause and then there is one or two byte transfers on SCL/SDA.
Same thing happens when not writing to REG_TOUCH_CONFIG or when writing 0.
Oddly I also see 311ms periods with SCL just low like this, even when I disconnect the CTP.
Maybe my touch controller is toast, but what the BT820 does is not looking correct either.
Looks like I need to check the touch controller with an Arduino, there was some I2C scan sketch somewhere.
Edit: I did just that, I have an Arduino UNO running at 3.3V with 4k7 pullup resistors to 3.3V scan the I2C right now, connected to the CTP of the display as written on it's FFC cable: 1 = GND, 2 = SDA, 3 = SCL, 7 = VDD - and nothing is found.
Strange.
Edit: I found the issue, I do have working touch now. ;D
The connector on the 10pin FFC adapter board I am using looks like is contacting on both sides of the cable,
but it definately is only contacting on the bottom side.
The cable for the CTP has the contacts on the top side...
Have two fotos to celebrate. :-)
Yes, I noticed that the backlight is a bit dim, but I can't control it by software and only set it to 20mA, maybe I'll add another resistor in parallel later.
Edit: I just put up a repository with the information from reverse engineering this display adapter: https://github.com/RudolphRiedel/PCB800182_LCD_Adapter
Hi Rudolph,
Congratulations on getting the BT810B up and running on your board !
Glad to hear that you found the cause of the issue with the contact side on the touch connector already and that it's working well now.
Is your picture nice and stable now on the display too?
We'll check the definitions of the REG_LVDSTX_PLLCFG in the guide.
Best Regards, BRT Community
The picture is nice and stable, yes, I started to implement the new commands for the BT820. :)
But I currently have an issue that I can not explain.
First I noticed that I need to place additional VERTEX_FORMAT(0) in my display list, somehow the setting is not persistent.
Then I noticed that the back-to-back CMD_TEXT in the snippet I am using with CMD_APPEND no longer work, only the first line is displayed.
And when checking with the logic analyzer I found that a single CMD_TEXT is keeping the command-co-pro busy for an unusual amount of time, like there is some issue.
When I interleave the CMD_TEXT with COLOR_RGB then all the lines are displayed, the co-pro still is busy with this for quite a while though.
Choosing the less complicated CMD_NUMBER I get the same:
EVE_cmd_dlstart();
EVE_color_rgb(BLACK);
EVE_cmd_number(10, 515, 26, 0, 12345);
EVE_cmd_number(10, 500, 26, 0, 12345);
EVE_execute_cmd();
Followed by:
num_dl_static = EVE_memRead16(REG_CMD_DL);
EVE_cmd_memcpy(MEM_DL_STATIC, EVE_RAM_DL, num_dl_static);
The result right now is that the second line is not completely displayed.
When I switch the order of the lines, the other one gets incorrectly displayed.
When I throw in an extra EVE_color_rgb(BLACK); between the two CMD_NUMBER, then both lines are displayed.
When I use a NOP one of the lines still get corrupted.
The resulting sequence for EVE_cmd_number(10, 515, 26, 0, 12345); is:
0xff 0x01 0x00 0x00 - write + REG_CMDB_WRITE
0x2a 0xff 0xff 0xff - CMD_NUMBER
0x0a 0x00 0x03 0x02 - x = 10, y = 515
0x1a 0x00 0x00 0x00 - font = 26, options = 0
0x39 0x30 0x00 0x00 - number = 12345
I still need to read out the resulting display list snippet and analyze it, but right now I do not see anything wrong with my code.
Hmm, I added the lines with x=110 to the main display list and also made the list use separate commands instead of using DMA,
the two lines are displayed just fine.
Then I checked my implementation of CMD_APPEND, nothing there, changed the target address for the snippet, no change.
Looks like the co-processor does not like to put commands in a display list anymore that is not meant to be displayed on it's own?
There is no CLEAR_COLOR_RGB or CLEAR for the snippet, as this is in the main display list.
Edit: I just modified my code to use CMD_NEWLIST/CMD_ENDLIST/CMD_CALLLIST which just stores the co-processor command instead of executing them.
And this works just fine, when executed in the context of the display list, both lines for CMD_NUMBER are displayed correctly.
After restoring the rest of my original code everything is executed as it should, I even can remove the two extra VERTEX_FORMAT(0) lines that
were necessary before.
I noticed in ESE that both CMD_NUMBER and CMD_TEXT switch to use SAVE_CONTEXT / VERTEX_FORMAT(2) when going beyond 511 on the B817/BT818.
And with the BT820 SAVE_CONTEXT is replaced with REGION.
Oh wait, that is the issue, the destination in REGION is absolute, not relative, so with CMD_APPEND destinations are pointing to the wrong address in the display list.
At least there is a workaround, although it is exclusive to BT817/BT818/BT820.
Makes me again wonder why VERTEX_FORMAT(0) is not just the default.
Additionally I found that CMD_NEWLIST is not finishing on it's own, REG_CMDB_SPACE never indicates that the FIFO is empty.
Only after I removed the busy check things worked.
This behaviour is not documented and something I should try on the BT817.
I just implemented CMD_RESULT and had an idea.
The register region has room for over 2100 registers in the BT820.
Documented are 155 right now and regardless of how many register are undocumented, it should be highly unlikely that
there are not plenty of unused slots.
Can we please reserve a bunch and name them like REG_USER0 to REG_USER9?
Why?
Because CMD_RESULT(REG_USER0) would be nicer than needing to find places in the memory map over and over again.
I just added the functions for CMD_RESTORECONTEXT and CMD_SAVECONTEXT.
And I do not get it, what was the point of adding these as commands to the co-processor?
SAVE_CONTEXT and RESTORE_CONTEXT are display-list commands that were introduced with the FT800, IDs 0x22 and 0x23.
And executing these with the co-processor, like the rest of the display-list commands, never was an issue.
So instead of having the co-processor just copy over the commands to the display-list it now has to exectute the
command to write the same values to the display-list.
This really strikes me as weird.
And then these were the only display-list commands that got that privilege to be elevated to co-processor commands.
I am trying out the SD card functions now and just successfully used CMD_FSDIR.
CMD_FSDIR "only" returns a bunch of names.
How can I find out which of these names are directories?
Edit: I implemented CMD_FSSIZE and the number returned for directories is 0xffffffff.
Well, yes, that matches the description of CMD_FSSIZE, that entry is not a file, so no file of that name was found.
And consequently CMD_FSREAD and CMD_FSSOURCE return 2 on folders for file-not-found.
So when the name is returned by CMD_FSDIR and CMD_FSSOURCE returns 2, then it is a folder.
Hi Rudolph,
Thanks for your suggestion, we'll pass that back to our R&D team and get their feedback,
Best Regards, BRT Community
Quote from: Rudolph on April 15, 2025, 03:17:21 PM
I just implemented CMD_RESULT and had an idea.
The register region has room for over 2100 registers in the BT820.
Documented are 155 right now and regardless of how many register are undocumented, it should be highly unlikely that
there are not plenty of unused slots.
Can we please reserve a bunch and name them like REG_USER0 to REG_USER9?
Why?
Because CMD_RESULT(REG_USER0) would be nicer than needing to find places in the memory map over and over again.
Quote from: Rudolph on April 16, 2025, 10:03:16 PM
I am trying out the SD card functions now and just successfully used CMD_FSDIR.
CMD_FSDIR "only" returns a bunch of names.
How can I find out which of these names are directories?
Hi Rudolph,
One way to check is to perform a cmd_fssize. Directories will return -1 for the size.
We'll add that as a note in the document too,
Hope that helps,
Best Regards, BRT Community
QuoteOne way to check is to perform a cmd_fssize. Directories will return -1 for the size.
Well, yes and no, technically. :-)
The size is documented to be a uint32_t.
And I got a couple of steps further along now, my test code is using CMD_FSSOURCE, CMD_LOADIMAGE with OPT_FS and CMD_GETIMAGE
to load one of the files returned by CMD_FSDIR and then display it.
I also found OPT_TRUECOLOR during this.
Another day, another screen of progress. :-)
I just added CMD_LOADASSET and tried it with two fonts converted with EAB 3.0.
Loading from SD card is really nice.
I am wondering what is driving up the display-list so much.
EVE_cmd_cgradient(EVE_EDGE_ZERO, 300, 200, 200, 200, WHITE, PURPLE); - 140 bytes
EVE_cmd_arc(400, 300, 100, 110, 0, 16384); - 144 bytes
debug-output of 8 hex-numbers - 736 bytes
Ok then, most of it is for all the text.
Nice work Rudolph! Your application looks great and good to see you've got the SD card running,
Yes, the longer RAM_DL is a nice thing to have on the BT820B to support larger amounts of text etc.
Best Regards, BRT Community
I implemented a couple more commands and got to CMD_WATCHDOG.
Quote
The watchdog command enables the watchdog timer and sets the watchdog reset intervals in clocks.
The watchdog flag in REG_BOOT_CFG register must be set.
C prototype
void cmd_watchdog ( uint32_t init_val );
Command layout
+0 CMD_WATCHDOG(0xFFFF FF83)
+4 init_val
Parameters
init_val
Watchdog timeout initialization value, in clocks. Must be a sensible value to prevent
watchdog being triggered prematurely.
Examples
To set the watchdog timeout every 72000000 clocks, which is 1 second on a 72 MHz system:
cmd_watchdog(72000000);
Quote
Adds watchdog timer to facilitate automatic correction.
Quote
The watchdog timer uses a 32-bit counter and is driven by the system clock. Hence, at default system
clock of 72 MHz, the maximum timeout period supported is 59.6s.
The watchdog timer begins and resets as it counts down from a user-defined initial value. Upon reaching
a count value of zero, the watchdog timer generates a system reset. The timer needs to be periodically
reset to the initial value to prevent the system reset from happening.
Refer to BRT_AN_086 BT82X Series Programming Guide for details on how to program the Watchdog
Timer using cmd_watchdog
That is practically all if it.
So yes, the watchdog system needs to be enabled during boot.
And it does a system reset - whatever "automatic correction" this is good for.
Then there is CMD_WATCHDOG which is documented to enable the watchdog and configure the timeout.
But there is no command like CMD_TRIGGER_WATCHDOG, so CMD_WATCHDOG is resetting the timer?
And if CMD_WATCHDOG really is the only command, does a CMD_WATCHDOG(0) disable the watchdog?
What safety requirements are covered by this?
If the EVE chip would crash hard, and I never encountered this, would the watchdog timer really not be affected?
And how would a reset help in this scenario? The host controller had to detect either way that the EVE chip is not answering anymore.
Ok, different scenario, the host controller crashes, how would resetting the EVE chip help? The host controller would still be dead.
So when the watchdog is not triggered by CMD_WATCHDOG, the screen goes dark?
What am I missing here?
If the EVE chip would be able to reset the host controller, that would be different, that would make the EVE chip an external watchdog controller and that could be viewed as positive for the system safety.
But I would use a window-watchdog with challenge-response for such a task, preferably in a SBC.
I implemented CMD_LOADWAV and in order to test it I enable audio in BOOTCFG.
The screen stays black though.
The host command is correct, it changes from 0xff 0xe8 0xc0 0x00 0x00 to 0xff 0xe8 0xe0 0x00 0x00.
Things look normal on the logic analyzer, "only" the screen stays black.
I am not writing to any of the audio registers, including not using CMD_LOADWAV.
I even moved the buffers for the swapchains.
Is it possible that the audio engine is messing with the clock tree?
Some might have noticed it already, I uploaded a new library on Github: https://github.com/RudolphRiedel/EmbeddedVideoEngine
I had the idea of renaming my library for a while, "FT800-FT813" was just wrong for a while now.
However, renaming seemed to be a bit disruptive, so I created a new repository for V6 of my library and the name should be future-proof now. :-)
I was already using the name for a while now in the library.json for PlatformIO.
Yesterday I tested the Arduino example, made sure it compiles for all tagets (although a few are non functional like the one for BBC Microbit.
And then I tested ESP32-S2, Arduno UNO V3, Teensy 4.1, Raspberry Pi Pico and Metro M4 with both a RVT50H (BT817) and the VM820C.
Right now I have the VM820C with the 7" 1024x600 TFT up and running with an ATSAME51 after a fix to the DMA code, and I already checked it with a BT817.
As usual, no warnings with -Wall -Wextra -pedantic.
Before I was using a STM32F407, so most targets are covered by now, at least are compiling or actually are tested.
While the lib is feature complete for the BT820, this is not finished.
There are still a couple of things missing like configuring the memory size for the BT820, the LVDS output clock is merely working by chance now, Audio does not seem to be working at all, video input is unexplored...
Unfortunately there are no modules for sale with a BT820, as far as I know. And only one was anounced.
I also learned again that sourcing LCDs is still a major pain, these things are really not commodities, speaking of course for not buying in bulk from a company account, trying to aquire single units.
Time for some torture-testing of the BT820. :-)
The attached image shows this code:
int16_t xc0 = 0;
int16_t yc0 = 0;
uint16_t length = 3;
static uint16_t increase = 0;
uint32_t colors[] = {RED, ORANGE, GREEN, BLUE, YELLOW, MAGENTA, PURPLE, BLACK, 0xc0c0c0, BLUE_1};
for(uint8_t arms = 0; arms < 12; arms++)
{
EVE_color_rgb(colors[arms]);
EVE_begin(EVE_LINE_STRIP);
for(uint8_t steps = 0; steps < 135; steps++)
{
EVE_polar_cartesian(length*steps, arms*30+steps*increase, &xc0, &yc0);
EVE_vertex2f(xc0 + 450, yc0 + 320);
}
EVE_end();
}
static uint8_t delay = 0;
delay ++;
if(delay > 2)
{
delay = 0;
increase += 3;
}
12 Linestrips with 135 segments each, 6916 bytes in the SPI buffe, a display-list of >8100 bytes, takes 1.3ms to preprare the buffer.
And this runs continously now, changing constantly.
All I noticed was that it started to flicker when I increased the "steps" in the loop.
Not for every value of "increase" though.
The flickering goes away when I decrease the maximum "steps" or increase the time between display-list updates.
Right now I am running this as posted and refresh the display list every 75ms, so 13 changes per second.
So this put the render-engine into stress-mode, sort of.
Nice, this stupid level of useless complexity should be way beyond what a normal application can put out to render. :)
Any ETA on an updated BT82x programming guide?
A few answers to the more crucial questions I posted would be very nice beforehand.
Like how REG_LVDSTX_PLLCFG actually works - if the guide is wrong there and I am not using the register incorrectly...
And I have a new question.
Is there a way to check if rendering of a display list is done?
Well yes, I could read REG_RE_RENDERS and check for a change.
But this takes a bit of caution and requires to not into a deadlock.
Or I guess using CMD_GRAPHICSFINISH could work, reading REG_CMDB_SPACE after this should indicate that the co-processor is waiting for the render engine to finish.
Hmm, sounds like a plan, I maybe should always end the BT82x display list with CMD_GRAPHICSFINISH and not send a new display list when the co-processor is still busy.
Well yes, there might be other things to do for the co-processor while the render-engine is busy, like loading assets or using CMD_TEXTDIM, in that case ending the display-list with CMD_GRAPHICSFINISH might be a bit inefficent, perhaps, especially when the render engine needs a bit more time than usual.
Hello,
On the programmers guide point, this is currently going through the final review stages and we hope to have it released shortly.
I will follow up with the R&D team for your other queries.
Best Regards,
BRT Community
Ok, this got lost in the forums update, so I am trying to re-post.
Quote
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.
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
What's happening with BT822 ?
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.
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)
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.
Quote from: Rudolph on July 08, 2025, 06:23:04 PMBoth 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.
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
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 (https://brtchip.com/product/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
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. :)
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 (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
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. :)
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.
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.