[PATCH] score: Add CPU counter support

Gedare Bloom gedare at rtems.org
Wed Feb 12 15:06:06 UTC 2014


On Wed, Feb 12, 2014 at 3:43 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello Gedare,
>
>
> On 2014-02-11 19:17, Gedare Bloom wrote:
>>
>> I like this idea. I have some requests about the interface though.
>>
>> First, is there only one possible counter or would it be extended in
>> the future to multiple?
>
>
> why do you need more than one free-running counter?  Linux (and many other
> operating systems) have only one get_cycles() function.
>
>
>> If there may be multiple, this resource should
>> be represented in the score and configured as an Object, with a
>> traditional interface in the classic (rtems/rtems) API. I'm not
>> convinced putting the interface into sapi is exactly the right thing
>> to do, unless some piece of the public API is needed before
>> initialization completes. With a classic interface, the 'manager' can
>> better encapsulate the counter storage such as the frequency scalar.
>> The more I think about it, the more a simple Counter manager makes
>> sense to me.
>
>
> No, a counter object makes no sense and would introduce cyclic dependencies.
> The use case for this free-running counter is profiling, busy wait delay
> functions and maybe also an entropy source for random numbers.
>
> http://www.rtems.org/wiki/index.php?title=SMP#Profiling
>
> This counter must be available early to be of any use and the overhead to
> read the counter must be as small as possible.
>
OK thanks for the link that helps me understand your goals here. It
looks like there will need to be some additional functions defined
over the rtems_counter_ticks type, such as 'max' and possibly 'add'
for accumulating statistics.

>>> +/**
>>> + * brief Initializes the CPU counter to/from nanoseconds converter
>>> functions.
>>> + *
>>> + * This function must be used to initialize the
>>> + * rtems_cpu_counter_to_nanoseconds() and
>>> rtems_cpu_counter_from_nanoseconds()
>>> + * functions.  It should be called during system initialization by the
>>> board
>>> + * support package.
>>> + *
>>> + * @param[in] uint32_t frequency The current CPU counter frequency in
>>> Hz.
>>> + */
>>> +void rtems_cpu_counter_initialize_converter( uint32_t frequency );
>>> +
>>
>> I don't like this name, because it is not clear what a "converter" is
>> just by seeing it. The correct technical term for what is done is to
>> compute the prescaler to use when dividing the counter to obtain a
>> nanoseconds value. So I would suggest the name:
>> rtems_counter_initialize_prescaler(uint32_t frequency);
>
>
> To change nanoseconds to/from ticks is clearly a conversion.  The existence
> of a prescaler is an implementation detail.  The comment states which
> converter functions are targeted.  So I will keep the name.
>
OK, but does this function need to be part of the sapi? It is
implemented within the bsp, and invoked by the bsp during bootstrap. I
don't see a reason the function would be re-invoked (to re-initialize
the converter), so an application should never call this function?

Thanks, and the code is looking good to me.
Gedare



More information about the devel mailing list