uCOS-II has a Statistics task that computes the CPU usage of the idle task. This very useful to keep an eye on the processor load.
Is there anything similar for this (apparently earlier) version of uCOS?
uCOS task statistics
Re: uCOS task statistics
Hi Jeff,
I don't think so, but you do have access to the idle task, so you could put a counter in there to get some information. Just need to rebuild the libs after any changes to system files.
I don't think so, but you do have access to the idle task, so you could put a counter in there to get some information. Just need to rebuild the libs after any changes to system files.
Re: uCOS task statistics
Putting in a counter is a good idea. After this run a test that stays idle all the time so you know how many counts you get per second. Then when you run your normal application you will know how long you are idle.
I also made a debugging application a while ago that might help you. It sets off a level 7 interrupt triggered by a timer and records the last program counter address. You can then look at the log of all the addresses to get a rough idea where your application was spending time. You can modify this for different granularity or a larger log file in RAM if needed. There is a main.cpp file that demonstrates how to use this. You will want to use the winaddr2line PC tool to decode the PC addresses to the line in your c application.
-Larry
I also made a debugging application a while ago that might help you. It sets off a level 7 interrupt triggered by a timer and records the last program counter address. You can then look at the log of all the addresses to get a rough idea where your application was spending time. You can modify this for different granularity or a larger log file in RAM if needed. There is a main.cpp file that demonstrates how to use this. You will want to use the winaddr2line PC tool to decode the PC addresses to the line in your c application.
-Larry
- Attachments
-
- TimeSliceProfiler.zip
- Time Slice Profiler Debugging tool
- (2.69 KiB) Downloaded 417 times
Re: uCOS task statistics
Thanks for the tips. After looking at how the taskstat function works in ucos-ii I put a counter into the idle task. Its pretty much the same idea as Larry described. It starts just one task, then records the count from the idle task for one second before starting other tasks. It then has a basis for comparing the idle counts to determine a CPU usage.
I'll have to try out your time slice profiler Larry, it looks interesting. Alternately, I'll revert to monitoring discretes on the scope, as I've usually done.
I'll have to try out your time slice profiler Larry, it looks interesting. Alternately, I'll revert to monitoring discretes on the scope, as I've usually done.
-
Ridgeglider
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: uCOS task statistics
I often have a "housekeeping" task that handles various simple odds and ends that need attention regualrly. The priority for this task is typically the lowest in my set of tasks; after all, who likes to clean up if there are more pressing things to do? Unlike most of the other tasks, I trigger this task off a regualrly occuring timer interrupt that just posts a semaphore to the pending housekeeping task, usually every 100msec. Within that task, I toggle a port bit. One way to see if the system is getting loaded up is to watch the regularity of the port bit toggling, either on a scope, a frequency counter, or concievably even a capture input timer. If the system is too busy, this (lowest-priority) pending task won't be serviced regularly at the desired 10 Hz.
I also use these timer-based tasks for control loop processing, or AD sampling that need to occur on a regular drumbeat sample clock. If you include a port-bit telltale (perhaps optionally enabled with an ifdef... macro), you can get a handle on whether the task loading or priority allows it to occur with the expected regularity. This works as long as the interval is long compared to the task switch time.
I try to keep a few port bits available than can be conditionally assigned to various tasks for this kind of telltale debugging. Using more than one bit allows you to ascertain the actual timing relationship between several tasks more clearly. When you are done, comment the code out, or assign them to be active somewhere else.
I also use these timer-based tasks for control loop processing, or AD sampling that need to occur on a regular drumbeat sample clock. If you include a port-bit telltale (perhaps optionally enabled with an ifdef... macro), you can get a handle on whether the task loading or priority allows it to occur with the expected regularity. This works as long as the interval is long compared to the task switch time.
I try to keep a few port bits available than can be conditionally assigned to various tasks for this kind of telltale debugging. Using more than one bit allows you to ascertain the actual timing relationship between several tasks more clearly. When you are done, comment the code out, or assign them to be active somewhere else.