Greetings,
We are in the process of converting our existing GUI (in-house emWin managed) project over to AppWizard to leverage all the resource management facilities and so far we mostly like what we see. We use an LPC4367 chip with 800/480 capacitive touch screen. Out of the box the performance seems slower than emWin, however we think we have traced the slowness to the 4bpp and other anti-aliasing portions of default behavior of AppWizard itself. Once we change back to 1bpp fonts and use only sharp square GUI objects, things seem to be considerably faster, and we understand why.
However, the following statement regarding a search on "task" in the user manual concerns us:
------------------------------------------------------------------------------------------------------------------------
AppWizard projects in multitasking environments
Please note that the AppWizard is only capable of limited multitasking. Please note the following:
- Only one AppWizard project can be executed.
- Only one task should access AppWizard functions.
Note
AppWizard functions must not be called from another task. This can lead to undefined behavior.
------------------------------------------------------------------------------------------------------------------------
As we know, the task provided (auto-generated) by AppWizard looks like this:
/*********************************************************************
* SEGGER Microcontroller GmbH *
* Solutions for real time microcontroller applications *
**********************************************************************
* *
* (c) 1996 - 2025 SEGGER Microcontroller GmbH *
* *
* Internet: www.segger.com Support: support@segger.com *
* *
**********************************************************************
----------------------------------------------------------------------
File : APPW_MainTask.c
Purpose : APPWIZARD application entry point
---------------------------END-OF-HEADER------------------------------
*/
#include "Generated/Resource.h"
/*********************************************************************
*
* MainTask
*/
void MainTask(void) {
//
// Setup configuration dependent pointers
//
APPW_X_Setup();
//
// Initialize AppWizard
//
APPW_Init(APPW_PROJECT_PATH);
//
// Create all persistent screens except initial screen
//
APPW_CreatePersistentScreens();
//
// Create initial screen...
//
APPW_CreateRoot(APPW_INITIAL_SCREEN, WM_HBKWIN);
//
// ...and keep it alive
//
while (1) {
while (GUI_Exec1()) {
APPW_Exec();
}
APPW_Exec();
GUI_X_Delay(5);
}
}
/*************************** End of file ****************************/Does the user manual mean "MainTask" is the only task that can call APPW_<routines> whatsoever? If so, how is the feasibility of the AppWizard viable? Does this mean that the MainTask must be the only task that makes calls such as APPW_DoJob()? Or can I have another task (only one) besides the main event processor loop (MainTask) that makes calls into APPW_DoJob() to externally change the visible screen?
In my situation, imagine my application performs a test on some hardware which takes some time. I press the button on the screen, GUI_Exec1() and APPW_Exec() end up processing the event(s) which came in from my (separate, irq-driven) touch-task through GUI_TOUCH_StoreStateEx(). I then get an automatic call to my corresponding "slot" routine which I queue a command to another task to perform the actual test on the hardware. That task blocks until completion, as I cannot have MainTask block, since it needs to also receive the possible "abort" GUI press if one comes in. I was planning on this secondary task, the one that received a queued actionable command, to make the call into APPW_DoJob() to change the screen when the test is complete. If the test was instead aborted, the GUI would also capture that, fire the appropriate slot handler and set a global abort flag that I monitor in hardware, and that enqueued command would come back with a status of "aborted". The same secondary task would still make a call into APPW_DoJob() to make the GUI show the correct state of the executed command whether it executed properly or was aborted. In both cases, a secondary task would need to call APPW_DoJob to change the screen.
So, is calling APPW_DoJob() from another task other than "MainTask" unsupported? If so, what is the purpose of the APPW_DoJob() routine if you cannot programmatically call it from another task outside of the main event loop that is solely responsible for keeping the AppWizard event loop alive?
If anyone knows why this won't work, we need to know ASAP because we need to pivot back to implementing everything in raw emWin primitives, which will be an absolute nightmare. If there is a newer version of AppWizard/emWin that supports multi-tasking better (such as mutex'es on any shared APPW objects, just like GUI_X_Lock/GUI_X_Unlock routines allow you to do), we may be interested in upgrading to the paid version above and beyond NXP's licensing terms for the LPC4367.
Kind regards,
Brad