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

Author Topic: fading screen flicker  (Read 702 times)

exatech

  • Newbie
  • *
  • Posts: 8
    • View Profile
fading screen flicker
« on: October 05, 2019, 04:54:26 PM »

Hi,
on a 800*480 display, driven by BT815, I made a background image and 20 icons of 100x100 pixels. All images are converted to 8x8 ASTC and reside in flash.

When this screen activates, all images are show up OK, but the screen flickers quite annoyingly. This slowly disappears: after about 15 seconds the screen is stable and I can switch between screens without any flicker.

If I start the display without the icons, but just the background, it shows up almost stable, but activating the icons in the first 15 seconds causes visible fading flicker. Using less compression for the background, and so more data, makes the flicker heavier and longer.

I just cannot grasp what is wrong with it. If the graphic engine is overloaded, how come the flicker disappears? Anyone any ideas?
thx.
Henk
Logged

BRT Community

  • Administrator
  • Full Member
  • *****
  • Posts: 113
    • View Profile
Re: fading screen flicker
« Reply #1 on: October 07, 2019, 03:01:23 PM »

Hello,

Can you let me know what display settings you are using?
Aslo are you using a custom hardware design?

Best Regards,
BRT Community
Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #2 on: October 09, 2019, 10:49:50 PM »

I was intrigued by this.
So I converted 30 icons to 100x100 and put them as ASTC into a flash image.
Code: [Select]
unified.blob                                   : 0     : 4096
88_1_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw  : 4096  : 2752
88_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw    : 6848  : 2752
89_1_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw  : 9600  : 2752
89_2_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw  : 12352 : 2752
...

This is rather small, only 85kB in total.

Then I created a simple test-code included lines like this:
Code: [Select]
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*4))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(0, 10));
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*5))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(105, 10));
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*4))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(210, 10));
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*4))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(315, 10));

I can setup any of the 30 icons to be displayed and I am displaying 28 Icons in total right now plus a small monochrome image from RAM_G.
The display-list size is 1252 bytes, bytes send by SPI are 676, refresh is 20ms.
The display is a PAF90 from Panasys with a BT815 which is clocked 72MHz, the flash is a W25Q128JVSIQ.

Now here is the problem, when I display more than eight *different* icons, it starts to bug out.
The first thing that happens with one additional icon is that the display is not properly build anymore.
It kind of resets after the third row, repeating at the bottom what should be on top.
And make the refresh time longer does not help.
Adding annother icon and the colors in that repeated frame at the bottom gets messed up.
Now I added two more and it flickers like crazy displaying only the first row on the top and a portion of it at the bottom.

Going back to only eight different icons for the 28 icons displayed, everything is fine again.

It looks like there either is a bandwidth issue with the BT815 or the image decoder trips and resets or both.
If necessary I can provide pictures but this should be easily reproduceable.

Edit: I played with the code and took a couple of images.

These all use the same code but while the first (20191013_203941s.jpg) is displayed okay,
the display for the other three is messed up.
The only difference between these images is the amount of different icons to be displayed.
« Last Edit: October 13, 2019, 07:59:20 PM by Rudolph »
Logged

pauljiao

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: fading screen flicker
« Reply #3 on: October 14, 2019, 10:39:58 AM »

I think rendering the image from RAM_G, instead of flash, shall be helpful.
You can use cmd_flashread to copy the ASTC data into RAM_G.
Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #4 on: October 14, 2019, 06:42:24 PM »

Thank you for the suggestion!

So I added "EVE_cmd_flashread(0,0,86784);" to my TFT_init() function.
And yes, at this point the FLASH already is in QSPI mode.

Then I changed my code to:
Code: [Select]
EVE_cmd_setbitmap(4096+(2752*0), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(0, 10));
EVE_cmd_setbitmap(4096+(2752*1), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(105, 10));
EVE_cmd_setbitmap(4096+(2752*2), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(210, 10));
...

And now I can display 28 different icons.
Which also verifies in one image that all of the icons in the FLASH are not corrupted.

I switched back to the original code for the first row.
And as you can see in the second attached image it works with 6 different icons from the SPI FLASH
and 21 different icons from RAM-G.
But when I change it to 7 different icons on the first row it completely bugs out and looks like
"20191013_202605s.jpg" of my previous post.


So I guess it is safe to deduce from this observation that the image decoder is not the source of the problem, at least not on its own.

And this looks like a reasonable workaorund, use highly compressed images from RAM-G that are stored in FLASH.
Only 2752 bytes for ASTC 8x8 with 100x100 instead of 20.000 bytes for ARGB1555 is nice.

Yet, this is not as advertised, if there really is a limit to what EVE can display directly from FLASH this should at the very least be documented with details what these limits are and why they exist.
Logged

pauljiao

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: fading screen flicker
« Reply #5 on: October 16, 2019, 11:32:55 AM »

I tried at my side to display 35 images at one screen (9 images are different, each image is 100x100 in ASTC8x8 format).  All those 9 images
are stored in flash and rendered directly as your code. It has no such issue as you mentioned.

Sharing several tips :   
1).  Use a separate display list to set up bitmap handle:
     
Code: [Select]
      CMD_DLSTART
      BITMAP_HANDLE(x)
      CMD_SETBITMP(...)
      BITMAP_HANDLE(y)
      CMD_SETBITMP(...)
      CMD_DLSWAP
     
2) Draw the bitmap in another display list using the bitmap set up above.
« Last Edit: October 17, 2019, 02:28:13 AM by pauljiao »
Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #6 on: October 16, 2019, 09:37:47 PM »

We can try to workaround it all we want, but what would be the point of this?
That code is perfectly fine.

And on the topic of bitmap-handles, 32 in total really is not enough, even more so when you take into account that one is for scratch and half are setup for the fonts.


I would apreciate if someone from Bridgetek would step in and explain what is wrong.
Logged

pauljiao

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: fading screen flicker
« Reply #7 on: October 17, 2019, 05:08:32 AM »

Tried to display 28 different ASTC8x8 images(each image is 100x100) : 7 from flash and 21 from RAM_G.  Found no issue
at my side, see the picture attached.

The code is as below:

Code: [Select]
CLEAR(1, 1, 1)
CMD_MEMSET(3155324, 0, 4)

CMD_FLASHREAD(0, 23360, 57792)
CMD_TEXT(101, 421, 31, 0, "1-7: Flash      8-28: RAM_G")

The first row 7 images are rendered from flash directly
---------------------------------------------------------------------------------------------------------
CMD_SETBITMAP(0x800000 | 128, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2II(0,0, 0,0)

CMD_SETBITMAP(0x800000 | 214, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2II(104,0, 0,0)

CMD_SETBITMAP(0x800000 | 300, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2II(208,0, 0,0)

CMD_SETBITMAP(0x800000 | 386, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2II(313, 0, 0, 0)

CMD_SETBITMAP(0x800000 | 472, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2II(417, 0, 0, 0)

CMD_SETBITMAP(0x800000 | 558, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(8368, 0)

CMD_SETBITMAP(0x800000 | 644, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(10016, 0)

The following 21 images are rendered from RAM_G , instead from Flash
---------------------------------------------------------------------------------------------------------

CMD_SETBITMAP(0x0, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(16, 1616)

CMD_SETBITMAP(2752, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(1632, 1616)

CMD_SETBITMAP(5504, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(3296, 1600)

CMD_SETBITMAP(8256, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(4976, 1600)

CMD_SETBITMAP(11008, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(6640, 1552)


CMD_SETBITMAP(13760, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(8336, 1584)

CMD_SETBITMAP(16512, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(9968, 1536)
=================================================

CMD_SETBITMAP(19264, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(0, 3248)

CMD_SETBITMAP(22016, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(1632, 3248)

CMD_SETBITMAP(24768, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(3280, 3248)

CMD_SETBITMAP(27520, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(4960, 3248)

CMD_SETBITMAP(30272, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(6640, 3248)

CMD_SETBITMAP(33024, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(8320, 3200)

CMD_SETBITMAP(35776, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(10000, 3200)

=================================================


CMD_SETBITMAP(38528, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(-32, 4864)

CMD_SETBITMAP(41280, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(1600, 4896)

CMD_SETBITMAP(44032, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(3264, 4864)

CMD_SETBITMAP(46784, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(4928, 4912)

CMD_SETBITMAP(49536, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(6592, 4864)

CMD_SETBITMAP(52288, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(8272, 4928)

CMD_SETBITMAP(55040, COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100)
BEGIN(BITMAPS)
VERTEX2F(9984, 4832)


Can you have a test on the flash read speed?  I guess the issue may be related to flash read throughput.

Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #8 on: October 17, 2019, 05:36:47 PM »

>Tried to display 28 different ASTC8x8 images(each image is 100x100) : 7 from flash and 21 from RAM_G.
> Found no issue at my side, see the picture attached.

Okay, what about really different images and all from flash? :-)
I have attached my flash file.

And why all these "BEGIN(BITMAPS)"?
One for a block of bitmaps is enough.
Also there is no END() in your posted code.

>Can you have a test on the flash read speed?

Not directly but I can measure how much time cmd_flashread() takes.
There is not much to gain from this as we have no information about how EVE is actually processing
the display-list and displaying anything.
A SPI trace would be more interesting, but my logic analyzer is way too slow to capture a QSPI which I expect to run at a minimum clock of 36MHz (half of EVEs clock).

An EVE_cmd_flashread(0,0,86784); takes about 4700µs.
An EVE_cmd_flashread(4096,4096,4752); takes about 320µs.
An EVE_cmd_flashread(0,0,256000); takes about 13720µs.
An EVE_cmd_flashread(0,0,384000); takes about 20550µs.

In Bytes/µs this is 18.46, 14.85, 18.66 and  18.69

So there is some overhead from my function which has less influence on the time with more data copied.
So lets say the flash can transfer 18 bytes per µs.
That results in 264µs for 4752 bytes.
And this also is close enough to show that the QSPI runs at 36MHz.

> I guess the issue may be related to flash read throughput.

Yes, maybe.
But then reading chunks of 2752 bytes from the very same flash chip that Bridgetek is using on their boards really should not be an issue.
And it could very well be that EVE is processing the images line by line and reading only the necessary data with every line.

Speculation.

Again, it does not seem to work like it should and I would apreciate a statement from Bridgetek regarding the issue.



Edit:
I just converted the set to 96x96 pixels.
And it has the same issues, directly using the icons from FLASH does only works up to a certain amount of different icons.
I can use 28 different icons from RAM_G without any issue.
And I can display 28 times the same icon from FLASH without issue.

Now I tried something new.

I changed the code to display only two lines of icons from FLASH:

0 1 2 3 4 5 6
0 0 0 0 0 0 0
This works.

0 1 2 3 4 5 6
7 0 0 0 0 0 0
This fails.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Okay. less icons overall (the '-' means the icon is not displayed):

0 1 2 3 4 - -
7 8 9 10 0 - -
This fails.

0 1 2 3 0 - -
7 8 9 10 0 - -
This works.

0 1 2 3 - - 6
7 - 9 - 0 - 0
This works.

0 1 2 3 - - 6
7 - 9 - 10 - 0
This works.

0 1 2 3 - - 6
7 - 9 - 0 - 10
This works.

0 1 2 3 - - 6
7 - 9 - 10 - 10
This fails.

0 1 2 3 - - 6
7 - 9 - 10 - 11
This fails.


Now this is interesting, if this would be an issue with the speed of the FLASH it should work better if there are less icons
on a single row and when there is more space between the icons - this is not the case.

Okay, annother idea, I added
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
lines after each VERTEX2F(), initally one line, then two lines.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Now I added BEGIN/END lines to each row of icons.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Now I added BEGIN/END lines to every single icon.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.


It still looks like something in EVE is broken and it is not getting any clearer what.
« Last Edit: October 19, 2019, 07:10:48 PM by Rudolph »
Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #9 on: November 10, 2019, 05:35:49 PM »

I really am a bit suprised that I can apparently demonstrate that ASTC support is broken and yet get no reaction at all from Bridgetek.
Logged

pauljiao

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: fading screen flicker
« Reply #10 on: November 13, 2019, 08:57:19 AM »

Tested your first failure case on my setup (Riverdi 5 inch 800x480) by using the flash file Rudolph sent.
Quote
0 1 2 3 4 5 6
7 0 0 0 0 0 0

The result is as picture and no failure at all.

Here is my EVE code:
Quote
CLEAR(1, 1, 1)

CMD_SETBITMAP(0x800000 | 128, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
BEGIN(BITMAPS)
VERTEX2II(0,0,0,0)

CMD_SETBITMAP(0x800000 | 214, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX2II(104,0,0,0)

CMD_SETBITMAP(0x800000 | 300, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX2II(208,0,0,0)


CMD_SETBITMAP(0x800000 | 386, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX2II(312,0,0,0)


CMD_SETBITMAP(0x800000 | 472, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX2II(416,0,0,0)

CMD_SETBITMAP(0x800000 | 558, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX_FORMAT(0)
VERTEX2F(520,0)


CMD_SETBITMAP(0x800000 | 644, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX_FORMAT(0)
VERTEX2F(624,0)

CMD_SETBITMAP(0x800000 | 730, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX_FORMAT(0)
VERTEX2F(0,104)

CMD_SETBITMAP(0x800000 | 128, COMPRESSED_RGBA_ASTC_8x8_KHR, 104, 104)
VERTEX2F(104,104)
VERTEX2F(208,104)
VERTEX2F(312,104)
VERTEX2F(416,104)
VERTEX2F(520,104)
VERTEX2F(624,104)

Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #11 on: November 14, 2019, 09:45:11 PM »

Interesting, what about using more different pictures?

And you changed the code, you used VERTEX2II() as well.
I tried this as well and it still does not work with

Code: [Select]
0 1 2 3 4 5 6
7 0 0 0 0 0 0

This works:

Code: [Select]
0 1 2 3 4 5 6
0 0 0 0 0 0 0

And more interestingly this works as well:

Code: [Select]
0 1 2 3 0 0 0
4 5 6 7 0 0 0

So I tried to leave out the last two images in the row for which I use VERTEX2F().

This works:

Code: [Select]
0 1 2 3 0
4 5 6 7 0

Code: [Select]
0 1 2 3 4
5 0 9 0 0

This fails:
Code: [Select]
0 1 2 3 0
4 5 6 7 8

Code: [Select]
0 1 2 3 4
5 6 9 0 0


Okay, it looks like I really have to get annother display.
The one I have from Riverdi unfortunately is only the 4.3" version.
And my EVE3-50G for some unknown reason died a while back, just stopped working for no apparent reason.

Well, annother EVE3-50G it is then.

Edit: I maybe need to clarify this a little, I really have no idea why it stopped working, I had it on my desk, connected to my target board and it worked, I uploaded a new software to my board like I did a couple of times this evening, and the BT815 did not respond anymore and the panel stayed black.
There was no magic smoke involved and there was no visual clue on the board that something failed.
Since it was send to me from Digikey on the other side of the globe it did not even occur to me to send it back.
Instead I decided to try to fix it myself by replacing the BT815Q.
Well, that did not work out either but I learned that I am not ready yet to solder VQFN-64 packages. :-)
Whatever, I would not have bought just annother one from probably even the same batch if I were suspicous that there is anything wong with the EVE3-50G.
« Last Edit: November 19, 2019, 07:27:40 PM by Rudolph »
Logged

Rudolph

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
Re: fading screen flicker
« Reply #12 on: November 18, 2019, 07:47:21 PM »

Okay, I received a new EVE3-50G today and have it up and running.

The good news is, I have no problem at all displaying the full set of 28 different icons directly from flash
with this display.

The bad news is, I still have no idea why it fails on the other display with the same resolution using the same code with an identical micro-controller and using the same pins.

With the EVE3-50G I can attach a USB adapter and flash from EVE Asset builder.
This works fine.
And erasing the flash and re-writing it from my Controller like I had to with the other displays also works fine.

There is a W25Q128JVSIQ FLASH on the display that fails and a 25Q32JVSIQ on the EVE3-50G.
The BT815 on the display that fails is labeled: K1COK BT815Q 1905-A
The BT815 on the EVE3-50G is labeled: K61TL.03 BT815Q 1842-A

And just for reference, I bought a chip from DigiKey that also is labeled like the on the EVE3-50G.
And the one on the RVT43 I have from Riverdi is labeled: K61TL.13 BT815Q 1802-A

So the "wafer lot number" looks different on the BT815Q from the display that fails but it still is
a revision "A" chip so it should just behave like the one on the EVE3-50G.

Whatever the heck is going on there?
Logged