On Wed, Feb 12, 2014 at 3:43 AM, Sebastian Huber <sebastian.hu...@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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
