Hello
I'm doing some experiments with RTX to investigate how quickly it switches between tasks and how much of the time I can make the processor (STM32F103 sleep.
Following the advice in this thread (http://www.keil.com/forum/18158/) I've implemented a function in my code with the signature:
void rt_post_taskswitch (U32 task_id)
As I understand it, RTX should call this after a task switch however this never happens (the break point I've set in the function is never hit). I had a quick poke around the RTX source and I can see where the function is weakly declared and where it's called. Everything looks fine except my implementation of the function never gets called.
I suspect this is because the project is linking against the RTX library and unless I recompile RTX along with my project it'll never know I've implemented the function.
What's the neatest way to go about making this work?
Many thanks in advance, Al
My log included interrupts - I did see our 1[ms] background ISR, but no task switch for about 40[ms]+ even though the controller seemed to have been functioning correctly. Or maybe the kernel did not switch tasks after all - but that was certainly not due to priority issues or it being disabled. I don't remember...
I have never tried this function.
The only profile I have done have been using LEDs in ISR and high-prio tasks.
So task A (with highest prio) lights LED A when it runs, and turns off the LED when it calls a wait function. LED A will then represent the total time spent with thread A running (including time spent for ISR processing).
Task B (next highest prio) lights LED A when it runs, and turns off the LED when it calls a wait function. LED B will represent the total time spent for ISR processing, task A and task B. B-A will represent time used by thread B.
Same thing for next lower task.
That have managed to cover the most important stuff. For less important tasks, I have read out a high-speed timer when an ISR or high-prio task sees something that needs to be done, and the low-prio task picks up the timer value again when having serviced the event. In this case, I haven't really bothered with CPU load, but only been interested in average and worst-case response times.
With a four-channel scope, quite a lot of information can be gathered from such a setup. A scope with configurable hold-off time for trigger can give even more interesting information while the system is up and running - and still with quite low additional CPU load and with a minimal need for any bandwidth on any peripherial. The only bandwidth needed would basically be to regularly dump avg + worst-case for event processing in full timer resolution (in my case 12MHz tick speed).
Many thanks for all the input.
I'm still having no luck making my rt_post_taskswitch work. This is probably my lack of knowledge with the linker.
I'm going to play around with different ways of doing this, probably just adding calls at entry and exit points of tasks.
Cheers, Al
"probably just adding calls at entry and exit points of tasks."
Note that depending on thread priorities, and if you have round-robin scheduling, you can get lots of task switches that will not result in any printout because the task that gets put to sleep was between two printouts, and the woken task was previously paused while between two printouts.
All you can manage is to print just before you call a wait-capable function, and directly after it returns. But that isn't enough.