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?

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.

The "Serial Data Protocol" has three valid combinations for the start of a communication defined:

0 0 - Host Memory Read
1 0 - Host Memory Write
0 1 - Host Command

What happens though in the FT81x / BT81x if the first two bits are 1 1?
Is the byte discarded as invalid and the next byte used as actual start of the frame?
Or is the complete frame discarded as invalid?

Could 0xc0 0x00 0x00 0x00 used for cmd ACTIVE?
Could 0xc0 0x30 0x20 0x00 used to read REG_ID?

Edit: I was too curious to not try this although doing undocumented things does not yield reliable results.
I changed my host command implementation by sending out an extra byte first - unfortunately this does not work at all,
the screen stays black.
Adding a trailing byte after the host command works though, so at least these could be using 32 bit transfers.
My "issue" is with the 24 bits for Host Memory Read/Write though.

I just found that EAB 2.10.0 was released.

I went across it, converted images, verified images, converted a font, put that font in a flash container, packed that flash container with the asset compressor, converted the resulting .zopfli file with the BIN2C tool.
And this went very smoothly. :-)

I found one small issue though.
When converting fonts, the "Input Character:" file selection gets cleared every time a new font is selected.

Edit: just found 2.10.1 and the bug is still in while this post is still missing approval.
Edit2: and I just found 2.10.2 which is dated 2023-11-10.

I downloaded and installed EVE-Asset-Builder-setup-2.9_rc1.zip and I have an odd issue.

The button to open the explorer window to select the output folder is not working for me in "Asset Compressor" / "Compress".
When I use the button on the second tab "Validate" though it works, I can select the output folder, I have to confirm twice and
now the output folder is also changed on the "Compress" tab.

What is CMD_REGREAD supposed to be used for?
It does not seem to have any use when building a display-list and outside of display list handling it is more efficient to read from the address directly.

I am playing with EVE_cmd_regread() and EVE_memRead32() on a BT817 - the results are the same for the most part.

for(uint8_t index=0; index < 32; index++)
{
    test1[index] = EVE_cmd_regread(0x302000UL + (index*4));
    test2[index] = EVE_memRead32(0x302000UL + (index*4));
}

Some of the not documented registers seem to be pretty usefull, like 0x3021A8UL + 0x3021ACUL, I wonder why these are not documented.
Reading from the not documented REG_DATESTAMP returned a string: "2019-10-28_2.5.3"
Reading from for example 0x303000 returns 0xdeadbeef.
Reading from 0x309218 returns 3, whatever that means. :-)

Reading from RAM_JTBOOT (0x30b000) is returning inconsistent results between EVE_cmd_regread() and EVE_memRead32(), not like EVE_cmd_regread() is executed with higher privilege, more like what is returned for this memory region is not actually accessible for both functions.

The region from 0x309000 to 0x30914e has a few documented registers like REG_TRACKER and REG_FLASH_SIZE,
it is not mentioned in the memory map though, "Table 5-1 BT817/8 Memory Map".


I also had a look at the code for BRT_AN_025.
The functions EVE_CMD_REGREAD(), EVE_CMD_GETPROPS(), EVE_CMD_FONTCACHEQUERY(), EVE_CMD_GETIMAGE() and EVE_CMD_GETPTR()
are not implemented to do anything usefull and all these write out the parameters to EVE that are return parameters.
There is EVE_LIB_GetProps() though.

EVE_CMD_PCLKFREQ() does write the parameter "factual" although this is a return parameter.
EVE_CMD_FLASHFAST() does write the parameter "result" although this is a return parameter.
EVE_CMD_MEMCRC() does write the parameter "result" although this is a return parameter.

I just found this in BRT_AN_033 BT81X Series Programming Guide version 2.3 which was not there in the previous revisions:

Important Note:
When using this command, the flash BLOB is required in order to ensure that the calculated PLL2
setting remains within the specification of 228MHz. Therefore, before using this command, ensure
that the following steps have been taken:
- External Flash chip connected to the BT817/8
- External Flash chip has the BLOB installed in the first 4096 bytes beginning at 0
- External Flash chip has been set to full-speedmode

Is this an editorial error?

I have been using CMD_PCLKFREQ in my init from the very beginning when the documentation for the bits in REG_PCLK_FREQ was not correct.
I have never set the flash to fullspeed mode before using CMD_PCLKFREQ.
Also the the flash was empty for at least the first tries of bringing up a new BT817 module.
It works just fine this way.

What dependency is supposedly between the external flash chip and the PLL2 for the pixel clock?



And I just did what I guess was a bit overdue, I calculated all possible frequencies for the pixel-clock
that can be setup with PLL2 thru writing to REG_PCLK_FREQ.

REG_PCLK_FREQ[11:10] is the range for the PLL2 frequency and not part of the calculation, my guess this is used for validation.
00: 20 – 40 MHz
01: 40 – 80 MHz
10: 80 – 160 MHz
11: 160 – 228 MHz

REG_PCLK_FREQ[9:4] is multiplied by 12MHz and the resulting PLL2 frequency must not be higher than 228MHz,
so the effective range for this 6 bit value is 1 to 19.
I really hope this value can go a couple of steps higher in a future device.

REG_PCLK_FREQ[3:0] is the divider and the pixel clock is calculated with this formula:
PCLK frequency = PLL2 frequency / REG_PCLK_FREQ[3:0] / 2
This makes the useable range for this 4 bit value to go from 1 to 12, at least is unlikely that higher values are of use.
The pixel clock must not be higher than 96MHz.

I put it all in a spreadsheet and sorted it by pixel clock.
These are the top values:

11   10   9   8   7   6   5   4   3   2   1   0         Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
1   1   0   1   0   0   1   1   0   0   0   1   3377   D31   3   19   1   228   114,000
1   1   0   1   0   0   1   0   0   0   0   1   3361   D21   3   18   1   216   108,000
1   1   0   1   0   0   0   1   0   0   0   1   3345   D11   3   17   1   204   102,000
1   1   0   1   0   0   0   0   0   0   0   1   3329   D01   3   16   1   192   96,000 x
1   1   0   0   1   1   1   1   0   0   0   1   3313   CF1   3   15   1   180   90,000 x
1   1   0   0   1   1   1   0   0   0   0   1   3297   CE1   3   14   1   168   84,000 x
1   0   0   0   1   1   0   1   0   0   0   1   2257   8D1   2   13   1   156   78,000 x
1   0   0   0   1   1   0   0   0   0   0   1   2241   8C1   2   12   1   144   72,000 x
1   0   0   0   1   0   1   1   0   0   0   1   2225   8B1   2   11   1   132   66,000 x
1   0   0   0   1   0   1   0   0   0   0   1   2209   8A1   2   10   1   120   60,000 x
1   1   0   1   0   0   1   1   0   0   1   0   3378   D32   3   19   2   228   57,000 x
1   0   0   0   1   0   0   1   0   0   0   1   2193   891   2   9   1   108   54,000 x
1   1   0   1   0   0   1   0   0   0   1   0   3362   D22   3   18   2   216   54,000
1   1   0   1   0   0   0   1   0   0   1   0   3346   D12   3   17   2   204   51,000 x
1   0   0   0   1   0   0   0   0   0   0   1   2177   881   2   8   1   96   48,000 x

The first three are not valid as these are above 96MHz.
The lines with the "x" at the end are also found in the table 4-11 of the BT817/8 datasheet.

This is a bit of a surprise for me as I went the first time thru this, there are very few frequencies to choose from above 60MHz.
Totally plausible when put in a table like this.

I was feeding CMD_PCLKFREQ with 71MHz for the 1280x800 displays.
And now I see that this is not even possible and the result likely was 72MHz.
The reason why I even looked into this is that the 10.1" panel with 1280x800 that I am trying to add a configuration for
is using a pixel clock of 72.4MHz (typical).
Ok, no problem, 72MHz it is.

I went with using CMD_PCLKFREQ as my first calculations with the previously incorrectly documented bits for REG_PCLK_FREQ got me nowhere.
And using CMD_PCLKFREQ did not only work, it looked like it allowed more flexibility over the apparently select "few" values
for REG_PCLK_FREQ in the datasheet.
Now I will remove the call to CMD_PCLKFREQ.

And as a final thought, these are the values if the PLL2 frequency would be allowed to go up to 480MHz:

   Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
E02   3   32   2   384   96,000
DF2   3   31   2   372   93,000
DE2   3   30   2   360   90,000
DD2   3   29   2   348   87,000
DC2   3   28   2   336   84,000
DB2   3   27   2   324   81,000
E83   3   40   3   480   80,000
DA2   3   26   2   312   78,000
E73   3   39   3   468   78,000
E63   3   38   3   456   76,000
D92   3   25   2   300   75,000
E53   3   37   3   444   74,000
D82   3   24   2   288   72,000
E43   3   36   3   432   72,000
E33   3   35   3   420   70,000
D72   3   23   2   276   69,000
E23   3   34   3   408   68,000
D62   3   22   2   264   66,000

The granularity is only a little higher so "just" allowing the PPL2 to run much higher does only achieve very little.

Adding a pre-scaler to bring down the 12MHz to a lower value before it is fed into the PLL2 would be much simpler to implement,
under the assumption that the multiplier already works all the way up to 63x.
So I kind of wish now that a future device would feature a clock pre-scaler for PLL2. 

This is the top of the table with a pre-scaler of 4 so the PLL2 gets 3MHz as input frequency:

   Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
FF1   3   63   1   189   94,500
FE1   3   62   1   186   93,000
FD1   3   61   1   183   91,500
FC1   3   60   1   180   90,000
FB1   3   59   1   177   88,500
FA1   3   58   1   174   87,000
F91   3   57   1   171   85,500
F81   3   56   1   168   84,000
F71   3   55   1   165   82,500
F61   3   54   1   162   81,000
F51   3   53   1   159   79,500
F41   3   52   1   156   78,000
F31   3   51   1   153   76,500
F21   3   50   1   150   75,000
F11   3   49   1   147   73,500
F01   3   48   1   144   72,000
EF1   3   47   1   141   70,500
EE1   3   46   1   138   69,000
ED1   3   45   1   135   67,500
EC1   3   44   1   132   66,000

As I am going thru the MISRA-C report for my library I am finding API inconsistencies.

CMD_BITMAP_TRANSFORM
The given C prototype has "uint16_t result" as last parameter.
While this by itself is not correct and "result" should either be the return value or a pointer,
the description for result is:
"result return. Set to -1 on success, or 0 if it is not possible to find the solution matrix."

Which one is it, uint16_t or int16_t?
And actually the native type for RAM_CMD would be uint32_t.