I'd like to use CH_DBG_STATISTICS to display in our own code information about thread CPU usage, but I am struggling to find any documentation on how I might do this. Can anyone give me a pointer?
The associated problem I'm trying to solve is that I have a low priority thread that is not getting any cycles under certain circumstances but I am really struggling to find the culprit for the CPU pinning. I thought that displaying the thread statistics for the other threads might show me which thread is taking a longer slice than it should. It should be easy to spot because when this problem happens the lower priority thread doesn't get the CPU for 10s - when normally it is ticking every ms.
Thanks in advance
andy
Programmatic use of CH_DBG_STATISTICS
Moderators: RoccoMarco, barthess
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Programmatic use of CH_DBG_STATISTICS
Hi,
When statistics are enabled each threads has a time_measurement_t structure named "stats" in its thread_t structure, you can access it at runtime. Look for time measurement in the documentation.
If the thread is not executed then there is some other thread at higher or equal priority that does not release the CPU under certain conditions.
Giovanni
When statistics are enabled each threads has a time_measurement_t structure named "stats" in its thread_t structure, you can access it at runtime. Look for time measurement in the documentation.
If the thread is not executed then there is some other thread at higher or equal priority that does not release the CPU under certain conditions.
Giovanni
Re: Programmatic use of CH_DBG_STATISTICS
andypiper wrote:Thanks - that works great, but I can't find a mechanism to convert from RTC to regular time - is there an inverse to OSAL_US2RTC somewhere?
Found it - RTC2US()
Re: Programmatic use of CH_DBG_STATISTICS
Giovanni wrote:Hi,
When statistics are enabled each threads has a time_measurement_t structure named "stats" in its thread_t structure, you can access it at runtime. Look for time measurement in the documentation.
If the thread is not executed then there is some other thread at higher or equal priority that does not release the CPU under certain conditions.
Giovanni
I'm back on this now. I have had the raw statistics data available for a while now but want now to produce a percentage CPU figure for each thread. I'm doing this by first summing all the tp->stats.cumulative data and then calculating the percentage for each thread using this and the individual value. This produces believable numbers apart from some threads which are completely out of whack. Any clues what might be going on here?
Also for one thread min and max come out as 268435456 which seems really weird. My min calculation is unsigned(RTC2US(STM32_HSECLK, tp->stats.best)) for instance.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Programmatic use of CH_DBG_STATISTICS
Is it possible that tp->stats.best is equal 0xffffffff in such cases? The "best" field is initialized to 0xffffffff initially so it is a very big number until the 1st measurement is performed.
Giovanni
Giovanni
Re: Programmatic use of CH_DBG_STATISTICS
Giovanni wrote:Is it possible that tp->stats.best is equal 0xffffffff in such cases? The "best" field is initialized to 0xffffffff initially so it is a very big number until the 1st measurement is performed.
Giovanni
Ok so I should check for that before doing the conversion.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Programmatic use of CH_DBG_STATISTICS
andypiper wrote:Giovanni wrote:Is it possible that tp->stats.best is equal 0xffffffff in such cases? The "best" field is initialized to 0xffffffff initially so it is a very big number until the 1st measurement is performed.
Giovanni
Ok so I should check for that before doing the conversion.
Yes, the initial values are 0xffffffff for "best" and 0 for "worst", "best > worst" should work too.
Giovanni
Re: Programmatic use of CH_DBG_STATISTICS
Giovanni wrote:andypiper wrote:Giovanni wrote:Is it possible that tp->stats.best is equal 0xffffffff in such cases? The "best" field is initialized to 0xffffffff initially so it is a very big number until the 1st measurement is performed.
Giovanni
Ok so I should check for that before doing the conversion.
Yes, the initial values are 0xffffffff for "best" and 0 for "worst", "best > worst" should work too.
Giovanni
But there are no weird values for the cumulative slot? I guess that's still my biggest problem
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: Programmatic use of CH_DBG_STATISTICS
There should not be weird values for "cumulative", that is an uint64_t variable that is only increased until it wraps.
Giovanni
Giovanni
Who is online
Users browsing this forum: No registered users and 21 guests