I have an application running under FreeRTOS with STemWin V5.40. I have setup two tasks to work with the GUI, an application task and an updater task.
The first task, the application task, calls GUI_Init(), calls WM_MULTIBUF_Enable(1) and then starts an updater task. After the updater task is started, the application continues to creates multiple windows. The application then enters a loop which switches between the windows by calling GUI_BringToTop() and at then end of the loop it executes a dialog with GUI_ExecDialogBox(). The Dialog Box terminates with a call to GUI_EndDialog() when it detects a button release. Then it goes to the beginning of the loop to cycle through the windows again.
The updater task just calls GUI_Exec() and osDelay(1) in a loop to refresh the screen.
When these two tasks are at the same priority level the GUI appears to update properly. (At least most of the time. Sometimes I see a partial dialog image show up when starting the dialog that clears itself. I think this might be a symptom of the same underlying problem.)
But if the updater task is at a higher priority than the application task then things start getting weird. It appears to work fine until the Dialog gets executed, then the screen updates stop. The dialog gets drawn once, but I do not see the buttons getting updated. And when the dialog exits the other windows do not show up. The dialog window continues to be displayed.
If I monitor the driver, I do not see any more calls to the LCD_X_SHOWBUFFER after the Dialog starts executing.
The first task, the application task, calls GUI_Init(), calls WM_MULTIBUF_Enable(1) and then starts an updater task. After the updater task is started, the application continues to creates multiple windows. The application then enters a loop which switches between the windows by calling GUI_BringToTop() and at then end of the loop it executes a dialog with GUI_ExecDialogBox(). The Dialog Box terminates with a call to GUI_EndDialog() when it detects a button release. Then it goes to the beginning of the loop to cycle through the windows again.
The updater task just calls GUI_Exec() and osDelay(1) in a loop to refresh the screen.
When these two tasks are at the same priority level the GUI appears to update properly. (At least most of the time. Sometimes I see a partial dialog image show up when starting the dialog that clears itself. I think this might be a symptom of the same underlying problem.)
But if the updater task is at a higher priority than the application task then things start getting weird. It appears to work fine until the Dialog gets executed, then the screen updates stop. The dialog gets drawn once, but I do not see the buttons getting updated. And when the dialog exits the other windows do not show up. The dialog window continues to be displayed.
If I monitor the driver, I do not see any more calls to the LCD_X_SHOWBUFFER after the Dialog starts executing.