The QNX time (eg as returned by time(NULL)) on our Arm platform drifts from
our hardware real time clock.
I’d like to track this drift in the software but I can’t find a libray
function to read the hardware rtc.
I’d assumed that clock_gettime(CLOCK_REALTIME, &time) would do this, but it
is yet another way of getting the system current time.
What library call can I use ?
Nick Horsley
Nick Horsley <nick.horsley@emsgroup.co.uk> wrote:
The QNX time (eg as returned by time(NULL)) on our Arm platform drifts from
our hardware real time clock.I’d like to track this drift in the software but I can’t find a libray
function to read the hardware rtc.I’d assumed that clock_gettime(CLOCK_REALTIME, &time) would do this, but it
is yet another way of getting the system current time.What library call can I use ?
There is, to my knowledge, no library call that will do this. And, we
can’t really write/supply one as part of our library. Our libraries
are differentiated on a CPU-type basis (PPC-BE, ARM-LE, etc), whereas
the hardware clock differs on a per-board basis, so we can’t supply an
ARM library routine that is able to get this information.
You might be able to look at the code in startup for your board, it
might be in init_qtime() or something similar, which reads the hardware
clock at startup, then write your own function to do this after boot.
It will not be able to be exactly the same code, as the code will be
running in quite a different environment in a process from when it
is running in startup.
Once you have system time, and hardware time, I would recommend using
ClockAdjust() to re-synchronise.
Though, if the drift is too extreme, it may actually mean that the
system is mis-configured in startup for what the actual underlying
timer interrupt frequency/resolution is on your machine.
David Gibbs
QNX Training Services
dagibbs@qnx.com