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?

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

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.

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

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?

I am using a RVT101HVBNWC00-B from Riverdi which is a BT817 with a 1280x800 panel.
And to rotate the screen does not work properly, just flipping it with either REG_ROTATE set to 1 or using CMD_SETROTATE(1) causes major distortion.

When I use CMD_SETROTATE(5) it curiously works fine though, I have no use for a mirrored image though.

0 - image is fine, just for reference
1 - image is distorted
2 - image is fine
3 - image is distorted
4 - image is distorted
5 - image is fine
6 - image is fine
7 - image is distorted

And right now it does not have to display much at all, it looks like this with more empty pixels:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

Pixelclock is 72MHz with REG_PCLK_2X set to 1.

Hmm, I dropped the pixel clock to 51MHz with REG_PCLK_2X set to 0 and now the flipped image is fine.
But this dropped the frames/s as well and the pixel-clock is now well below the minimum of 66.3MHz that is listed in the datasheet.

I set REG_PCLK_2X to 1 while still using 51Mhz -> image is distorted when flipped.
I set REG_PCLK_2X to 0 while using 72MHz -> image is fine.
I set REG_PCLK_2X to 0 while using 66MHz -> image is fine.

Any more advice on this why REG_PCLK_2X = 1 with REG_ROTATE = 1 leads to a distorted image?

At 72MHz pixel-clock with 72Mhz system clock the datasheet says that REG_PCLK_2X needs to be set to 1.
And 66MHz is out of spec for the panel, although barely, it is not possible though to set PLL2 to anything between 66MHz and 72MHz.

I reduced the pixel clock to 38MHz and it still works, here at my desk.
But there is no way to tell what will happen out in the field with -20°C....+60°C.

I received a newsletter from Bridgetek on my work account that indicated that BT882 and BT883 are released, but I can not find any specifics for these.
Am I correct to assume that these are memory reduced variants of FT812 and FT813?
So like BT880 and BT881 but with 24 bit RGB interface?

Or are these BT815/BT816 or even BT817/BT818 with reduced RAM_G?

I very much prefer BT81x over FT81x for mostly three reasons, UTF-8 fonts, external Flash interface and ASTC compressed images.
And it seems like at least having ASTC would be a good idea when the size of RAM_G is reduced to a quarter.

On a slightly related note, do you have a list of display modules that are available for end users from different manufacturers?
I could probably compile such a list, but I am always on the lookout for something new to support with my library.

I received an image file to conduct a test with and this image file is a .png.
Long story short, the image gets decoded to ARGB4 and not RGB565.

There is OPT_RGB565 in chapter 5.9:
Decode the source image to RGB565 format - CMD_LOADIMAGE

And the first idea I had was to provide this option in order to make CMD_LOADIMAGE
decode the .png file to RGB565.
But then I saw that the value for the option is actually zero, so this "option" does not actually do anything,
this is just the default value, this is !OPT_MONO.
As I was already using CMD_LOADIMAGE with bit 1 of the options cleared, this "option" OPT_RGB565 has no effect on loading PNG images.

Please consider removing OPT_RGB565 from the table in chapter 5.9.