Print

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

[david]

I have problems with flickering displays, when I try to render fonts with larger sizes (f.e. 32 or 40).
It does not happen if I render just a few characters. It begins at about 6 lines with around 15 letters on each line.
I tried converting the font with EVE Asset Builder with ASTC 8x8 and also tried it with the maximum 12x12.
The total size of the glyph for the font size 40 is 2.2 MB so loading it into RAM is not an option.
I don't have problems with smaller font sizes (tried size 22).
Are there know limitations about the ASTC rendering from flash? In the programming guide I saw the section "Performance" which describes the time needed for specific formats, but I think those are not for ASTC on flash.
For me it looks like the time for reading the data from flash takes to long, but some information about that would be helpful.

Flash: W25Q128JV
BT: BT815
Display: 640x480 with NV3052C display controller
BT clock: 72 MHz
REG_PCLK: tried 3, 2, 1 (flickering gets a bit better with higher display clock)
REG_CSPREAD: 0
Font: Noto Sans (https://www.google.com/get/noto/)
Font size: 40

I found this old thread, which might be a related issue but it was not solved and it was about showing images from flash instead of custom fonts: http://www.brtcommunity.com/index.php?topic=78.msg379#msg379

I can provide photos or code/font files if needed. But I think it is very easy to reproduce that, it happened on the EVE 3 with 7 inch display for me before I just ignored it by showing less text. Just show some more lines of text with a font size 40.

[BRT Community]

Hello,

Thank you for your question.

I've tried to reproduce this behaviour, however I unfortunately do not have a 640x480 display to hand to test with, but I was able to reproduce this with a 800*480 display.

In general there is a finite bandwidth of the QSPI link from the BT81x to the Flash chip. When you render an image/font direct from flash, the data must be retrieved over QSPI within a certain time (related to the scan time for the row on the display) and if this retrieval takes too long then the line will be corrupted and you can see artefacts. We normally refer to this as underrun in EVE. This is likely the cause of the flickering you are seeing on the display.

This occurrence becomes more likely to happen if you have more data to retrieve for a given line on the display (note: only when you are utilising multiple lines of text).
This may be because of higher resolution or having more of the images/fonts on the same rows of the screen.
 
On BT815/6 we added a feature called adaptive frame rate which varies the PCLK and so can provide a longer time for scanning out a line by slowing it down and so gives us longer to retrieve the data and create the graphics. This requires that the LCD is compatible with this variation of PCLK and is for RGB displays. 
One BT817/8 there is also a new mode adaptive hsync which allows the device to increase the hcycle up to a specified value to give more time to render the line.
 
Therefore, our suggestions would be to overcome such a scenario would be:
1.       Turn on the adaptive frame rate if LCD supports it (BT815 and BT817)
2.       Turn on the adaptive HSync feature (BT817)
3.       Copy the image to RAM_G and render the ASTC image from RAM_G instead

I note that the .glyph size is too large to be copied into RAM_G and you are using the BT815 on this occasion, but does your LCD panel support AFR? If so can you give this a try?

Could you also ensure that the flash IC is in the FULL state, and not in the BASIC state as this may also be causing performance issues.

Best Regards,
BRT Community

[david]

Thanks a lot for clarifying. The display does not support adaptive frame rate. I will try to work around this issue by splitting up the text more (bigger margins between then lines). This worked in my first tests.
I ensured that the flash is in full state, by checking REG_FLASH_STATUS. If I put it in basic state I cannot even see any directly rendered ASTC images from flash. So this one is done correctly.
I will also order a BT817 for testing you mentioned adaptive HSync feature.

Best Regards,
David

[Rudolph]

Annother interesting feature in this regard that the BT817/BT818 have is the fontcache.
While this takes away RAM_G it does not eat up as much of it as putting the whole font into RAM_G since one normally does not use every glyph from a font and then the .glyph file is rather inefficient in terms of storage space.