Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[linuxfan]

Hi all.

I have three images in ASTC format ready in the flash memory attached to BT817. Each image starts on a 4k boundary.

If I, stepping through my program, generate a DL with only one of the three images, it works normally.

As soon as I use two or three images, the BT817 gets crazy, messe up the screen with flashes and other anomalies.

I I first copy the three images in RAM_G, of course in appropriate non-overlapping adresses, it works.

My display list is as follow:

        // copy in ram 3 images, and get their address
        handles[1] = resou_bitmapastc("STS 8x752x168.raw", 0);
        handles[2] = resou_bitmapastc("ST 8x752x168.raw", 0);
        handles[3] = resou_bitmapastc("ASS 8x752x168.raw", 0);

   Gpu_CoCmd_Dlstart();
   coCmd(CLEAR_COLOR_RGB(255,255,255));
   coCmd(CLEAR(1, 1, 1));

   coCmd(COLOR_RGB(255,255,255));
   coCmd(BEGIN(BITMAPS));

   coCmd(BITMAP_HANDLE(0));
   Gpu_CoCmd_SetBitmap(handles[1], resou_lastt, resou_lastw, resou_lasth);  // resou_lastX are correct
   coCmd(VERTEX2F(18*16, 53*16));

   coCmd(BITMAP_HANDLE(1));
   Gpu_CoCmd_SetBitmap(handles[2], resou_lastt, resou_lastw, resou_lasth);
   coCmd(VERTEX2F(18*16, 250*16));

   coCmd(BITMAP_HANDLE(2));
   Gpu_CoCmd_SetBitmap(handles[3], resou_lastt, resou_lastw, resou_lasth);
   coCmd(VERTEX2F(18*16, 412*16));
   coCmd(END());

   coCmd(DISPLAY());
   Gpu_CoCmd_Swap();
   Gpu_Hal_WaitCmdfifo_empty();

The above works, because the images are first copied in RAMG. But if I don't copy them, and use

            Gpu_CoCmd_SetBitmap(0x800000 | FLASH_ADDR / 32, .....)

only one image at a time can be displayed correctly. No two or three images together work. I can say this because, running step-by-step my program, I can execute instruction for just one image, and then skip right to the instruction for DISPLAY().

Please note that the three commands "coCmd(BITMAP_HANDLE(X));" were added later: at first I didn't use them, and then added them to see whether they could help (but they didn't).

What am I doing wrong?

Thank you for help and regards.

[BRT Community]

Hi,
Could you advise what sizes your images are, are they all 752x168 (based on filename)?
Is your flash set for fast mode before you try to render direct from flash?

Best Regards, BRT Community

[linuxfan]

> what sizes your images are, are they all 752x168 (based on filename)?
> Is your flash set for fast mode

Thank for your reply.

Yes, images have all the same dimension 752x168 and yes, the flash is in full mode.

In fact, not touching the C program but simply skipping instruction, any single image works correctly, but two or more together do not.

[BRT Community]

Hi,

We can try it out here, could you send us the images (to support.emea@brtchip.com) or if not possible then could you advise the conversion settings when you converted to ASTC in EVE Asset Builder?

It may be that the bandwidth of Flash <-> EVE is too high as EVE reads the image from flash in real time. One thing you could check is to read the REG_UNDERRUN in a lop after you display the images to see if EVE is running out of time (e.g. time to load the images is more than the time allowed which is in turn dictated by the frame rate) 

Best Regards, BRT Community

[linuxfan]

I've sent the images via email as you suggested.

For your comfort, I also post them here. The images are 8x8 ASTC.

The initialization of the display is as follows:

    #define DispWidth      800L          // REG_HSIZE
    #define DispHeight     480L          // REG_VSIZE
    #define DispHCycle     928L         // REG_HCYCLE...
    #define DispHOffset    88L
    #define DispHSync0     0L
    #define DispHSync1     48L
    #define DispVCycle     525L
    #define DispVOffset    32L
    #define DispVSync0     0L
    #define DispVSync1     3L
    #define DispPCLK       2
    #define DispSwizzle    0
    #define DispPCLKPol    1
    #define DispCSpread    0
    #define DispDither     1

The main clock is external, set by writing 0x44000000 during initialization. I am not able to tell what the frame rate is, using the above parameters - I just copied them from an example and they work.

[BRT Community]

Hello,
Thanks, we received your files and will test them out and post an update,
Best Regards, BRT Community

[Rudolph]

The main clock is external, set by writing 0x44000000 during initialization.

That is only partially correct, the host commands are three bytes long and CLKEXT is 0x44 0x00 0x00.
Interesting would be the next command, if it is ACTIVE then the BT817 runs at 60MHz.
If it is CLKSEL followed by 0x46 then the BT817 runs at 72MHz - 0x61 0x46 0x00.

I am not able to tell what the frame rate is, using the above parameters - I just copied them from an example and they work.

It either is 61.58Hz with 60MHz clock or 73.89MHz with 72MHz clock.

What library is this exactly and in what version?
What TFT are you using?

[linuxfan]

> That is only partially correct ... Interesting would be the next command

The next command reads the chip ID from REG_ID register (0x302000): if the content is not 0x7C the whole wakeup sequence (reset, set CLK...) is repeated.

So I assume the chip runs at 60 MHz.

>> I am not able to tell what the frame rate is

> It either is 61.58Hz with 60MHz clock or 73.89MHz with 72MHz clock.

Uhm... how do you calculate that? I thought that I should take the PCLK and divide it first for display width and then for display height (grossly). I obtain a frame rate of about 78 Hz (which is 30MHz divided by 800 then by 480), so I thought I could lower it down to 30 FPS to give more time to the GPU.

Is my reasoning correct? I mean - I should lower the framerate in order to ease the GPU job?

[Rudolph]

> That is only partially correct ... Interesting would be the next command

The next command reads the chip ID from REG_ID register (0x302000): if the content is not 0x7C the whole wakeup sequence (reset, set CLK...) is repeated.

So I assume the chip runs at 60 MHz.

The next command after CLKEXT should be ACTIVE if it is not CLKSEL.
But yes, correct, then this is followed by reading from 0x302000 and it looks like you have the BT817 running at 60MHz.

So one thing to optimize could be to run the BT817 at 72MHz which also increases the clock for the external SPI flash.

>> I am not able to tell what the frame rate is

> It either is 61.58Hz with 60MHz clock or 73.89MHz with 72MHz clock.

Uhm... how do you calculate that? I thought that I should take the PCLK and divide it first for display width and then for display height (grossly). I obtain a frame rate of about 78 Hz (which is 30MHz divided by 800 then by 480), so I thought I could lower it down to 30 FPS to give more time to the GPU.

Is my reasoning correct? I mean - I should lower the framerate in order to ease the GPU job?

Almost, the framerate is pixel-clock / (VCYCLE * HCYCLE).
And lowering the framerate might help, for example by setting PCLK to 4.
As you have a BT817 you also can configure the pixel-clock a bit more directly by using the second PLL.
Also, within limits, the config can be tweaked to use more clocks per line.

But I would rather put as much as possible in RAM_G before displaying directly from FLASH.
The pixel engine really has to do a lot and random access to a serially attached external memory does not help.

[BRT Community]

Hi,

Yes, for small images such as a few tens of KBytes, putting into RAM_G is a good option as they will fit easily and leave plenty of room for other images etc. This avoids delays during accessing and means that you can load more or higher quality level images etc. without being concerned about being at the limits of the flash transfer.

One new feature in the BT817 is the REG_AH_CYCLE_MAX (Please refer to page 50 below) Instead of slowing down the PCLK, this feature extends the line by clocking out more cycles in the non-visible part of the display waveform up to a max which you specify.
https://brtchip.com/wp-content/uploads/2023/12/BT81X-Series-Programming-Guide.pdf
This can be used in some cases to give a similar effect to reducing the PCLK rate.

However, if you can load them from RAM (after copying from flash) then this would be better.

Best Regards, BRT Community

[linuxfan]

Thank you all for the help. I tried to lower the frame rate, and to use REG_AH_HCYCLE_MAX. Both helped in giving more time to the GPU, but failed on a more thorough test.

So I decided to always copy the images in RAM first.

While playing with registers I activated the HSF filter: awesome! Now my 800x480 LCD shows perfectly round circles instead of ellipses. This HSF filter is clever and transparent - good job.

Regards,
linuxfan

[BRT Community]

Hi,

Thanks for letting us know and it's great to hear that it works well.
Yes, the new HSF feature on BT817/8 is great. We are seeing more panels with non-square pixels now and so it makes it easy to use these with BT817/8. Glad you found it helpful,
Best Regards,
BRT Community

   

[jlewis]

Just wanted to add my experience for the record.  I too am getting glitches and "streaks" when I try to load images directly from flash.  Just one image does ok, but it gets worse the more I add.  I haven't tried any of the tweaks mentioned above, except for loading to RAM_G first, which does work. 

Does this mean that loading images directly from flash doesn't really work?  I don't know if I'll need that functionality yet, but I had been thinking about it.

[BRT Community]

Hi,

It is possible to load images direct from flash but there can be limitations. EVE needs to be able to retrieve the image in the time available to display it in real time. Therefore, a large image or one which is of greater quality (e.g. ASTC 4x4) or multiple images may take longer than the time available.

If your images will fit comfortably into RAM_G along with any other items you have there, it is suggested to do that as the access time will be very low from RAM_G and so will avoid the issue.

Best Regards, BRT Community