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]

It's correct, but confusing - I agree =) It has to do with the "chunks" of the framebuffer we transfer to the DSI display for 16 and 24 bits respectively, to avoid tearing. And 448*2=896 also has special significance. If you check the HAL code you'll find that we split the framebuffer into these areas and transfer one at a time until done. (TE and EndOfRefresh interrupt handlers)

You can't represent this intention in CubeMX in a clear way, though 🙂

[scottSD]

@Martin KJELDSEN​  thanks for your quick reply.

That does explain it a bit. I also see that the following function is being called in MX_LTDC_Init():

  HAL_LTDC_SetPitch(&hltdc, 800, 0);

[scottSD]

The reason I ran into this is that I am comparing animation performance between this board and my custom board and trying to figure out why the Discovery board has better performance (with the same TouchGFX project). I was surprised it performs better because it is using DSI and my board is RGB--but it might make sense because with DSI, TouchGFX is Single Buffer strategy and because my display is RGB, I had to set TouchGFX to Double Buffer strategy.

Of course there are many other differences with one BIG one being my board has an STM32H743.

[Martin KJELDSEN]

You do not necessarily need to use double FB with Parallel RGB, but ultimately a good idea if you have the RAM for it and a performance heavy GUI (animations, etc). The H7 does make a difference 🙂

[scottSD]

@Martin KJELDSEN​ 

Just checking, to verify your statement. Would you expect the H7 to have poorer performance than the F769?

I noticed that the F769 Disco board has a 32 bit bus to the SDRAM, but I set it up as 16 bit and than did not reduce it's performance.

FYI, I am using a cacheable container (which you told me about weeks ago) which made a SIGNIFICANT improvement.

[Martin KJELDSEN]

Oh, no the H7 should out perform. I read your statement wrong.

[scottSD]

@Martin KJELDSEN​ I appreciate the feedback--and the clarification. It's day time here, not so in your case 😉

I will start dig into the configuration differences to try to find where my bottle neck is.

[Martin KJELDSEN]

It _is_ getting a bit late 🙂 Maybe tomorrow i can help track this down. Good luck today, though!

/Martin

[scottSD]

A little help would be much appreciated. I am seeing about 2 X the RENDER_TIME of the Discovery kit with the same animation being run on both.

I have looked at the TouchGFXHAL.cpp file and there are many differences between the Stm32F769i-Discovery and my project--which stands to reason because DSI is being used in the Discovery board.

I am wondering if that driver has been optimized for DSI and my driver might be missing some of this optimization? HAL_DSI_EndOfRefreshCallback(), etc.

I will also add that the VSYNC_FREQ GPIO signal is different on this DSI implementation compared to my board--Notice that it is a much wider pulse (is this also caused by the DSI implementation?).

Stm32F769i-Discovery performance

My board's performance

Overall this does not look like it will cause problems. But I am planning on adding more animations per frame, so it has me concerned and would like to have at least as good performance as the F769-discovery kit.

I should also add, that I am purposefully rendering every other frame during this example.