I created a new feature request ticket. Doesn’t seem like there’s very much action in the Tickets section, so I thought I’d post here as well. https://sourceforge.net/p/freertos/feature-requests/78/ What can I do to maximize the likelihood of this feature being implemented in the next release? I’ve suggested a solution and provided code for it in the Ticket comments. If there’s anything more that I can do, I’d be happy to hear about it.

Generally support requests do not get discussed in the ticketing system unless it is not clear what the support request is asking for. Unfortunately it is not easy to change the way the variables are used in the run time stats as there would be a huge knock-on effect to all the people who support kernel aware plug-ins for FreeRTOS. In addition there would be the possibility to break compatibility with port specific run time stats implementations developed by and already in use by users. I have not studied your request in detail yet – but the key point is – does the ulTotalRunTime variable still hold the value of the total amount of time passed since the system booted (in whatever resolution the run time stats counter is using). If it does, then it may be feasible to consider the request – if it doesn’t them I’m afraid it can’t realistically be included. In any case, it won’t be in FreeRTOS V7.6.0 as that has already gone out to a partner, although its not due for official public release until early next week. It is already in SVN. That all said, it is always preferable to keep port specifics (such as the number of bits in the timer) outside of the core kernel code. In this case, in the macros that provide the numbers to the kernel. For example there are some Cortex-M3 implementations that use the system clock. The system clock is only 24 bits and runs very quickly, so overflows often. In a way this is analogous to your 16-bit clock scenario issues. That is handled by keeping a 32 bit count at the point the stats are provided to the kernel (outside of the kernel itself). The fast 24 bit value obtained (which is reset by the tick interrupt) is shifted right (which is a fast operation) to effect a sort of software prescale on its value. The scaled value is then ANDED with the 32-bit value. Each overflow of the value resulting in an increment in the higher bits of the 32-bit value – I haven’t explained that very well I know but hopefully it makes some kind of sense. Regards.

Richard, thanks for the reply.

does the ulTotalRunTime variable still hold the value of the total amount of time passed since the system booted (in whatever resolution the run time stats counter is using).

Yes, the ulTotalRunTime still holds the amount of time passed. The change is to allow this 32-bit ulTotalRunTime value to be updated from a 16-bit counter by treating ulTotalRunTime as an accumulator. I did also make a suggestion to add an API to reset the stats (including the ulTotalRunTime). If the plug-ins can’t handle a reset of these statistics, they can just never call that API, but it could be handy to the rest of us.

preferable to keep port specifics (such as the number of bits in the timer) outside of the core kernel code.

Absolutely agree. This is why I suggest using a macro to enable the 16-bit support. This macro can be defined by the user in their FreeRTOSConfig.h file.

I haven’t explained that very well I know but hopefully it makes some kind of sense.

I’m very familiar with Cortex-M and its 24-bit SysTick clock, but I really did not follow this explanation. Is this functionality you describe included in one of the demo projects? I’d like to know more about it. Thanks, JF

Here is an implementation but dont know it is correct.