BRT Community

Just saw that EAB 4.1.0 is finally: out https://brtchip.com/eab/

What's up? 
It has been three weeks again since the last post while there are 75+ daily visistors listed.

I implemented all of the BT822 patch functions, or at least these that are documented so far.
Actually testing these still is difficult since the new EAB has not been released.

I would like to buy a BT82x based display module, but the options are still very limited.

Today I received a ACD-110DHTT which is a 10.1" industrial touch monitor that I got used for only 23€ from EBay, 1280x800.
And of course I only took it apart, really nice build quality, the case is machined from a block of aluminium, I do not want to know how much these cost before they were phased out back in 2019.
The panel is a G101EVN01.0 from AUO for which I even found a datasheet, LVDS, single channel, 6 bits per color.

The touch is a separate unit and will provide more challenges, it uses an eGalax Touch controller.
On the outside the interface is USB, but it does support I2C as well.


Now, what is everyone else here up to?

Edit: I really have no idea why this site is practically dead, 144 views of this post and no reaction?
Ok, stay positive. :-)


I just spent some time to check the wiring of the ACD-110DHTT and adapt it the VM820C.
As it turned out, the wire harness of the display is using the exact same 6 pin / 2mm header for the backlight than the VM820C, I only had to swap two pins. 
And for LVDS the wire harness connects to the conroller board with a 32 pin / 2mm header which uses the same crimps than the 30 pin / 2mm headers I have for the LVDS TX of the VM820C.
The pinout was slightly different, but taking out the pins from the old header and putting it in the 30pin header was really easy.

Next I put in a 1280x800 profile, checked the data format, which is JEIDA / Format 1 for 18-bit RGB, checked the clock frequency range and configured REG_LVDSTX_PLLCFG accordingly.
And, yeah, it worked on the first try. 
Even the backlight control is working, as the panel has the backlight controller integrated and takes a PWM signal to control it.

I do not have touch, did not even try to connect it, so far I have no idea if the eGalax touch controller is compatible to anything the BT820 supports.

Hello,

I just found this:
https://brtchip.com/wp-content/uploads/2025/08/BRT_AN_095_BT82X-Firmware-Update-and-Extension-Guide.pdf

Nice, I was expecting something like this.

But the referenced patches are not available yet as an not yet released EVE Asset Builder is supposed to provide these in a new EXTENSION tab.
Please attach a full .bin here in the meantime for testing, the base patches and all extension patches in one binary.
Or, if that needs to be handled separately for some reason, the mentioned base_patch.bin plus a binary with all extension modules.

I would just drop that on the SD card for the BT820.

I recently found this:
https://brtchip.com/wp-content/uploads/2024/04/Errata-notification-2024-R2.pdf

It states:
"We are reaching out to notify an important Errata that has been identified on our BT81x / BT88x series. This
Errata pertains to specific user applications, which may affect the functionality or performance of the product
under certain conditions."


What this does not state is what the actual issue might be.
So, what is it?

Given the date of release this could appear in a version of BT81X programming guide later than 2.4.
But I don't see anything in the 2.5, 2.6 or 2.7 history that indicates an issue.

I vaguely recall seeing extra DISPLAY commands added to the end of the command list to address some issue, is this related to this erratum?

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

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.

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

Hello, it has been a few days since there was a rollback on the forum and nothing new got posted since then.
What happened?

See also here: https://github.com/RudolphRiedel/FT800-FT813/discussions/147

CMD_FLASHERASE does nothing on my RVT101H with a BT817 and some 512Mb Micron flash when the flash status is BASIC.
When I put the flash in FULL and then issue CMD_FLASHERASE, it does seem to do something, at least the flash can not be accessed anymore.
However, it takes very little time, this is not noticeable in the startup although Bulk Erase for the Micron devices I could find a datasheet for
is documented to take 153 to 460 seconds.

I did not notice this so far since I am not using CMD_FLASHERASE. Because of the time it takes and because I am using a fraction of the flash anyways.
I am using CMD_FLASHUPDATE, first writing the 4k for the .blob in BASIC and then switching to full for the complete image.

As I am still not seeing the board "Discussion - Software" while beeing logged in, I am asking here.
I wrote an email to the board admin address a while ago about this.

I am working on an exporter script for ESE that generates code which is compatible with my library FT81x / BT81x library.
I used one of the existing exporter scripts as a starting point and things are starting to make sense.

However, I just found that comments seem to be stripped from the data that is send to the converter script.
All comments, lines that only have a comment end up empty, lines that end up in comments have the comments removed.

All exporter scripts have this however:
  if (line.lstrip()).startswith("//"):
and
  functionName, functionArgs, comment = parseCommand(line, functionMap, convertArgs)

My .ese file:
        "",
        "/* foo */",
        "// foo",
        "VERTEX_FORMAT(0) // boo",
        "",

The result when printing out each line raw with
f.write("//  " + line + "\n")
plus either the parsed command line or
f.write("    \n")
in case the line was empty:
// 
   
// 
   
//  VERTEX_FORMAT(0)
    EVE_vertex_format(0);
// 
   

So, not only are all comments stripped, the lines with comments end up beeing empty lines instead of beeing removed.
Is this actually working as intended?

The BT82X Series Programming Guide 1.0 is released. :-)
I only saw it two days ago and I did not really have much time for it so far though.

One thing, I found CMD_ARC, nice.
But, this is the description:
"The arc command draws a circular arc. The end caps of the arc are rounded. If the angles specify a complete circle, a disc is drawn."

Is that correct? So not a circle, but a a fully filled round area like with POINTS?

void cmd_arc( int16_t x, int16_t y, unint16_t r0, unint16_t r1, uint16_t a0, uint16_t a1 );

That u*n*int16_t is an interesting typo. :-)

But more importantly, why is the inner and out radius limited to 1..511?
Hmm, yes, radius, not diameter, so quite big - but still, no flat arc over the complete height of the display for example.

And is there any way to influence the roundness of the end caps?

I was just looking at what accelerometers are available on Mouser, sorted by price, as to detect the orientation of the display the simplest option should do.
And the most inexpensive option that is available today is a MXC4005XC with an I2C interface.

Then it hit me, EVE already is using I2C for the touch sensor.
And at least electrically it would be a no-brainer to add a second chip to the existing I2C bus, the only thing to look out for would be the chips adresses.
So what is missing in order to support an optional accelerometer is some software in the EVE chip to detect such an accelerometer on startup, read the registers if a accelerometer is present, calculate the orientation of the device from it and then provide the information in a register.

REG_ORIENTATION
Bit 2 – 0: screen orientation information bits.
0b'000: Default landscape orientation
0b'001: Inverted landscape orientation
0b'010: Portrait orientation
0b'011: Inverted portrait orientation

Well, maybe that is a dumb idea as I have no idea so far how complicated it is to implement this in software.
Hmm, I could add an accelerometer with SPI to my controller board for EVE,
this might be something extra to do untill BT820 are available to play with. :-)

I am always looking for EVE modules to include support for in my library and I just found these from Winstar:

WF43WTYBEDST0 - 4.3" IPS 480x272 resistive touch, BT816
WF43WTYBEDSG0 - 4.3" IPS 480x272 capactice touch, BT815
WF50FSYBGDST0 - 5.0" IPS 800x480 resistive touch, BT816
WF50FSYBGDSGA - 5.0" IPS 800x480 capacitive touch, BT815

These might be Arduino shields and these might come in different versions.
Like with a SD socket, Arduino pins soldered in or a flash-chip - but none of these options are in the datasheets I found.

There is a 20pin header (FFC connector not populated) that looks like Winstar started with the pinout from Riverdi,
but pins 9 to 16 are different.
There is no Audio Out, the IOs are different and there are CSCL, CSDA, CRST and CINT pins for the ILI2130 CTP.

I wonder if the CTP is even connected to the BT815.

I am curious, but I can not find a distributor I would buy these from.
And Winstar only offers a short-form datasheet on their website.

Has anyone played with these?

The BRT_AN_088_FT81x_BT88x-Programming-Guide.pdf v1.0 documents CMD_SYNC for FT81x and BT88x.
But the earlier FT81X_Series_Programmer_Guide.pdf v1.0 does not have this command.

Do FT81x have CMD_SYNC?

Edit: I guess FT81x do have CMD_SYNC, I just noticed that CMD_SETBITMAP is command #0x43 while CMD_SYNC is #0x42.
And #0x44 is CMD_FLASHERASE.
So not mentioning CMD_SYNC in the FT81x documentation is likely an oversight which has been correct with BRT_AN_088.

I just actually used CMD_SCREENSAVER and found a minor issue.
The command does not respect the setting of VERTEX_FORMAT and therefore requires to set it to 4 like this with the display-list macro command for it:

EVE_vertex_format(4);
EVE_macro(0);
EVE_vertex_format(0);

I am using a FT813 right now, a BT81x will probably do the same.
This was easy enough to figure out, the only issue is, this is not documented while at least for the BT81x commands like CMD_ANIMXY have a note in the programming guide.

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. :-)

Not trying to discuss why, yet. :-)

But I am looking for an inexpensive camera module with LVDS interface.
And I am not finding any.

Either the cameras have USB, parallel Interface or MIPI-CSI.
Or I find cameras for 400+ EUR/USD.

Anything from 320x240 up to 2.3MP should do.

Maybe that is just something that is difficult to search for?

Ok, that this is supposed to actually display an Image surprised me:

Gpu_CoCmd_LoadImage(phost, 0, OPT_FLASH );
//Start drawing bitmap
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2II(0, 0, 0, 0));
App_WrCoCmd_Buffer(phost, END());


This made me wonder if Riverdi implemented the command with some extra lines.

But I found this in the BRT_AN_033_BT81X_Series_Programming_Guide V2.4:

cmd_loadimage(0, 0);
... // JPEG file data follows
cmd(BEGIN(BITMAPS));
cmd(VERTEX2II(10, 20, 0, 0)); // draw bitmap at (10,20)
cmd(VERTEX2II(100, 20, 0, 0));


This suggests that this is somehow supposed to work like this.

Next I did this in EVE Screen Editor:

CLEAR(1, 1, 1)
CMD_LOADIMAGE(0, 0, "someimage.png")
BEGIN(BITMAPS)
VERTEX2F(0)
END


And ESE was indeed displaying the image.

The generated display list is:
Offset
(decimal)          Raw      Text
0          0x26000007      CLEAR(1, 1, 1)
1          0x01000000      BITMAP_SOURCE(0)
2          0x28000000      BITMAP_LAYOUT_H(0, 0)
3          0x07310040      BITMAP_LAYOUT(ARGB4, 128, 64)
4          0x29000000      BITMAP_SIZE_H(0, 0)
5          0x08008040      BITMAP_SIZE(NEAREST, BORDER, BORDER, 64, 64)
6          0x1f000001       BEGIN(BITMAPS)
7          0x40000000      VERTEX2F(0, 0)
8          0x21000000      END()
9          0x00000000      DISPLAY()

Wait a second, CMD_LOADIMAGE is not supposed to have that effect.
But at least in ESE this works for FT81x, BT81x and BT88x.

I downloaded the sources from https://github.com/riverdi/riverdi-eve/tree/master and CoPro_Cmds.c has the implementation:


void Gpu_CoCmd_LoadImage(Gpu_Hal_Context_t *phost,uint32_t ptr, uint32_t options)
{
  Gpu_CoCmd_StartFunc(phost,CMD_SIZE*3);
  Gpu_Copro_SendCmd(phost, CMD_LOADIMAGE);
  Gpu_Copro_SendCmd(phost, ptr);
  Gpu_Copro_SendCmd(phost, options);
  Gpu_CoCmd_EndFunc(phost,(CMD_SIZE*3));
}


Nothing extra, just the command.
But somehow this still displays images? How?


So I tried to reproduce this on a display with BT817 with my library.
And I can not reprocuce this behaviour.
REG_CMD_DL does not change when I am issuing a CMD_LOADIMAGE.
And reading 20 bytes anyways from where REG_CMD_DL is pointing does not return BITMAP_SOURCE and so on.
Manually writing a different offset to REG_CMD_DL and reading it back afterwards shows no change either.


My last test code is this:
EVE_memWrite16(REG_CMD_DL, 0);
EVE_cmd_dl(0xdeadbeef);
EVE_cmd_loadimage(MEM_PIC1, EVE_OPT_NODL, pic, sizeof(pic));
EVE_cmd_dl(0xcafecafe);
EVE_execute_cmd();

for(uint8_t index = 0; index < 5; index++)
{
  array_test[index] = EVE_memRead32(EVE_RAM_DL + (4 * index));
}

array_test[5] = EVE_memRead16(REG_CMD_DL);


The EVE_cmd_loadimage() is working just fine, that image is loaded into memory and displayed with my regular display list.
But displaying the values from the array on screen only shows this:
DEADBEEF
CAFECAFE
30000000
30000000
27000000
8

And seeing that there is nothing in the CMD_LOADIMAGE doku that suggests that display list commands are generated, this result is to be expected.

What is going on then with ESE and especially the Riverdi / Bridgtek library?

The attached .zip has two .png files:
app_blocking_BAD.png
arrow_WORKS.png

And as the names imply, the one works, the other does not.
Why is that and what can I do to convert these .png into files that are compatible with EAB?


The icons are from Google: https://fonts.google.com/icons
There also is a Github repository: https://github.com/google/material-design-icons

What I am doing is to convert a bunch of icons to ASTC 8x8, load these into a BT817 and display them from RAM_G.
While arrow_WORKS.png works just fine as well as the other icons I received the same way, app_blocking_BAD.png and a lot of other icons I received differently just are displayed with a mono-chrom square although EAB claims the .png is valid and compatibel.
I loaded the files into paint.net and saw no fundamental difference, these are white symbols with alpha channel.
Saving app_blocking_BAD.png with paint.net made no difference, saving an "optimized" version with EAB made no difference.

Ok, how did I get these.
The file arrow_WORKS.png is from a set of icons that I manually downloaded from the web page like this:
https://fonts.google.com/icons?selected=Material+Symbols+Outlined:home:FILL@0;wght@400;GRAD@0;opsz@20&icon.size=16&icon.color=%23FFFFFF

But well, there are a lot of icons.

The Github repository: https://github.com/google/material-design-icons is a major pain as well, first the way the files are organized:
https://github.com/google/material-design-icons/tree/master/src/alert/add_alert/materialiconsoutlined/24px.svg
https://github.com/google/material-design-icons/tree/master/png/communication/call_made/materialiconsoutlined/48dp/1x/outline_call_made_black_48dp.png

A co-worker was intrigued and came up with a script that extracts the .svg, scales them with white color and alpha and saves them all in one folder.
The result are two folders so far with over 2000 icons each, one 64x64, the other 48x48.

I randomly selected 50 from the 64x64 for a test, converted these to ASTC 8x8 and only got colored squares on the display as a result.