In an OS free environment, with software running on an H7, one would call MX_TouchGFX_Process() indefinitely in the main so that TouchGFX will do its thing, render the graphics and pop them on the display, all synchronized by the VSYNC interrupt generated by the LTDC. If I understand correctly, that means in a typical 60fps display, MX_TouchGFX_Process() will return immediately most of the time except every 16.66ms where we need the next frame to be rendered. Render time is about 5ms when the frame does not need any update and 25 ms when text and such need to be updated.
How does one integrates this in a real-time environment where several tasks need to be run every 1ms, based of a simple timer? My understanding is that every 16.66ms, MX_TouchGFX_Process will be running for up to 25ms and nothing else will be happening during that time, which is not acceptable.
If I run my code and put a scope on a digital output that measures how long MX_TouchGFX_Process takes (ie the render time) and also pulse another output in a 1ms timer, I do not see either tasks being interrupted. How is that even possible? What happens when the timer interrupt fires but MX_TouchGFX_Process is in the process of rendering a frame? Is MX_TouchGFX_Process interrupted and the frame lost (i don't see the render time shorten)? Is it interrupted and resumed (I don't see any mechanism for that)?
What would be the best practice -aside from using a dual core STM32- to have a steady real-time 1ms loop while running the TouchGFX graphic engine. Is that even possible if TouchGFX does not have a suspend-resume process available?
Thank you
