BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: Concerns with ESD and generated source  (Read 322 times)

swissNanoTrom

  • Newbie
  • *
  • Posts: 3
    • View Profile
Concerns with ESD and generated source
« on: June 07, 2022, 08:40:59 AM »

* In contradiction to the EVE concept of a co-processor for offloading host MCU from graphics drawing,
   the ESD generated source has an endless, fulltime burner loop for repeated Updates/Render (about each 5-20ms), even if the HMI didn't change!!??
   What is the rational behind this?
   Any chance for changing (in near future) to an event-driven (dirty-state => refresh) model?
   Also note:
     - what about the touch-input tags repeatedly getting swapped out+in?
     - RTOS unfriendly.
     - this is energy-unfriendly if battery powered.
     - causes constant EMI on cables.

* the new 'Switch Page' concept is very under-documented! (e.g. hierarchical usage),
    there is a 'Fill Display' show on a screenshot (Figure 44, PDF man 4.15), but undocumented!
     Urgent need for new tutorial video explaining all this, sample page transition.

* There is a well hidden document BRT_AN_073 for porting ESD source to STM32L4.
   Bad: the listed files are not available from bridgetek github anywhere, namely EVE_HalImpl_STM32L476GDISCOVERY.c !!??
      (by pure chance I found an older 'clone' at https://github.com/kaetemi/nuklear_eve )

* please add an option to export (eclipse) source with alternative name for the entry fn, instead of main().

Thanks!
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: Concerns with ESD and generated source
« Reply #1 on: June 14, 2022, 06:56:26 AM »

* In contradiction to the EVE concept of a co-processor for offloading host MCU from graphics drawing,
   the ESD generated source has an endless, fulltime burner loop for repeated Updates/Render (about each 5-20ms), even if the HMI didn't change!!??
   What is the rational behind this?
   Any chance for changing (in near future) to an event-driven (dirty-state => refresh) model?

It's a simple loop that's familiar to Arduino users. It's also common in games. EVE has a bit of a background in both of those.
It makes things easy to understand for new developers who are already familiar with that style.
For animations it's also convenient.

Having it only run the loop when necessary is feasible, but it'll need more care from developers to flag when a refresh is needed.

     - RTOS unfriendly.
     - this is energy-unfriendly if battery powered.

That said, when the ESD Core library is waiting for something it'll spin on the Idle function callback of the application.
You might be able to take advantage of that call to enter a low power mode when ESD Core is doing nothing, and just go back into full speed based on some interrupt.

It'll spin on Idle in two situations:
  • When in-between frames, and waiting for the display list to swap. This is called from the main loop directly
  • Whenever writing to the coprocessor, and the coprocessor space is full. This is can be called very deep in the call stack
If you want to integrate with an RTOS event loop, then you can just use that event loop, and call the inner loop function once whenever EVE signals a frame swap (and disable the display list swap wait).
Ideally you'll also want to enter into your event loop from that second Idle situation. Mask out any events that would affect the ESD library while it's waiting. Exit the event loop whenever EVE sets some interrupt.

Do you have any reference device with power management and a reference RTOS to see how this can be integrated?

     - what about the touch-input tags repeatedly getting swapped out+in?

Not sure what you mean by this?

* There is a well hidden document BRT_AN_073 for porting ESD source to STM32L4.

That port has not been actively maintained and tested, as far as I know, so not sure what its state is.
Logged

pauljiao

  • Newbie
  • *
  • Posts: 49
    • View Profile
Re: Concerns with ESD and generated source
« Reply #2 on: June 14, 2022, 07:46:08 AM »

As far as I know, in ESD generated source code, there is an "idle" callback function which users can reimplement and wait there till touch is detected.
Logged

Cyrilou

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: Concerns with ESD and generated source
« Reply #3 on: June 14, 2022, 03:11:24 PM »

* please add an option to export (eclipse) source with alternative name for the entry fn, instead of main().

Hi,

In eclipse you can ignore the file where main fonction is used (app_generated.c) from your project then you can duplicate it and create your own in an other folder. Like this, when I export from ESD, I overwrite always the same folder but my custom App_generated.c is safe.
Logged

swissNanoTrom

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Concerns with ESD and generated source
« Reply #4 on: June 20, 2022, 09:06:57 AM »

@Kaetemi, thanks for your answer,
Yes, the Idle function callback of the application could be used
for some cases, BUT it is called somewhat  'unpredictable' or multiple times.
  (see Esd_Loop()  =>  Esd_Update() : Idle at least once every frame)

I STRONGLY propose to add a specific app-callback,
I guess best place would be here in Esd_Loop as last line in the while-loop, like:
ESD_CORE_EXPORT void Esd_Loop(Esd_Context *ec)
{
........Esd_Start(ec);
   while (Esd_IsRunning__ESD() && !ec->RequestStop)
   {
      Esd_Update(ec);
      Esd_Render(ec);
      Esd_WaitSwap(ec);
                ec->FrameDone();  // <<<<< CALLBACK APP (ONLY HERE!)
   }
   Esd_Stop(ec);
}

Thanks!
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: Concerns with ESD and generated source
« Reply #5 on: June 20, 2022, 10:18:47 PM »

@Kaetemi, thanks for your answer,
Yes, the Idle function callback of the application could be used
for some cases, BUT it is called somewhat  'unpredictable' or multiple times.
  (see Esd_Loop()  =>  Esd_Update() : Idle at least once every frame)
Thanks!

For all the Idle calls that are done during the WaitSwap step, LoopState will be set to ESD_LOOPSTATE_IDLE.
Any other Idle calls that may be done deep in the call stack may have update or render loop state set instead.

As far as the multiple calls, it seems okay to just check in the Idle call if the low power state was already enabled to deduplicate.
Maybe a single IdleEnd call after each batch of Idle calls may be useful to restore back to full speed, though... :)

Do you have any reference device with power management and a reference RTOS to see how this can be integrated in practice?
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: Concerns with ESD and generated source
« Reply #6 on: June 21, 2022, 12:37:32 AM »

Alternatively, instead of using the Esd_Loop function, reimplement this behaviour into your RTOS event loop.

Whenever you get an interrupt from EVE, push an event in your RTOS event loop, check if the current loop state is IDLE and the frame swap is done, and if so call Esd_Update and Esd_Render.

Instead of Esd_WaitSwap, you'll need a new function to check the swap (EVE_Cmd_rp(phost) == EVE_Cmd_wp(phost)) and also check EVE_CMD_FAULT(rp),
refer to EVE_Cmd_waitFlush and Esd_WaitSwap to see how the fault state is resolved correctly - it affects some internal state.
After cmd is swapped or reset, check if EVE_Hal_rd8(phost, REG_DLSWAP) == 0 --- this is just to catch any unexpected behaviour.

In this case Idle will only get called deep in the call stack while the command buffer is full (this should resolve quickly), so from there you can just pump any pending events in your RTOS event loop.
Logged

swissNanoTrom

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Concerns with ESD and generated source
« Reply #7 on: June 23, 2022, 09:29:35 AM »

The file Esd_Context.c in function Esd_Render(Esd_Context *ec)
has code lines in DEBUG builds:
Code: [Select]
  #if defined(_DEBUG)
   // This will cause a dark red screen in case background video incorrectly swaps the display
   EVE_Hal_startTransfer(phost, EVE_TRANSFER_WRITE, RAM_DL);
   EVE_Hal_transfer32(phost, CLEAR_COLOR_RGB(0x40, 0x00, 0x20));
   EVE_Hal_transfer32(phost, CLEAR(1, 1, 1));
looks a bit suspect to me. IMHO this should be an opt-in sequence in request, not the default for debug.
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 29
    • View Profile
Re: Concerns with ESD and generated source
« Reply #8 on: June 25, 2022, 11:15:35 PM »

Code: [Select]
  #if defined(_DEBUG)
   // This will cause a dark red screen in case background video incorrectly swaps the display
   EVE_Hal_startTransfer(phost, EVE_TRANSFER_WRITE, RAM_DL);
   EVE_Hal_transfer32(phost, CLEAR_COLOR_RGB(0x40, 0x00, 0x20));
   EVE_Hal_transfer32(phost, CLEAR(1, 1, 1));

If you ever see this screen, it means a duplicate or spurious display list swap occurred for some reason.
Or in other words, you would have swapped in a completely invalid display list.

See the implementation of EVE_CoCmd_videoFrame, which patches one of those cases.
This is enabled in debug specifically to catch those issues early.

Normally this will always be overwritten by the coprocessor rendering commands, so you should never see this screen.
Logged