Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darkjezter]

Hey all,

Perhaps this is a question for the Bridgetek folks, but I'm looking for a way to rapidly cancel pending operations and first up is the frame-swap if one has been scheduled.

I've found that the swap can be aborted allowing dependent operations to proceed by writing a zero to REG_DLSWAP.  While my testing looks good, the documentation specifically states not to write 0 to this register.

I'm interested in using this to rapidly begin a new screen without waiting for the previous swap (and corresponding CMD_DLSTART) to complete.  Any specific reason this particular operation is specifically prohibited in the doc?

[BRT Community]

Hello,

The REG_DLSWAP register should not be written to 0 as explicitly stated in the documentation.
Ignoring this could result in unpredictable behaviour of the IC.

Best Regards,
BRT Community

[Rudolph]

You forgot to mention why you believe that would need this in the first place.
What is the issue that needs fixing with this?

And there is only a very narrow time-window for such an operation to even work, and unpredictable since it depends
on how far the current frame is rendered before REG_DLSWAP is written with DLSWAP_FRAME.
It could take from no time at all to a full frame.

[darkjezter]

Very well then.

Is there any other alternative which doesn't require switching to line swap?

I see no way to determine when a frame is nearing completion (no register showing the current vertical position in scanout).  Heck, the only way I can see to switch from a frame-swap to a line-swap is by replacing CMD_SWAP with CMD_MEMWRITE.

Is there perhaps a way to abort all pending operations and begin populating the command FIFO in less than the frame interval?

Cheers!

[BRT Community]

Hello

Curious as to what you are trying to achieve, is there any particular reason you wish to :

abort all pending operations and begin populating the command FIFO in less than the frame interval?

You are correct there is no register which will give you the current scan out position. You can probably do the maths given the display parameters of the screen you are using the PCLK frequency being used. For a given 60 Hz refresh rate you are looking at 16ms for a frame, is there a necessity in your application to update a frame in an interval that is less than 16ms?

Best Regards,
BRT Community

[darkjezter]

The issue arises from the contention around RAM_DL when using co-processor widgets.

Suppose we have a simple case of a screen with a large amount of static content which is populated once as the screen is activated.  In addition to the static content, there is dynamic content which is updated once per frame by tracking when CMD_SWAP has been sent, and when the swap interrupt has been triggered.  To avoid blocking and overflowing the FIFO, these updates are suppressed until the SWAP interrupt occurs.  This works well, ensures there is only one swap holding up the FIFO at a time, and generally results in the FIFO being nearly empty.

Now, suppose a different screen needs to be displayed, with a similar bulk of static content populated during initialization.  Also that it's triggered in response to some error or other event that is not-related to the UI of the previous screen.  The update to the previous screen and the request to swap now prevent the FIFO from being emptied by the co-processor for up to a full frame interval.

The path that led me to this question, was trying to invalidate the updates to the previous screen so that the new screen could be constructed without waiting the frame interval.  I don't need the new screen to be displayed immediately, I simply want predictable data-transfer times across SPI to the EVE.

You can probably do the maths given the display parameters of the screen you are using the PCLK frequency being used

Am I correct in understanding that your suggestion here is to track the timing of when the previous swap interrupt occurred, and suppress future swap requests until some fraction of the frame interval expires?

If that's the case, I hope you can appreciate why I'd seek to exhaust alternatives like cancelling a swap and/or resetting the co-processor.

[Rudolph]

Just relax and implement a state based display refresh then?

Code: [Select]

20ms_task()
{
  display_refresh();
}

display_refresh()
{
 if(alarm)
 {
  display_screen_alarm();
}
else
{
 switch(screen)
 {
  case 0:
       display_splash_screen;
       break;
  case 1:
       display_screen_1;
       break;
  case 2:
       display_screen_2;
       break;
  default:
       display_splash_screen;
       break;
 }
}

Just let it flow.

>and when the swap interrupt has been triggered

The only interrupt I am using is the end-of-dma Interrupt to execute the display-list that has been written and that resets the flag
that indicates that the SPI is busy.

>I simply want predictable data-transfer times across SPI to the EVE.

Putting it on a timer and therefore updating the screen asynchronously makes it very predictable.

And it is a human-machine-interface, the user will not notice if there are only a few ms delay betwen touching a button and
the visual feedback for it.

[darkjezter]

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.