As those suggested state machines will need to be duplicated or extended for each of the existing screens (again, legacy software migration), this is a solution that would require completely restructuring the existing codebase. That is one of the things on my todo list, however, it will not be done to work around the EVE chip's swap behavior.
In the end, this will likely move to a co-processor command buffer managed on the MCU, using DMA to feed the FIFO. Using the self-modifying command stream I mentioned in another thread, this can at least be built in MCU RAM without waiting on completion by the co-processor, or guessing at the resulting display list snippet sizes.
As stated earlier, my concern is not delays in updating the display, it's managing the SPI communication time. The transfer times are fine as they are, up until the FIFO overflows due to RAM_DL contention.
The other ways I see this issue being managed are:
- Moving screen initialization logic into each screen's event loop, waiting for the last swap request to be completed before initializing the new screen. This would allow the automation logic to still execute if the FIFO was at risk of overrun, and is a much more conservative change to the existing code.
- Build the entire screen-initialization command list in RAM_G, and feed the FIFO from there. This would have the advantage of shifting the RAM burden to the EVE, which has a much larger capacity than the MCU. It also would prevent the FIFO from filling, as CMD_DLSTART would be cached in RAM_G along with the reset of the new-screen initialization.
- Abandon the co-processor widgets and build new screens directly in RAM_G
I'm a bit surprised that the with the contention around RAM_DL and suggested swap behavior which exacerbates this contention that there is no way to either track the scanout progress, or to abort pending operations to make the co-processor available. Either of these would allow the cost of a pending swap to be managed.
In the meantime, writing zero to the REG_DLSWAP register is giving me exactly the behavior I'm looking for until I either A: encounter the 'unpredictable-behavior' mentioned, or B: proactively migrate to a MCU command buffer and DMA.