On 2014-02-12 16:06, Gedare Bloom wrote:
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.
No, that is not necessary. The use cases for values obtained by
rtems_counter_read() is very limited. You can use it as an entropy source, in
this case its just a number without further meaning. The second use case is a
time instant value. In this case the only useful operation is to calculate the
difference between two such values (rtems_counter_subtract). Once you have a
difference further operations with it are normal integer operations.
+/**
+ * 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?
Yes, an application should not use this function. It might be necessary to
call this function again if the counter frequency changes (e.g. some power
saving state).
Thanks, and the code is looking good to me.
Gedare
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
