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?

One thing that just struck me, FT81x and BT81x do "only" have a 22 bit address range, so 4 megabyte.
Does this mean that the BT822 will be using a new memory model with a 30 bit address range in order to support the 27 bit needed to address the 128 megabyte of embedded DDR3L SDRAM plus FIFO plus DL plus registers plus external Flash and so on?

That would indeed be a fundamental change if the first bytes to be send is 32 bit instead of 24 bit and a change that I really would apreciate.         

Ok, wow more nice features.

- 16kiB display list
- SD card support
- Audio is Stereo now and output is by I2S
- integrated Watchdog timer
- enhanced touch engine
- live video feed

Looks like there won't be a resistive touch variant this time and I can totally see why.
Edit: from one of the pictures: "Supports resistive and capactive touch panels..." - ok, so maybe both in one chip this time?

I guess documentation will become available with the launch in october?
Right now I am wondering if I will be improving my EVE library to support EVE-5 or if it would be better to do a separate library.
The memory layout is likely completely different which would make a new library without EVE2/3/4 support cleaner.

Any ETA on the availability of modules with display from Matrix Orbital, Crystalfontz or Riverdi?
I am very interested in buying a module with a BT822, 7" would be my sweetspot in regards of desk space needed. :-)
Heck, I would use a 5" if this is the first I can get my fingers on. :-)

Has there ever been a solution to this problem? Is there any answer from bridgetek?

No, yes and maybe.

No, since as far as answers from Bridgetek, this is it, the thread went dead.

Yes, and this is based on experience since then, not on real hard data.
While the flash connected to the BT81x allows to display images directly, there is a caveat.
First off all, the bandwidth for the QSPI attached NOR flash is limited, naturally.
And this is not only limited by the clock of the QSPI but also latency when loading different assets since
reading something requires to address the flash first.
As I understand it, the pixel engine works thru the whole display list for every single line to be displayed.
So, there is a limit up to which this works as a product of the total bandwidth, the amount of data to be read per asset
and how many assets are supposed to be read, this is just a physical limitation.
Ok, yes, EVE-4 was improved and can prolong the time spent a pixel line but this reduces the refresh rate.

My advice from this is, pretend displaying anything directly from flash is not working at all.
Make use of all RAM-G before you try even try this and if you run out of RAM-G check what options you have
before starting to display anything from flash, like using ASTC for everything and check if the higher compression variants work for you.
Heck, ASTC-8x8 gave us full color plus alpha with only 2 bits per pixel while still looking good, this is like RAM-G getting 8x as large.
Not because displaying from flash is not working in general, but because it is a finite resource.

This brings me to the maybe.
Given that I had the most issues with one particular brand and model, my conclusion is that there is probably
some issue with the layout of that board between the BT815 and the flash.
There might have been reflections on the QSPI due to an impedance mismatch, so a layout issue.
But I will never know as I do not have the proper equipment to really measure a 36MHz QSPI.
My only real hint is that I used BT81x modules from three other brands and these allowed to push things further.


And looking forward we have this:
https://brtchip.com/bridgetek-is-in-embedded-world-2024-austin-texas/

EVE-5 is launched at Embedded World in Austin, Texas in five weeks.
I have no idea what is coming (why oh why?  ) - but it has been a few years since BT817/BT818 was launched.

I even checked if I could attend the fair, but the 11 hour flight was a no-go for me.

Can we please get a confirmation for the polynomial and the start value?

And it might be a good idea to put this in a future revision of the programming guide.

Oh dear, that was stupid.
Of course. OPT_NODL did exactly what it is supposed to do.
That happens when you never used a command without that option, I did not even register it was there. :-)
Thanks for pointing that out!

With this:
EVE_memWrite16(REG_CMD_DL, 0);
EVE_cmd_loadimage(MEM_PIC1, 0, pic, sizeof(pic));

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);

I now get displayed:
0x010FA000
0x28000000
0x07399064
0x29000000
0x0800c864
0x14

Which should be pretty much on point, at least it is in regards of the commands and
the target address is correct.

To my defense, this is very vaguely documented:
"To minimize the programming effort to render the loaded image, there are a set of display list
commands generated and appended to the current display list, unless OPT_NODL is given."

It would have been helpfull to know what these display list commands are.
Now we have CMD_GETIMAGE with the BT817.
But like this the same information would be as easily accessible with a FT81x.
I am not loading random images but getting the format and the sizes like this was something that came up a while ago with no solution.

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?

To clarify, I am not really considering this a bug, I was more fishing for the answer "this is not a bug because..."
Well, maybe it is in that the color of fully transparent pixels should not be used for any kind of transformation.
But when searching for what color fully transparent pixels are supposed to have, I found no definitive answer,
I did find at least one recommendation to set them to black in order to avoid issues with layer composition.
However, it is rather inconveniant to find out what the issue actually is, apart from converting it to RGBA I still could not tell what color the fully transparent pixels do have, so I would apreciate it if EAB would at least warn about this.

I had a lengthy discussion with my co-worker who batch-converted the icons from .svg for me.
He is a gfx-designer from the team that puts out our companies style-guide for UI development and he was using some Adobe software for the conversion.
And he could not tell me either what color the fully transparent pixels have in the images he provided.
But if some Adobe software produces .png like this, you can bet that I won't be the last with this issue.