On 10/12/14 02:53, Nick Withers wrote:
On Wed, 2014-12-03 at 08:09 +0100, Sebastian Huber wrote:
Hello Nick,
to disable TCR[ARE] is not the right fix. You have to check the
TSR[DIS] register in the nanoseconds extension. See for example
lpc-clock-config.c for an example.
Hi Sebastian,
Thanks for your help, 'fraid I need to lean on you a little more...
I don't understand how the proposed solution (or that in
lpc-clock-config.c) can work properly in the case where the nanoseconds
extension could be queried multiple times with an interrupt lock held
(which I believe disables interrupts), preventing the tick from being
incremented, as I believe happens in spnsext01.
lpc-clock-config.c's lpc_clock_nanoseconds_since_last_tick(), if I'm
understanding it correctly, says "Ah, there's an interrupt pending, so
we need to add another tick period to our current timer value". Cool
bananas.
Yes, this is exactly how it works.
But what if it's called again with the same interrupt still
pending? The timer counter may have wrapped again and we could return an
earlier time.
...Couldn't we? What am I missing?
Cheers :-)
If you disable interrupts for more than one clock tick interval, then
you have a bigger problem than a non-monotonic uptime.
If you disable the auto-reload, then the decrementer stops, so you have
a time freeze.
--
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
