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 ... 28
1
Discussion - EVE / BT82x
« on: October 09, 2024, 05:03:35 PM »
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. :-)

2
Discussion - EVE / inexpensive camera module with LVDS interface?
« on: September 30, 2024, 04:35:25 PM »
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?


3
Ok, no more questions then, the suspense though. :-)

One final remark though, I noticed that the BT822 is using a 38.4MHz crystal on the "Block Diagram" image.
That is an odd value.

4
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.         

5
That is 1Gbit, so 128MB, which is still a lot more.

And in regards of gameduino library, you should check out other options.

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

7
I just saw the image on your Facebook page.
If I am spoilering and that went up only by accident, just don't approve my post. :-)

But wow.
- two channel LVDS TX for displays with up to 1920 x 1200
- two channel LVDS RX for Video *input* up to 1920 x 1200
- "Embedded 1Gbit DDR3L SDRAM" - so 128MB of RAM
- "Advanced EVE with Frame Buffer support for High Resolution HMI"

This sounds like a pretty fundamental change.
First I was thinking that is a lot of memory.
But then I noticed the "Frame Buffer" part.

I am looking forward to learn how much "EVE" is left in "EVE-5".

8
Discussion - EVE / Re: fading screen flicker
« on: September 03, 2024, 05:52:17 PM »
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.

9
Discussion - EVE / Re: EVE3 to EVE4 - Big Font Display Issue
« on: July 31, 2024, 08:50:42 PM »
The EVE_cmd_fontcache() line looks ok.

But, and I am still getting this wrong myself, CMD_SETFONT2 is generating display list commands, so it needs to be put in a display list,
this is not a direct co-processor command, more a nice shortcut to use less SPI traffic.
Like CMD_SETBITMAP.

Just a quick check with EVE Screen Editor:

CMD_SETFONT2(100, 200, 32)

->

Offset
(decimal)   Raw   Text
1   0x0500000a   BITMAP_HANDLE(10)
2   0x01000000   BITMAP_SOURCE(0)
3   0x28000000   BITMAP_LAYOUT_H(0, 0)
4   0x07000000   BITMAP_LAYOUT(ARGB1555, 0, 0)
5   0x29000000   BITMAP_SIZE_H(0, 0)
6   0x08000000   BITMAP_SIZE(NEAREST, BORDER, BORDER, 0, 0)

Ok, well, this is with no .xfont data.

Code: [Select]
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(DL_CLEAR_COLOR_RGB | WHITE);
EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);
EVE_cmd_setfont2(12,MEM_FONT50-0x010000,0x010000);
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);
EVE_execute_cmd();

Can't test this right away as I do not have  the right setup on my desk, but this should work better.

10
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.

11
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.



12
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.

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

14
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?

15
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.

Pages: [1] 2 3 ... 28