Then a synchronous suspend task would possibly guarantee that the task starts, then suspends, unless you manage to have a “counting suspend task”, which just somehow doesn’t seem quite right. I’d likely use the synchronous task suspend. It would be necessary to have a superuser task.
Any thoughts about that?
For many processors, there are controls for what counter/timers get disabled by a breakpoint, thus you can often keep the PWM running (but the control loop stops, so you still can have issues),
But the OS doesn’t know how to do this. Note, the OS currently has a processor-specific port layer to handle the processor-specific parts for task switching. The key fact is, how to set a “breakpoint” is inherently processor specific.
Synchronous suspension can be done by a task suspending itself (task handle = NULL). In addition in can set a flag or whatever before to tell that it’s going to be suspended. Another task can check the flag or something else (e.g. wait for a semaphore) and then poll-wait using eTaskGetState of the task going to suspend itself until it really is suspended, do whatever it has to do and suspend the task later on.
Which, to me, is a “your choice” kind of thing. IIRC, the STM32 processors I use do that. I’d still have thrown some hardware at that to prevent dumpster fires.
I do not need a breakpoint for this. This does not need to be processor specific unless you want to integrate suspending and resuming a specific task from the IDE.
In terms of my original design, pause the system queue reading task. Set a breakpoint when the last data packet is received. Enable the queue reading task and use breakpoints on it as needed. Idea is to allow the system queue to have a complete set of packets.
I was thinking of a very high priority superuser task which provides a console input to the system. It could suspend one task, use the breakpoint to inform (or a tag to the superuser task) to enable the task. It could also do stuff depending on how the task interacts with the console. Its not as elegant as simply being able to pause a task, but offers more within the framework of FreeRTOS.
How do you intend to “watch” that packet assembly happen without breakpoints and stepping?
If you just want the task to hold off until a complete set of packets is received, just add a semaphore or task notification before going to the queue reads, and have the queueing task send the notification when all is ready. No need for a special “Debugger” to handle things.
oh, I never did. I wanted it to be graceful.
Turn off one task, and then one breakpoint will do it. Turn on the task, and then the breakpoints there will do it.
Of course, that was one of the workarounds. I wanted something that would work without having to add extra semaphores for debugging. I thought that being able to pause a specific task would be conceptually more elegant.
If I decide to do it a different way (other than working around what I can’t do), I will likely create a superuser task on both nodes, and have them talk to a program running on another machine. Visually lot nicer, easier to deal with, and more elegant. I do not expect an operating system to have this ability, though. The concept might be a useful add-on for people trying to debug two simultaneous instances of a program running so to debug both ends of a communication link. However, it would require a board to board communication to a superuser task, which may require a program running on another computer. I wouldn’t expect something like FreeRTOS (or any other OS) to provide this. Might be nice, though, and could be done at the OS level (no breakpoints needed except for convenience). If you’re interested, we could talk about this. I may do this, it seems attractive and could solve a number of packet/packet communications problems. There isn’t an add-on for FreeRTOS that deals with this, is there?