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: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash  (Read 8269 times)

Craggan

  • Newbie
  • *
  • Posts: 11
    • View Profile
Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« on: September 26, 2022, 04:02:29 PM »

Hi there,

i'm testing a MicroChip PIC32 EV-board connected to a new Riverdi 7" 1024x600 EVE4 BT817 display.
I'm using the EVE library from Rudolph.

So far everything is OK and all works fine.

To test out the limits i wrote a small test routine which writes zigzag lines in blocks of 250 single lines.

The BT817Q spec says display list size is 8k, but i crash after the 4k border:


void test_8k(void) {
   
   uint16_t  i;

   EVE_cmd_dl( CMD_DLSTART );               
   EVE_cmd_dl( CLEAR( 1, 1, 1 ) );
   
num_dl_static = EVE_memRead16(REG_CMD_DL);         // read current position

   EVE_color_rgb( WHITE );                         // sets the foreground color   
   EVE_cmd_dl( LINE_WIDTH( 1 * 16 ) );
   
  // *** draw zigzag 1
 
  EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );

   for( i = 0 ; i < 250 ; i++ ) {
      
      if( i % 2 )
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  66*16 -50 *16 ) );
      else
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  66*16 +50 *16 ) );

     
// to go sure
    if( i % 50 )
       EVE_execute_cmd();      
   }


num_dl_static = EVE_memRead16(REG_CMD_DL);         // read current position
      
  // *** draw zigzag 2
 
  EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );
   
   for( i = 0 ; i < 250 ; i++ ) {
      
      if( i % 2 )
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  196*16 -50 *16 ) );
      else
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  196*16 +50 *16 ) );
      
// to go sure
    if( i % 50 )
      EVE_execute_cmd();      
   }
   
num_dl_static = EVE_memRead16(REG_CMD_DL);         // read current position

  // *** draw zigzag 3
 
  EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );
   
   for( i = 0 ; i < 250 ; i++ ) {
      
      if( i % 2 )
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  326*16 -50 *16 ) );
      else
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  326*16 +50 *16 ) );
      
// to go sure
    if( i % 50 )
      EVE_execute_cmd();      
   }

num_dl_static = EVE_memRead16(REG_CMD_DL);         // read current position

  // *** draw zigzag 4
 
  EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );
   
//   for( i = 0 ; i < 250 ; i++ ) {   // CRASHES !
   for( i = 0 ; i < 230 ; i++ ) {   // OK
      
      if( i % 2 )
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  456*16 -50 *16 ) );
      else
      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  456*16 +50 *16 ) );
      
// to go sure
    if( i % 50 )
      EVE_execute_cmd();      
   }

  // *** draw zigzag 5
 
//  EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );
//   
////   for( i = 0 ; i < 250 ; i++ ) {   // CRASHES !
//   for( i = 0 ; i < 230 ; i++ ) {
//      
//      if( i % 2 )
//      EVE_cmd_dl( VERTEX2F( 1600 + i*40,  586*16 -50 *16 ) );//
//      else
//        EVE_cmd_dl( VERTEX2F( 1600 + i*40,  586*16 +50 *16 ) );
//      
//    if( i % 50 )
//      EVE_execute_cmd();      
//   }

num_dl_static = EVE_memRead16(REG_CMD_DL);   

   EVE_cmd_dl( END() );
  EVE_cmd_dl( DL_DISPLAY );   
  EVE_cmd_dl( CMD_SWAP );     
  EVE_execute_cmd();
}



One picture shows the forth block with 230 lines, the second one with 250 line, which crashes.

"num_dl_static" shows the size of the display list to me in the debugger.

What am i doing i wrong ?

Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #1 on: September 27, 2022, 07:06:13 PM »

>i'm testing a MicroChip PIC32 EV-board

I would be interested in the target code for this one since I do not have any code for PICs so far.
Never found these attractive, I do not like MPLAB-X at all and Platformio "only" supports the Arduino framework for PIC32.


I just tried this with an EVE3-50G connected to an ESP32-S3 as I had this already connected.
And I pushed it to 5x 365 Line-Strip Segments filling the display-list with 8176 bytes with the attached souce,
this is for everything, the whole display-list.

I modified my basic demo for this:
Code: [Select]
EVE_color_rgb(RED);
EVE_cmd_dl( BEGIN(EVE_LINE_STRIP) );
for(uint16_t i = 0 ; i < 365 ; i++ )
{
    if( i % 2 )
    {
        EVE_cmd_dl(VERTEX2F( i, LAYOUT_Y1));
    }
    else
    {
        EVE_cmd_dl(VERTEX2F( i, LAYOUT_Y1 + 50));
    }
}

EVE_cmd_dl(DL_END);

Now there are a few things to mention.
Usually I am using DMA which limits the amount of bytes that can be send to 4k as the FIFO "only" is 4k.
This is not really an issue since under normal conditions as the display-list is composed by the co-processor with commands like CMD_BUTTON, CMD_TEXT or CMD_NUMBER which need more bytes in the display-list than in the FIFO.
Try this in EVE Screen Editor, add 19 buttons for example and RAM_DL shows around 50%, depending on where the buttons are placed (less with coordinates below 511).
But this is not under normal conditions and you are not using DMA so I switched if off as well for the 5x 365.


With DMA on I just pushed it to 190 per color which resulted in 4076 bytes for the FIFO and 4688 bytes for the display-list.
Using two or more segments to push more than the 4k out by DMA to the FIFO is possible, but beyond the scope right now.

Next thing is that you might be missing an EVE_cmd_dl(DL_END); line.

The EVE_execute_cmd(); lines in between the segments in your version are not doing anything in this context.
All this does is to wait for the FIFO to be empty but since every command is executed on it's own with a separate chip-select cycle and VERTEX2F is just copied over from the FIFO to the display-list by the co-processor, the FIFO is always empty anyways.

And at last this is awfully slow.
The time in the image is wrong, I limited the digits to 4 and num_profile_a was "only" 16 bits.
I consider over 2ms to be not viable for my applications.
With 32 bits and 6 digits I get 118680µs now (ouch), this is for the whole TFT_display() function.
This is mostly for the transfer without DMA (adds 3 bytes overhead) at 10MHz using the ESP32-S3.

And a smaller part is from calculating VERTEX2F since X is at bit 15...29.

Segments of 190 without DMA: 63510µs
Segments of 190 with DMA: 348µs and the SPI transfer itself needs 2069µs.
No segments with DMA: 44µs
So calculating 950 VERTEX2F needs about 300µs - and that is on a 32 bit controller clocked 240MHz.

This still does not answer why it crashes for you and I still need to test this with a BT817.
I am fairly certain though this is neither on my side or the fault of the BT817.
Logged

Craggan

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #2 on: September 28, 2022, 09:10:11 AM »

Can anybody confirm this behaviour?
I fear i stumbled over a bug.
4k is the limit of the coprocessor FIFO and not the display list.
If yes, i can stop the annoying search.
Maybe i am wrong or i oversee something?
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #3 on: September 28, 2022, 06:54:30 PM »

I feel I wasn't clear enough on this, this is not an issue with the FIFO as the 4k limit on the FIFO only applies when sending data in a single transfer.

I am testing this with the RVT70H now, so 1024x600 EVE4 BT817.
My board is using an ATSAME51J19A with 120MHz, SPI clock is 15MHz.

And I am afraid that this is a limitation on the BT817 in combination with the long lines.
Just switching over from the EVE3-50G which has 800x480 and a BT815 I need to reduce
the amount of lines even for the variant with DMA enabled.
190 + 190 + 190 + 190 + 150 = 910 segments is fine
With three output lines more to display the frequency, frames/s and REG_UNDERRUN the total amount for the DMA transfer is 4010 bytes and the resulting display-list is 4912 bytes.

When I increase the last segment to 160 it flickers and the value for REG_UNDERRUN starts to go up.
Setting the last segment to 170 results in 4092 for the DMA transfer and 4992 for the display-list,
this should be fine but really is not.
When I increase it beyond 160 (and above 170 without DMA) things really get weird, this effect looks to me like the render-engine is crashing and restarting, I have seen this before when reading too many images on the fly from the external flash.

The frames are a solid 60/s, there is no drop.

Using EVE_memWrite8(REG_PCLK_2X, 1); does not help at all, looks like the display-list is just too complex.

Using EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500); helps a lot, still 60 frames/s but no flickering anymore.
My value for EVE_HCYCLE is 1344.
With DMA off I can set the last segment to 310, no problem, the display-list is 5528 bytes.
Further increasing the REG_AH_HCYCLE_MAX does not help anymore.

Now I wonder if I should just add EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500); as default for BT817/BT818, it does not eliminate the issue but it certainly pushes what is possible.
For the test I put it just after EVE_init().

I can't push it to 1825 segments like with the BT815 and 800x480 but 1070 segments still is a lot and at least a little higher than 920.

Maybe it is worth looking into making the time per line longer.


The 7882 µs in the screenshot is accurate, the ATSAME51 is a lot faster with single SPI transfers than the ESP32.
« Last Edit: September 29, 2022, 04:28:40 PM by Rudolph »
Logged

Craggan

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #4 on: September 29, 2022, 01:10:42 PM »

Hello Rudolph,

thanks a lot for your answer.

My second post was done before i read your first one. So they interfered.


I did some try and error.
i replaced STRIPLINE through POINTS and also LINES.

It seems the work. First i thought it's maybe a precision problem and i also changed to:

Code: [Select]
EVE_cmd_dl(VERTEX_FORMAT(0));
as you did.

Then a tried POINTS and as they worked i tried LINES.

So i assume at the moment it has maybe to do with the STRIPLINE calling parameters( size and position )



Meanwhile i read your second post.

My value for EVE_HCYCLE is also 1344.

This made it much better:

Code: [Select]
EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);
Also i don't understand what it does?
« Last Edit: September 29, 2022, 03:32:08 PM by Craggan »
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #5 on: September 29, 2022, 05:45:57 PM »

Quote
i replaced STRIPLINE through POINTS and also LINES.

Well, both require less computations in EVEs graphics backend,
i can totally see that making a difference.

I merely changed the precision to remove the multiplications on the controller side.

Quote
My value for EVE_HCYCLE is also 1344.

This made it much better:
Code: EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);

Also i don't understand what it does?

This allows EVE to extend lines by additional clock cycles and there gives it more time to compute the display-list.


Here is something weird though.
I calculated the time per line in µs based on HCYCLE and the pixel clock.
EVE3_43G: 53.278 µs
EVE3_50G: 25.778 µs
RVT50H: 34 µs
RVT70H: 26.353 µs
RVT101H: 20.282 µs

So actually the BT817 on the RVT70H with 1024x600 has more time per line than the EVE3_50G.
I am using the EVE3_50G with 36 MHz pixel-clock due to limited options to setup the pixel-clock with the FT81x and BT815/BT816, the value for HCYCLE is 928.
On the RVT70H the line is much longer with 1344 and I am using a pxiel clock of 51 MHz.

The time per visible pixel is lower for the RVT70H though - if that even is a valid concern.


I ordered a RVT50HQBNWC00-B as I do not have a BT817 with 800x480 so far.
And I will test what happens when I lower the frame-rate by reducing the pixel-clock.


Edit: I played with it some more.
Now I am using two DMA transfers to reduce the time for the actual transfer, just to make sure
everything is within my intended timing of 50 changes per second.

And I was wrong before, 190+190+190+190+150 is not the limit.
I have it currently running with 6 x 255 Segments, the size of the display-list is 7400 bytes.
The frames per second actually dropped from 60 to 57/58 - which is to be expected when EVE is allowed to lengthen the lines to compensate for more complex lines.

The complexity per line is key.
When I change the last block to overlapped with these before -> tilt.








« Last Edit: October 02, 2022, 09:41:03 PM by Rudolph »
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #6 on: October 09, 2022, 09:27:56 PM »

To wrap this up, I tested this with the RVT50HQBNWC00-B now as well.
And the display list itself really is not the limiting factor.
I currently have it running with 6 LINE_STRIP blocks of 265 segments each.
Plus another block of 170 segments.

The list gets transmitted in two blocks via DMA of 7432 bytes combined and the resulting display list
is 7948 bytes long.


The limiting factor really is not that the display-list can not be bigger than 4 kiB,
but the complexity of the display list per line and how much time EVE has to throw out pixels per line.
Much like the bandwidth of the external flash is a limiting factor so displaying images directly from flash should be used sparingly if not avoided alltogether.
And using fonts from flash is actually displaying images as well, at least we have CMD_FONTCACHE to help with that (but only for a single font).

So we need to put things in RAM_G, especially at resolutions of 800x480 or beyond.
And we have ASTC to help with that, using ASTC 8x8 with only 2 bits per pixel brings down full color images with alpha channel to 1/8 of ARGB1555.

Then EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500); gives EVE more flexibility with the timing.

And the last measure would be to reduce pixel-clock and therefore the framerate.
Logged

Craggan

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #7 on: October 12, 2022, 01:58:31 PM »

Hi Rudolph,

thanks a lot to you to work this out.

but the complexity of the display list per line and how much time EVE has to throw out pixels per line.

I think normally this should be mentioned within the specification.
This cost me a lot of time.

By the way, you name sounds to be from Southern Germany. Are you?



Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: Testing Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash
« Reply #8 on: October 13, 2022, 05:07:00 PM »

Quote
but the complexity of the display list per line and how much time EVE has to throw out pixels per line.

I think normally this should be mentioned within the specification.
This cost me a lot of time.

I am afraid there is no easy answer to this one and a "you may or may not run into timing issues if you compose a very difficult line and your time per line is less than 30µs" would probably help no-one, even if it would be accurate.

Quote
By the way, you name sounds to be from Southern Germany. Are you?

Rudolph is my first name, like the Reindeer. :-)
I am aware though that Rudolph is found as a family name in southern Germany since I am from northern Germany.
Logged