BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rudolph

Pages: 1 2 [3] 4 5 ... 30
31
Discussion - EVE / Re: BT816 Read CRC Flash
« on: July 10, 2024, 10:39:04 AM »
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.

32
Discussion - EVE / Re: Load image
« on: June 27, 2024, 08:32:08 PM »
Looks like you used the .astc file, you need to use the .raw file.
The .astc file has an extra 16 bytes of file header.

I am not using the example, I only wish it would be optional to write that to disk.
Same goes for the .astc the .json, the .rawh and the _converted.png.
When converting a bunch of files the cleanup takes longer than the conversion.

Some for fonts, all I need is the .glyph and the .xfont file, not the three extra files, not the example and
certainly not that a folder is created with a sub-folder for every font size.


>What is strange that's my original PNG file has dimension 75x75 pixel and generated by EAB is 80x80 pixel.

Yes, that is a limitation of the format, you need sizes that can be divided by 8.

>Now, how EVE fundamentally works is that a display list gets executed internally...

One thing that I forgot to mention when I tried to be both brief and informative,
the display-list is double-buffered, you can not change the active one, you update the inactive one and CMD_SWAP then
exchanges it with the active list and so on.
The only bad idea there is trying to SWAP the list faster than the screen is refreshed.



33
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:
Code: [Select]
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.

34
Discussion - EVE / Re: Load image
« on: June 25, 2024, 07:05:52 PM »
Ok, first, I have my own library and I have a basic example: https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/examples
All the examples use the same code, one of these is: https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_Arduino_PlatformIO/src/tft.c
Just as something extra to check out.

Now, how EVE fundamentally works is that a display list gets executed internally, typically 60 times per second.
There is no screen buffer, the whole display is composed on the fly over and over again.
The display list can be written directly to with basic commands but usually is generated with the command co-processor as this allows mixing basic commands with more high-level commands like CMD_BUTTON.
And then there are assets like images and fonts (ok, technically also images).
The FT81x / BT81x EVE chips do have 1Mib of integrated memory for anything we want to put there.

So in order to display an image we first need to put it in RAM_G - but we only need to do this once.
This is something for the initialization phase of the software as a whole lot of data needs to be transferred thru SPI.
Unless you run out of RAM_G when your UI gets complex with several screens perhaps, you transfer the images once and be done.

So first do the setup:
Code: [Select]
...
Gpu_CoCmd_FlashHelper_SwitchFullMode(&host);
...
Gpu_CoCmd_FlashSource(phost, PARAMETERS_ADDRESS_MEM);
Gpu_CoCmd_LoadImage(phost, ADDRESS_IMAGE1, OPT_FLASH );
App_Flush_Co_Buffer(phost);
Gpu_Hal_WaitCmdfifo_empty(phost);
Gpu_CoCmd_FlashSource(phost, NEXT_ADDRESS_MEM);
Gpu_CoCmd_LoadImage(phost, ADDRESS_IMAGE2, OPT_FLASH );
App_Flush_Co_Buffer(phost);
Gpu_Hal_WaitCmdfifo_empty(phost);
...

And when everything is setup, write your display-list.
I am kind of gussing my way thru this library here.

Code: [Select]
Gpu_CoCmd_Dlstart(phost);
App_WrCoCmd_Buffer(phost, CLEAR(1, 1, 1));
App_WrCoCmd_Buffer(phost, VERTEX_FORMAT(0)); /* set the pixel precision for VERTEX2F to 1 */

App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));

App_WrCoCmd_Buffer(phost, COLOR_RGB(255, 255, 255));
Gpu_CoCmd_SetBitmap(phost, ADDRESS_IMAGE1, FORMAT_IMAGE1, WIDTH_IMAGE1, HEIGHT_IMAGE1);
App_WrCoCmd_Buffer(phost, VERTEX2F(15, 15);

App_WrCoCmd_Buffer(phost, COLOR_RGB(255, 255, 255));
Gpu_CoCmd_SetBitmap(phost, ADDRESS_IMAGE2, FORMAT_IMAGE2, WIDTH_IMAGE2, HEIGHT_IMAGE2);
App_WrCoCmd_Buffer(phost, VERTEX2F(130, 15);

App_WrCoCmd_Buffer(phost, END());

App_WrCoCmd_Buffer(phost, DISPLAY());
Gpu_CoCmd_Swap(phost);
App_Flush_Co_Buffer(phost);
Gpu_Hal_WaitCmdfifo_empty(phost);

So this display list should display your two images when you fill in the missing information about the images.

I added
App_WrCoCmd_Buffer(phost, COLOR_RGB(255, 255, 255));
for each image and this is where things are getting more interesting.

If you send the display list either cyclically (my preferred method) or when there is a change (needs to have a minimum delay between updates),
you can modify the colors each time,
For example to visually indicate that a touch was detected for an icon.

And again, for this it is not necessary to setup the images again in RAM_G.

Well, and there is a couple more things. :-)

35
Ok, that this is supposed to actually display an Image surprised me:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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:

Code: [Select]
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.

Code: [Select]
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?

36
Discussion - EVE / Re: Load image
« on: June 24, 2024, 05:17:01 PM »
Not my library, so I am not actually sure what potential side-effects are.  ;)

However, I see that you are mixing utility commands with display list commands.
Try to make things a bit cleaner first, do not throw everything between one pair of Gpu_CoCmd_Dlstart (phost); / Gpu_Hal_WaitCmdfifo_empty(phost); calls.

Setup things first, like you already did with the Gpu_CoCmd_MemSet().

I mean this stuff:
Gpu_CoCmd_FlashHelper_SwitchFullMode(&host);
Gpu_CoCmd_FlashSource(phost, PARAMETERS_ADDRESS_MEM);
Gpu_CoCmd_LoadImage(phost, 0, OPT_FLASH );

Move it out of the display-list building.
Especially so as using .png has the tendency to take quite some time and it wrangles the uppper 42k of memory.

I provide separate functions in my library.
One group that is meant to be called outside of display list building and that already includes execution
and waiting for the operation to be done.
And one group that is meant to be called when building a display list.

As you do have an external flash I would also advise to use ASTC 8x8 format, not to display directly from flash necessarily,
but mostly ASTC 8x8 is a 32 bit format with 8 bit alpha that only needs 2 bits per pixel.
And PNG is decoded to well, some format, that needs 8 or 16 bits per pixel.

Gpu_CoCmd_FlashSource(phost, PARAMETERS_ADDRESS_MEM);
Gpu_CoCmd_LoadImage(phost, 0, OPT_FLASH );
Gpu_CoCmd_FlashSource(phost, NEXT_ADDRESS_MEM);
Gpu_CoCmd_LoadImage(phost, 0, OPT_FLASH );

This loads two images from different flash addresse but decodes them both to address 0 of RAM_G.

This is missing CMD_SETBITMAP:
//Start drawing bitmap
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2II(130, 15, 0, 0));
App_WrCoCmd_Buffer(phost, END());

I wonder why the images are even displayed.

And the artefacts are likely the result of
Gpu_Hal_WrCmd32 (phost, CMD_MEMCPY)
As this also goes to address 0 of RAM_G.

37
Discussion - EVE / Re: PNG issue with EAB
« on: June 11, 2024, 05:53:38 PM »
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.

38
Discussion - EVE / Re: PNG issue with EAB
« on: June 10, 2024, 05:03:08 PM »
I tried something different, I used an online converter to convert .png to .rgba and this is the result:

Original:
FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 40 FF FF FF EF FF FF FF 9F FF FF FF 00 FF FF FF 00
FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF BF FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00

Fixed:
00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF 40 FF FF FF EF FF FF FF 9F 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF BF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF BF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So, in the original file all pixels are set to white and the transparent pixels have Alpha set to zero.
And in the one that works with the BT817, all transparent pixels are set to black.

Why is this not a bug in the render engine of the BT817?
The mean part in this is that Paint.net for example displays the images without any difference, the fully transparen pixels do not seem to have a color.

39
Discussion - EVE / Re: PNG issue with EAB
« on: June 08, 2024, 12:44:09 PM »
I tried some more things.
It looks like the Alpha channel is set to white in the icons that do not work and black in the icons that do work.
But I have not found a tool yet that actually confirms this.

In binary these files that are displayed practially the same with ESE for example look totally different:
app_blocking_20dp_64x64_COMPRESSED_RGBA_ASTC_8x8_KHR.astc
13 AB A1 5C 08 08 01 40 00 00 40 00 00 01 00 00
FC FD FF FF FF FF FF FF 00 00 00 00 00 00 00 00
44 8D 48 08 04 C0 88 59 03 07 07 03 01 00 00 00
44 CD 16 28 47 07 08 20 FF FF FF FF 7F 7F 00 00
0A 08 0F E1 FF 1F EA 1F 00 00 00 00 FF FF 0F 00

app_blocking_20dp_64x64_COMPRESSED_RGBA_ASTC_8x8_KHR.astc
13 AB A1 5C 08 08 01 40 00 00 40 00 00 01 00 00
FC FD FF FF FF FF FF FF FF FF FF FF FF FF 00 00
24 8D 25 28 08 E0 0B E1 0B 83 C1 60 00 00 00 00
14 85 FE FF 03 FE 71 7F 7F 7F 7F 7F BD 05 00 00
1A 80 FF FF FF FF FF FF 01 FE 01 84 CF E7 17 00

Btw, I found this: http://www.richwhitehouse.com/index.php?content=inc_projects.php&showproject=91
Neosis can display .ASTC files, among man other formats.

And when I use the "Cycle blend" option it goes thru two transparent views and one view that has the alpha as solid color.
The icons that do not work are shown with white background, so all white, the icons that do work are shown with black background.

With this I just used IrfanView to batch-convert all the .png icons.
The option that does seem to do the trick is "Use main window color for transparency" combined with "Save transparent Color" and "Save Transparency as Alpha channel".

So I put a bunch of icons again thru EAB, rebuilt _iconlibrary.astc, zopfli compressed it, converted to to .c, put it in,
built the software and displayed the result on the BT817.
And now the icons are working.  :)

There may have been a loss in quality due to the conversion, at least it looks like the anti-aliasing could be better.
But maybe now we can find where it went wrong with the original conversion from .svg and re-do it.

So if I am correct and the color of the alpha-channel is set to white instead of black, this is probably something that the
PNG/JPEG Validator in EAB should point out and something to fix for the "Generated Optimized File" option.

I could not find an option to do that in the used "optipng" though.
What I found is that the version used is 0.7.7 and the optipng homepage states:
"You are strongly encouraged to upgrade to the latest version." - and lists security sensitive issues with the previous versions

40
Discussion - EVE / Re: PNG issue with EAB
« on: June 05, 2024, 02:21:35 PM »
Ok, things got even stranger.

I wrote a python script that merges all the .raw files in the current folder into a _iconlibrary.astc file.
This works fine as the icons I am using have 64 x 64 pixel and I am compressing these with ASTC 8x8 which results in 1024 bytes per icon,
so each icon is aligned to 1024.
And the _iconlibrary.py generates a header file like this:
#define ICON_APP_BLOCKINGX 0xf0000UL
#define ICON_APP_BLOCKING_20DP 0xf0400UL
#define ICON_APP_BLOCKING 0xf0800UL
#define ICON_ARROW 0xf0c00UL

There is just an index that starts at a fixed number and gets increased by 1024 with each new file merged.
Now I can just include the header and reference the icon address in RAM_G by name.
And so far I reserved space for 55 icons.

Not very flexible and a number of conditions, but it does the job.

I compress the _iconlibrary.astc with EAB to _iconlibrary.zopfli, convert it to a .c file and put that in my source-code,
then I use CMD_INFLATE to put the data into RAM_G.
So the _iconlibrary.zopfli can not really be corrupt or the code on my display would fail completely.
And most of the icons in this set work, only a couple do not work.

app_blocking.png - does not work
app_blockingX.png - does not work, for this I opened app_blocking.png in paint.net and saved it again
app_blocking_20dp.png - works, downloaded with the web-interface

Now here is where it gets weird, I created an ESE project with _iconlibrary.astc at the same address and
the two icons that are not shown on the display work just fine with ESE.
So the pixels are there but somehow ESE can show them while my BT817 can not?

Maybe it is the compression? Well, the icons I downloaded directly are all fine.

What is going on and how do I fix this?

41
Discussion - EVE / PNG issue with EAB
« on: June 04, 2024, 05:15:03 PM »
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.

42
Discussion - EVE / Re: Eve3 built-in fontset
« on: June 02, 2024, 05:37:03 PM »
I am comparing font 32 right now with the one that I converted on the display.
And while it looks good, the size is not correct.
This is with the V1 of Roboto-Regular.ttf you provided but a V2.137 and a version that I modified show the same false size.

Please provide a list of "Font Size" values used to convert fonts 26 to 34.

I believe now that font #32 was converted with a font size of 54.
At least the lengths of the strings match.

And now I ran into the next issue, at least the "1" looks different in the ROM font when compared to V2.137 of Roboto-Regular.ttf.
Ugh, looks like I need to use V1 after all and start from scratch.

After I played some more, I do not get the font sizes for 28, 29 and 30 to match, did not try for 26, 27, 33 and 34.


43
Discussion - EVE / Re: What are the correct settings for my screen?
« on: May 28, 2024, 03:39:02 PM »
But if my system clock is 72MHz PCLK=8? or both work?

With 72MHz system clock and PLCK=7 you get 10.286MHz pixel-clock and 66.34Hz,
with PCLK=8 it is 9MHz and 58.05Hz.
So yes, PCLK=7 is for 72MHz system clock and yes, both settings should be fine.

And of course, if you are using a BT817 you could use the second PLL and set it to 9.333MHz pixel clock for 60.19Hz.
Plus you can modify the timing parameters a little for fine-tuning, these are not strictly fixed, it should not hurt for example to make HCYCLE a bit larger.

44
Discussion - EVE / Re: What are the correct settings for my screen?
« on: May 25, 2024, 07:38:30 PM »
That looks like a panel similar to what is used in the RVT43H or the PS817-043WQ-C-IPS.

#define EVE_HSIZE (480L)
#define EVE_VSIZE (272L)
#define EVE_VSYNC0 (0L)
#define EVE_VSYNC1 (4L)
#define EVE_VOFFSET (12L)
#define EVE_VCYCLE (292L)
#define EVE_HSYNC0 (0L)
#define EVE_HSYNC1 (4L)
#define EVE_HOFFSET (43L)
#define EVE_HCYCLE (531L)
#define EVE_PCLK (7L)
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)

45
Discussion - EVE / Re: Eve3 built-in fontset
« on: May 08, 2024, 07:56:08 PM »
Ok. fine, I guess I have to check what it actually looks like on the display. :-)
Unfortunately I have no idea so far what I need to display, I only have a very vague project description.
It is even possible that font 34 is not big enough.

Pages: 1 2 [3] 4 5 ... 30