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

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

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

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

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


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

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

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

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

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

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

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

Here are my observations:

1) The memory region RAM_ERR_REPORT was renamed to RAM_REPORT.

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

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

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

Not fundamentally, but this is still a bit strange.

from EVE_HAL.c:

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

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

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


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

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

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

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

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


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

The prototypes are not what I am looking for, I am looking for what the functions are supposed to do,
hence the extract with the "prototype" and the "layout".

But the important part of my post is, at least BRT_AN_086_BT82X-Series-Programming-Guide_1.0.pdf and BRT_AN_033_BT81X_Series_Programming_Guide_2.6.pdf are not consistent enough to have ChatGPT successfully write a python script to extract function requirements.
I even reached the point now that ChatGPT can no longer fix the script further, the script changes, but the result stays the same.

The data really is not an issue, I get about 95% extracted fine and can fix the rest manually.

I am trying to extract requirements for the commands from the programming guides, I am thinking about doing unit tests for my library and I need requirements for these that are not derived from my code.
The least I could do with such a list of requirements would be to check it against my header file.

After a number of iterations with ChatGPT the resulting .json starts to look ok:


   {
    "prototype": "void cmd_swap( );",
    "layout": [
      "+0 CMD_SWAP(0xFFFF FF01)"
    ]
  },
  {
    "prototype": "void cmd_append( uint32_t ptr, uint32_t num );",
    "layout": [
      "+0 CMD_APPEND(0xFFFF FF1E)",
      "+4 ptr",
      "+8 num"
    ]
  },


I ran into several issues though and I could not fix them all, yet.

First of all, the layout of the document, there a couple of "C prototype" that cross page boundaries so I end up with this:


  {
    "prototype": "void cmd_mediafifo ( uint32_t ptr, 119 Product Page Version 2.6 Document Reference No.: BRT_000225 Clearance No.: BRT#129 uint32_t size );",
    "layout": [
      "+0 CMD_MEDIAFIFO (0xFFFF FF39)",
      "+4 ptr"
    ]
  },



Then consistency.
Commands that need to be followed by data like cmd_inflate should have a pointer for that data as parameter and also a parameter for the amount of bytes.
But the real issue is how the "Command layout" looks like.

CMD_INFLATE: +8 ...n byte0 ... byten
CMD_INFLATE2: +9....+n byte1...byten (which is plain wrong since options is 32 bit wide and data starts at byte 0)
CMD_LOADIMAGE: +12 byte 0 / +13 byte 1 / ... ... / +n byte n - creative, but why so different?
CMD_PLAYVIDEO: +8~ +n byte1 ... byten - even more creative and also wrong with byte1
CMD_FLASHSPITX: byte1...byten the data to transmit - does not state the offset
CMD_FLASHWRITE: +12...n bytes1 ...byten
CMD_MEMWRITE: +12 ...n byte0 ... byten


BT82x:
CMD_INFLATE: +12....+n byte1...byten - also not correct as data does not start at byte 1.
CMD_LOADASSET: +12 byte1 ... byten
CMD_LOADWAV: +12~ +n byte1 ... byten

And for text we have these:
CMD_BUTTON: +16 s / +17 ... / ... ... / +n 0
CMD_KEYS: +16 s / ... ... / +n 0
CMD_TOGGLE: +16 s
CMD_TEXT: +12 s / .. .. / .. 0 (null character to terminate string)
CMD_TEXTDIM BT82x: +12 s / .. .. / .. 0


That is nothing that can't be fixed with a little manual editing and/or perhaps a couple more exceptions for the parser,
but a good specification should be correct and consistent across the board.

And I just noticed for example that for BT82x CMD_COPYLIST, CMD_SAVECONTEXT and CMD_RESTRORECONTEXT are skipped, the function prototypes for these do not have the ";" at the end.

My take on this was that the .raw file is just stripped of the header: https://github.com/ARM-software/astc-encoder/blob/main/Docs/FileFormat.md

But, I just found out that while this is true for EAB v3.0.0, this is not the case for EAB v2.13.0.
No idea what is going on there, but the .astc and .raw of EAB v2.13.0 are not the same when you strip the header.

The images from 2.x worked fine, but this is strange.
Both are using the same ASTC encoder which is v4.5.0 from June 2023 (why this old?)

Anyways, skipping the header when saving the file should be fine.

However, given previous experiences with ASTC encoding, especially font conversion, I wonder if running the ASTC encoder on anything that still can be called a micro-controller is even possible, even more so at 1280x800.
My desktop CPU merely blinks with the current EAB when converting stuff, but it has AVX-512 SIMD instructions and plenty of memory.

Quote
Regarding Q2, yes I presume resolution 1100x700 by itself is not a problem. The problem is my image. Find attached original and converted image, encoded with ASTC 4x4 and 6x6.

The issue really is with the memory layout of the format, the compression works in blocks of pixels.
1100 / 4 = 275
1100 / 6 = 183,333 -> needs 1104

Quote from: TreeOone on May 30, 2025, 09:41:41 PM
Hi.

Sometimes, because of answers ,,Whatever the correct way is to calculate Stride and Height in BITMAP_LAYOUT for ASTC, just stop using it and switch to CMD_SETBITMAP", I begin to think who on earth would want to use Bridgetek's solutions.

What do you want me to say?
CMD_SETBITMAP is part of Bridgetek's solution, this coprocessor command was introduced with the FT81x back in 2015.
And the only time I would not use it would be to optimize the display list, like for example when trying to display several images with
the same format and resolution.

Edit: forgot to mention, I really have no idea how to get to
BITMAP_LAYOUT(GLFORMAT, 976, 94)
from  500x376 and ASTC_4x4.
That is a factor of 1.952 for Stride and 1/4 for Height - why?

Quote
Regarding your question, there is a function BITMAP_SOURCE in your library, but it is missing option to set FLASH as a source. One can not set bit No. 23 to 1.

Code Select Expand

//#define BITMAP_SOURCE(addr) ((DL_BITMAP_SOURCE) | ((addr) & 0x3FFFFFUL))
/**
* @brief Set the source address of bitmap data in RAM_G or flash memory.
* @return a 32 bit word for use with EVE_cmd_dl()
*/
static inline uint32_t BITMAP_SOURCE(const uint32_t addr)
{
    return (DL_BITMAP_SOURCE | (addr & 0x3FFFFFUL));
}


You are correct, this is a bug and I just fixed it, thank you!

Quote
I have 2 more questions:

Q1: Can you perhaps say why EAB, when generating ASTC images, creates files with extension .astc and .raw. If .astc is given to BT817, image does not load well, whereas .raw generates image OK. What's the difference? I also tried creating ASTC images with ASTC encoder (downloaded from official ARM's GitHub page). Same problems. Results are not compressed.

The .astc files have a 16 bytes header, there is software out there that can use these, like Neosis:
https://www.richwhitehouse.com/index.php?content=inc_projects.php&showproject=91

And I would prefer if the generation of the .astc, .json and .rawh files as well as the _converted file would be optional in EAB
with the default that these are not generated.

Quote
Q2: I noticed some images encoded in ASTC_6x6_KHR display correctly, whereas when they are encoded in ASTC_4x4_KHR, they do not display at all. I am talking about same original image, for which EAB created two .raw files, one with 4x4 and other time with 6x6 encoding. What is the catch here? My test image has resolution 1100x700 px. The only difference which I can see is that result of 4x4 encoding has 1100x700 px, whereas if it is encoded with 6x6, resolution changes to 1104x702 px.

I only displayed the two .astc for the 1100x700 image I converted just now with Neosys and they work both fine.
The change in X/Y is necessary for the memory layout of the format.

Quote
I am not sure this is OK:

Code Select Expand


EVE_cmd_dl(BITMAP_LAYOUT(EVE_GLFORMAT, image_width * bits_per_pixel / 8.0, image_height));


And you are correct, this is not right.
Not that I could tell how these values are calculated, I tried this in EVE Screen Editor.

And for
CMD_SETBITMAP(0x800000 | 128, COMPRESSED_RGBA_ASTC_4x4_KHR, 500, 376)

The generated display list code is:

BITMAP_SOURCE(0x800000 | 128)
BITMAP_SIZE_H(0, 0)
BITMAP_SIZE(NEAREST, BORDER, BORDER, 500, 376)
BITMAP_EXT_FORMAT(COMPRESSED_RGBA_ASTC_4x4_KHR)
BITMAP_LAYOUT_H(1, 0)
BITMAP_LAYOUT(GLFORMAT, 976, 94)

Whatever the correct way is to calculate Stride and Height in BITMAP_LAYOUT for ASTC,
just stop using it and switch to CMD_SETBITMAP.


Edit: forgot to ask:

Quote
// Source is FLASH -> can NOT use Rudolph's library

Why?

This forum still is "missing" a thumbs-up feature as quick feedback for posts.

Oh, this is what you meant by "I have solved it", now I can access the board with this account as well.

I tried to register a test account and it took me 20+ attempts to get past that captcha.
Ok, now I have to wait for approval.

I am using FireFox.
So I just logged in with this account using Edge - same thing, the board only shows when I am not logged in.
And I see the board when I log out in FireFox, it vanishes as soon as I log back in.

With the update to the newer board software version, the board "Discussion - MCU" still does not show when you are logged in.
I only know that it does exist from checking the forum at work.
And it shows up when I open a private window in firefox.

That also means that there is no way to post in that board.
Like for example pointing out that the download link for the new ESE 5.0.1 is linking to the wrong file.
Edit: and I just downloaded and installed it now

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.

Unfortunately I can not repost directly, I am not making backups of the posts here. :-)
And I checked the wayback machine, no backup there either.

Well, now we know.

Well, let's try. :-)

Do you have a chance to restore the couple of posts that got lost?