I’ve managed to get the C++ tasking working, and create C++ tasks with semaphores and queues, which are all that I need. However, I have a few questions and some observations.
-
Apparently, It’s one task per C++ class. I have a situation where two tasks are needed. Side stepped that one by having one task as part of the class and one task with the original code, not a member of the class.
-
In the hardware design I have, the graphics are a RAM hog, and the processor has insufficient memory. I’ve added memory (it’s an STM32L562VET6Q processor with an OCTOSPI interface. The memory is an AP6404 64 Mbit QSPI memory). The added memory is significantly slower than processor on board memory.
I’ve changed the FreeRTOS stack to use external memory (part of the 64Mbit memory) as the heap. For tasks happening every 100 ms or so, (vTaskDelay) the speed difference does not slow down the system.
However, the graphics system writes to a virtual display image (32 bit color). The low level display driver task (in this case for an ILI9341) takes a queue input of an update packet (rectangular area update) and copies and formats the virtual display for the ILI9341, calling the SPI drivers as needed.
This works.
However. If the task is located in extended memory, it’s quite slow. If the task is located in processor memory, it runs quite a bit faster (acceptably so).
The question becomes: TaskClassS makes decisions on the global condition of whether static allocation is used or not. Short of modifying that class (and making a copy of it), is there a way to specify the location of the task in the system call to TaskClassS?
- last, and a puzzlement.
The screen variable is the owner of a graphics tree of linked graphics objects, which can have siblings, and in some cases children. Drawing the screen automatically draws all objects belonging to that screen. This works, mostly.
With the widgets (graphics objects that update themselves with a task), I get several problems with TaskCPP. One is that not all of the code in the class works properly, which may well be related to the use of a virtual object for drawing. It looks as if the virtual object is broken somehow so that a simple “if object.property == specific property)” equality is not working.
The other problem I’m having with this is that the draw routine hangs when drawing a widget. Literally, wherever it gets to, the rest of the tasks work and the main task is somehow suspended. No idea on that one.
I do have a workaround, and that’s simply to go back to the original code, which places the task outside the class. Oddly enough, that works perfectly.
Any thoughts?
Thanks, code is much nicer with the wrappers…