On 2014-02-12 13:38, Chris Johns wrote:
On 12/02/2014 8:27 pm, Sebastian Huber wrote:
Add a CPU counter interface to allow access to a free-running counter.
It is useful to measure short time intervals.
What is meant by a short time interval and also what would a long time mean ?
This actual time interval is CPU/BSP dependent. The interval should at least
cover a system tick.
Is an overflow or wrap around status available and/or important ?
A overflow of the counter register will happen on most systems. Thus we use an
unsigned integer type since here modulo arithmetic is defined. Also the
implementation must provide the _CPU_Counter_Subtract() function. Some smaller
ARM controllers have for example only 24-bit timers.
This can be used for
example to enable profiling of critical low-level functions.
Why use this rather than the existing rtems_clock_get_uptime_nanoseconds ?
Are you looking at sub-nano second times ?
The overhead to use rtems_clock_get_uptime_nanoseconds() is too high. Also
this counter should work without a clock driver and during system initialization.
Also what happens if your driver using the busy wait is initialized before the
clock driver, etc.?
The step from CPU counter ticks to/from nanoseconds is explicit in this API
unlike to rtems_clock_get_uptime_nanoseconds().
How do you profile the spinlock used by rtems_clock_get_uptime_nanoseconds()?
I would be concerned about trace data based on this unless the over was handled
or interrupts are masked.
Add two busy wait functions rtems_counter_delay_ticks() and
rtems_counter_delay_nanoseconds() implemented via the CPU counter.
How is the user protected in a portable way across different cpus ?
Protected against what?
Is there range checking or is overflows used ?
The range is limited by the parameter integer types.
Are the calls re-entrant ?
What do you mean with re-entrant here?
diff --git a/doc/cpu_supplement/general.t b/doc/cpu_supplement/general.t
index cf28eef..3608705 100644
--- a/doc/cpu_supplement/general.t
+++ b/doc/cpu_supplement/general.t
@@ -341,6 +341,26 @@ _TLS_Size = _TLS_BSS_end - _TLS_Data_begin;
_TLS_Alignment = ALIGNOF (.tdata);
@end example
+@section CPU counter
+
+The CPU support must implement the CPU counter interface. A CPU counter is
+some free-running counter. It ticks usually with a frequency close to the CPU
+or system bus clock. On some architectures the actual implementation is board
+support package dependent. The CPU counter is used for profiling of low-level
+functions. It is also used to implement two busy wait functions
+@code{rtems_counter_delay_ticks()} and @code{rtems_counter_delay_nanoseconds()}
+which may be used in device drivers. It may be also used as an entropy source
+for random number generators.
+
+The CPU counter interface uses a CPU port specific unsigned integer type
+@code{CPU_Counter_Ticks} to represent CPU counter values. The CPU port must
+provide the following two functions
+
+@itemize
+@item @code{_CPU_counter_Read()} to read the current CPU counter value, and
+@item @code{_CPU_counter_Subtract()} to subtract two the CPU counter values.
+@end itemize
Is overflows handled in the maths ? I could not see it if important.
Should the user be able to ask the range of the counter ?
The only useful operation with values obtained by _CPU_counter_Read() is
_CPU_counter_Subtract().
--
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
