Hello,
Recent day I was struggling in handling with multitasks calling emWin.
It seems that sometimes I need to use the pair of WM_LOCK()/WM_UNLOCK().
But not very sure. The manual does not mention it in details.
In my multitask system (FreeRTOS), I follow the recommendations (chapter 17.4.5) strictly:
- All UI requests are organized as events
- One task handling with UI events as UI foreground task
- One task calling GUI_Exec() as UI background task
- Other real time tasks sending UI events to UI foreground task
- Also there're some custom widgets
But the code does not seem that stable, sometimes complains with "DataAbortFault".
So I start to think about using the pair of WM_LOCK()/WM_UNLOCK(), just as a try.
The questions are:
Do I need to use them in any callbacks? (I thought NOT)
Or just in the creation/callback/get/set functions of the custom widgets? (I thought NOT ENOUGH)
Is there any general guideline to use the pair of WM_LOCK()/WM_UNLOCK()?
Would anybody kindly give a clear answer?
Thanks in advance!
Kenmux
Recent day I was struggling in handling with multitasks calling emWin.
It seems that sometimes I need to use the pair of WM_LOCK()/WM_UNLOCK().
But not very sure. The manual does not mention it in details.
In my multitask system (FreeRTOS), I follow the recommendations (chapter 17.4.5) strictly:
- All UI requests are organized as events
- One task handling with UI events as UI foreground task
- One task calling GUI_Exec() as UI background task
- Other real time tasks sending UI events to UI foreground task
- Also there're some custom widgets
But the code does not seem that stable, sometimes complains with "DataAbortFault".
So I start to think about using the pair of WM_LOCK()/WM_UNLOCK(), just as a try.
The questions are:
Do I need to use them in any callbacks? (I thought NOT)
Or just in the creation/callback/get/set functions of the custom widgets? (I thought NOT ENOUGH)
Is there any general guideline to use the pair of WM_LOCK()/WM_UNLOCK()?
Would anybody kindly give a clear answer?
Thanks in advance!
Kenmux