Is the Application Template for the Stm32F69i-Discovery correct?

[scottSD]

I recently tried the Application Template for the Stm32F769i-Discovery board and noticed that the horizontal sizes in the CubeMX file are 448 instead of 800:

This appears to be incorrect.

[Martin KJELDSEN]

Just taking a quick look at the clock tree it looks correct for H743. It's running 400Mhz on the core clock. How are you testing? Can you try with images in internal flash just to rule out a QSPI bottle neck?

[scottSD]

Actually running 480MHz on the core clock. Running FMC and QUADSPI at 133MHz.

I am placing all images and text areas behind the animated shape into a cacheable container, so would moving images to internal flash a difference?

Based on your suggestion, I did move the background images into internal flash and it made a slight improvement, but sure why if they are part of a cacheable container.....

I am caching my cacheable container into dynamic bitmap cache.

Below is my cacheable container code:

CacheableContainer containerBackground;
BitmapId bmpIdBackground;
 
bmpIdBackground= Bitmap::dynamicBitmapCreate(800, 480, Bitmap::RGB565);
if(bmpIdBackground!= BITMAP_INVALID)
{
    containerBackground.setCacheBitmap(bmpIdBackground);
}

Below is my dynamic bitmap cache in touchgfx_init() (in the file TouchGFXConfiguraiton.cpp):

#define DYN_BMP_W   800
#define DYN_BMP_H   480
#define DYN_BMP_CUSHION 200
 
#define DYN_NUM_BMPS  1
#define DYN_USE_BPP   16
 
#define DYN_BMP_CACHE_SIZE DYN_BMP_W * DYN_BMP_H * (DYN_USE_BPP/8) * DYN_NUM_BMPS + (DYN_BMP_CUSHION * DYN_NUM_BMPS)
 
uint8_t *bmpCache = (uint8_t*)0xc0177000;
 
void touchgfx_init()
{
  Bitmap::registerBitmapDatabase(BitmapDatabase::getInstance(),
                                BitmapDatabase::getInstanceSize(),
                                (uint16_t*)bmpCache,
                                DYN_BMP_CACHE_SIZE,
                                DYN_NUM_BMPS);

[Martin KJELDSEN]

Data still has to be read from QSPI even when using a cacheable container. Cacheable Container only really gives you a benefit if you have something computationally heavy (like canvas widgets, texturemapper) that you need to move around.

The reason i wanted you to move the images was to rule out a poor QSPI configuration - Doesn't seem to be the case. The very small improvement is expected.

[scottSD]

I am using the cacheable container behind a shape widget (similar to the Gauge class in one of the ST examples). I am placing a few images and textAreas in that container. If I don't cache the container, I see a drastic reduction in performance, so it is indeed helping. You pointed this out to me a while back and I am using it.

[Martin KJELDSEN]

Okay, great! Sounds like we should have an optimal setup. Can you verify that DMA2D is being used to make this transfer? Since you say drastic, i'm assuming it is.

I suggest you try toggling some more GPIOs around certain points of interest to find out where time is spent.

[scottSD]

Great suggestion. ChromART (DMA2D) is selected inside the TouchGFX Generator.

One question about the DMA2D configuration. I am setting the color modes to ARGB8888. Is this correct for TouchGFX even though I have its Framebuffer Pixel Format set for RGB565?

[Martin KJELDSEN]

The DMA2D settings don't matter, actually. The TouchGFX DMA2D class will know which formats the application is using (input, output) and configure each transfer accordingly.

[scottSD]

I will verify the DMA2D is working.

Also, I should note that I am using a circle widget with a bitmap painter (placed in a cacheable container). The bitmap is in QUADSPI.

When my shape animates over this circle widget i do take a performance hit, as you indicated.

[scottSD]

@Martin KJELDSEN​ 

According to CacheableContainer's comment header for setCacheBitmap, it looks to me as if items inside the container are placed in a dynamic bitmap, so I am surprised you say this doesn't pertain to images in QUADSPI:

    /**
     * @fn void CacheableContainer::setCacheBitmap(BitmapId bitmapId);
     *
     * @brief Set the dynamic bitmap into which the container content will be rendered.
     *
     *        Set the dynamic bitmap into which the container content will be rendered.
     *
     * @param bitmapId Id of the dynamic bitmap to serve as a render target.
     */
    void setCacheBitmap(BitmapId bitmapId);

But I found what was causing my major issue. It improves my performance when I actually ENABLE it:

      containerBackground.setCacheBitmap(bmpIdGaugeBackground);
      containerBackground.enableCachedMode(true);
      containerBackground.updateCache();

I had forgotten to do this. I had done it in an earlier project but missed it in my latest project (insert banging head on wall smiley here.....).

A couple of things that would be very useful is that when the Cacheable option is checked in the Designer, it would call enableCachedMode() within the generated gui base screen code. I have a feeling other people think that when this option is clicked, the container is actually cached. It appears that it is not until enableCacheMode() is called. People need to know that updateCache() needs to be called also.

Of course, if one doesn't setup a dynamic bitmap cache, it wouldn't be cached anyway. I suggested in another thread that you add the setting up of dynamic bitmap cache in the TouchGFX Generator because it needs to be done when calling registerBitmapDatabase() which is in a generated file and is overwritten by a CubeMX.

That thread:

https://community.st.com/s/question/0D53W000004k3sdSAA/is-there-a-way-to-add-user-code-areas-to-touchgfx-generator-files-so-user-code-is-not-over-written-by-a-cubemx-generation

Even so, it does not answer why my performance was worse in they H7 compared to the F769-Disco when caching was disabled in both. However, now when I have the cacheableContainer enabled in both, the H7 does slightly out-perform it.

[scottSD]

Below is ST's article explaining the Cacheable Container for anyone who may run into this:

https://support.touchgfx.com/docs/development/ui-development/scenarios/achieving-better-performance-with-cacheable-container/