Print

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

[mrclnz]

We are thinking to evaluate the BT816 for use with an 800x480 TFT panel. However calculations show issues with the required memory bandwidth for ATSC compressed images. Please correct me if some of the assumptions are wrong.

The FTDI is clocked at 72 MHz. Nominal dot clock for the panel is 40 MHz, maximum 50 MHz, so using the PCLK divider we run at 36MHz. From timing specs the horizontal raster time is 862-1200 dots (1056 nominal), giving 2112…2400 master clocks to build a scanline using the display list.

Now, from the datasheet and the ATSC 2×2 tile organization it is strongly inferred that the texture line cache size is 64 bytes: 2×2 ATSC blocks are 64 bytes, every address in flash must be multiple of 64 bytes and so on.

The fastest way to access the SPI flash is in quad SPI XIP mode, which is what the firmware blob I assume does… in this mode from the chip select the memory needs: 6 cycles for the address, 2 for the mode/address extension, 4 dummy cycles for access latency and then it outputs the data. So for a 64 byte transfer you need 44 master clocks.

Since a scanline runs for 2112…2400 clock you can only have 48-50 tile transfers in a line (for a 2×2 ATSC block tile). At the minimum compression level (4×4 texels for block) a tile represents 8×8 texels, so to hypotetically fill a full size background image (800 pixels) you would need 100 tiles and that doesn't fit the timings.

This is of course a bit extreme (since it's kind of a worse case, we could use bigger blocks and so on) but if there are many bitmaps (i.e. many characters) on the scanline, the texture unit/rasterize can definitely starve. What happen in this case? The condition is not described in neither the datasheet nor in the programming manual.

- The bitmap is not drawn? (like the old game console with something like max 5 sprites for scanline)
- The display list stalls? like when the display list is too long and there is no time to render all the pixels
- Something else?

On a smaller 480×272 panels there is a lot more time (because there are a) less pixels and b) dot clock is usually about 8MHz) so probably it isn't a concern, and I will try to lower the dot clock to see if it's feasible; this panel is currently running on the FT810 without issues however it seems to be quite sensible to the clock (for example it hangs if I try to do a snapshot) so I'd like to know what would actually happen if the scanline timing are exceeded due to memory accesses.

Thanks in advance
Regards

[BRT Community]

Hello,

Your analysis is quite accurate but there is an additional cache and other factors too which help. The BT815/6 is therefore able to render a 800x480 background in ASTC4x4 from flash.

In general, if there are too many items to process, you may see the contents of the busy lines being corrupted. The latest versions of EVE, the BT817/8, have even more enhanced features to give more time in the horizontal timing to allow for more complex lines as well as other performance improvements and so will be even better in this regard,

Best Regards,
BRT Community

[Rudolph]

As far as I know the QSPI clock of the external flash is not coupled to the pixel clock and runs at full speed.

I did quite some tests with three different modules from three manufactures and while i am still waiting on feedback what is going on there I can at least partly report what I found since this can be easily tested by anyone.

There are couple factors at play, one is definately the image size. If you use smaller images it runs smoother.
The other is the order in which the images are acessed, with random accesses is is more likely to run into an issue
than with linear access.
Use a bunch of 80x80 images in linear order and everything is fine.
Use the same images in random order and you may have an issue.
Use smaller images like 64x64 in totally random order and you may not have an issue.

Use a different module with the same chip but a completely different PCB you can have an issue with the exact same code that is running fine on the first module.

Now what happens is this, the first stage with the BT815 is that the framerate drops a little as per default it tries to compensate by making the lines a little longer.
I only noticed it when I measured the frames per second with REG_FRAMES.

The next stage however is that the pixel engine crashes and restarts, or at least this is my guess what happens.
When you try to display a bunch of pictures for example at Y=100, you get a little pixel salad and then the first 100 lines are displayed again, only not with the right colors, then it crashes again when reaching what should be line 200, displays the first 100 lines correctly and so forth.

And while the second stage already is something you want to avoid, it is also possible to go beyond that and end up with not even fragments of what should be displayed.

So if anyone encounters something like this, either try to use smaller images or check how much RAM_G you have left and copy the images there. ASTC images work just as fine from RAM_G.

That said, I did not get any reports for my code-library regarding this so far and I also did not run into this with the application code I did for my projects, i only found this while testing.