Is it safe not do change the touchgfx screen, switch QSPI from and back to memory mapped mode, and only change the screen afterwards? Does Touchgfx access the QSPI only if the screen is switched or does it also access the QSPI if e.g. only a timer value is modified on the screen?
In some cases my application running on an STM32F4 with RTOS needs to store huge amount of data into the QSPI flash, which could take more than one minute. Currently, I display a message that it will take up to a few minutes and suspend the touchgfx thread until the data is written and the flash is switched back to memory mapped mode. During this time, the clock which is displayed on the screen is not updated and of course the screen is frozen. I want to give some feedback to the user during storage operation. One possibility would be to store the data in smaller chunks and therefore suspend and continue the touchgfx many times. The solution I ask here is not to suspend the touchgfx thread but avoid operations which could cause touchgfx to access the QSPI during that time.
Hello @awiernie ,
TouchGFX will access font and text data when the clock changes. If these are stored in QSPI flash, this will not work. A possible solution is to make sure that the specific font and texts used for the clock are in internal flash. This is only a few characters, so no big issue.
Another solution is to use a BoxProgres widget from the Progress Indicators. It does not use any data from the flash. Then remove clock meanwhile. TouchGFX accesses the flash when something on the screen is updated, not only on screen change.
I hope this helps you, don't hesitate to ask more questions
Perhaps there is the ability to partition the data so some lives in internal, and others in external.
Provide for some indirect access methods, ie QSPI_memcpy() type thing, which gates and arbitrates access, perhaps interleaving with the Page Write operations when a resource is needed. Or caches objects in RAM