2020-07-10 09:20 AM
I'm trying to run two threads when using TouchGFX. One is TouchGFX_Task and another is custom. Problem is that custom task requires about 30ms uninterrupted run.
Problem is that running two tasks - one is interrupted which causes issues. If TouchGFX_Task is higher priority - screen works ok, but communication with external device is interrupted in another task. If TouchGFX_Task is lower priority - screen freezes and becomes unresponsive.
Tried suspending and resuming TouchGFX_Task with osThreadSuspend() and osThreadResume() but it just stops updating screen (just like with changing priority, tried with commented/uncommented versions)
Changed Preemptive mode to Cooperative in FreeRTOS configuration but did not help.
Considering trying to use semaphores and/or mutexes however I'm unsure how to proceed with TouchGFX_Task to stop it so no issues arise when suspending and resuming task.
Or maybe there is a better way to achieve something like this when using TouchGFX ?
Below is sample code of main.c, StartTask02 is my task where time-sensitive code resides.
main.c
/* Definitions for TouchGFXTask */
osThreadId_t TouchGFXTaskHandle;
const osThreadAttr_t TouchGFXTask_attributes = {
.name = "TouchGFXTask",
.priority = (osPriority_t) osPriorityHigh,
.stack_size = 2048
};
/* Definitions for myTask02 */
osThreadId_t myTask02Handle;
const osThreadAttr_t myTask02_attributes = {
.name = "myTask02",
.priority = (osPriority_t) osPriorityLow,
.stack_size = 1024
};
<....>
int main (void) {
<....>
osKernelInitialize();
TouchGFXTaskHandle = osThreadNew(TouchGFX_Task, NULL, &TouchGFXTask_attributes);
myTask02Handle = osThreadNew(StartTask02, NULL, &myTask02_attributes);
osKernelStart();
<....>
}
<....>
__weak void TouchGFX_Task(void *argument)
{
/* USER CODE BEGIN 5 */
for(;;)
{
osDelay(1);
}
}
void StartTask02(void *argument)
{
/* Infinite loop */
for(;;) {
//osThreadSuspend(TouchGFXTaskHandle);
<....> <--- time sensitive code goes here
//osThreadResume(TouchGFXTaskHandle);
osDelay(1000);
}
}
Any help or hints to solution or further reading material is appreciated;
Solved! Go to Solution.
2020-07-11 12:14 AM
Hello,
The fact that your custom task requires about 30ms uninterrupted run is a problem.
Because the TouchGFX thread shouldn't be stopped that long. 30 ms is equivalent to almost two new frames (because 60 Hz is equivalent to 1 frame every 16.6 ms).
Therefore, if it was stopped, you wouldn't be able to start rendering, sending new frame or retrieving the touch coordinates for 30 whole milliseconds. It's normal that your app is not working after that.
Unfortunately, I don't how you can make TouchGFX work with a custom task taking that long.
/Alexandre
2020-07-11 12:14 AM
Hello,
The fact that your custom task requires about 30ms uninterrupted run is a problem.
Because the TouchGFX thread shouldn't be stopped that long. 30 ms is equivalent to almost two new frames (because 60 Hz is equivalent to 1 frame every 16.6 ms).
Therefore, if it was stopped, you wouldn't be able to start rendering, sending new frame or retrieving the touch coordinates for 30 whole milliseconds. It's normal that your app is not working after that.
Unfortunately, I don't how you can make TouchGFX work with a custom task taking that long.
/Alexandre
2020-07-11 09:21 AM
Hi
you dont write what task2 do, but maybe you can USE ofload technique as DMA or timed interrupts for improve.
And recommend is use Normal priority for both tasks.
2020-07-11 11:58 AM
Thanks for support and suggestions.
Offloaded communications to DMA together with some trial and error for data rates so got it working for now, takes about 4ms now and haven't observed any issues so far.
2023-11-17 06:40 AM
Hello, your answer is already some years old.
But I have a question:
You wrote: "Because the TouchGFX thread shouldn't be stopped that long. 30 ms is equivalent to almost two new frames"
Why could it be a problem to suspend the TouchGFX for e.g. several seconds? (Or does it not apply with the use of FreeRTOS)
2024-08-28 12:26 AM
Hello,
We are facing the same issue on some of our products: all non-touchgfx related threads continue to work but the touchgfx thread is somehow suspended. If another thread takes too much time/resources, wouldn't the touchgfx thread be able to recover once the situation has become normal again?
2024-08-28 12:54 AM
In my case the problem was that the UART communication via DMA had an overrun or noise flag set, which caused to call a function so often, that the touchgfx thread was virtually never executed again. The problem disappeared after clearing the overrun or noise flag. Pausing the touchgfx for one minute is not a problem now (e.g. during writing to QUADSPI flash).
2024-08-28 05:07 AM
Hello Alexandre,
Could you say why the thread shouldn't be stopped that long? I would have expected loss in performance when the TouchGFX thread is delayed, but not that it would be stopped or suspended?
Thanks in advance,
Jurgen