Programmatic use of CH_DBG_STATISTICS

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: RoccoMarco, barthess

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Programmatic use of CH_DBG_STATISTICS

Postby andypiper » Sat Dec 19, 2020 4:18 pm

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

User avatar
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

Postby Giovanni » Sat Dec 19, 2020 4:25 pm

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

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Programmatic use of CH_DBG_STATISTICS

Postby andypiper » Sat Dec 19, 2020 5:18 pm

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?

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Programmatic use of CH_DBG_STATISTICS

Postby andypiper » Sat Dec 19, 2020 7:56 pm

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()

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Programmatic use of CH_DBG_STATISTICS

Postby andypiper » Wed Apr 14, 2021 7:29 pm

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.

User avatar
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

Postby Giovanni » Wed Apr 14, 2021 8:01 pm

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

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Programmatic use of CH_DBG_STATISTICS

Postby andypiper » Wed Apr 14, 2021 10:59 pm

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.

User avatar
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

Postby Giovanni » Thu Apr 15, 2021 5:04 am

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

andypiper
Posts: 65
Joined: Sat Oct 24, 2020 5:21 pm
Has thanked: 5 times
Been thanked: 4 times

Re: Programmatic use of CH_DBG_STATISTICS

Postby andypiper » Thu Apr 15, 2021 8:03 am

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

User avatar
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

Postby Giovanni » Thu Apr 15, 2021 9:59 am

There should not be weird values for "cumulative", that is an uint64_t variable that is only increased until it wraps.

Giovanni


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 21 guests