Hello
Does anyone know how to read the realtime clock in interrupt handler.
Get_time and qnx_getclock commands hang the computer?
The CPU is 486 so i can’t use the pentiums rtdsc command to read the clock
ticks. Is there some way to read the clock or processor ticks?
Marko
“Marko Mattila” <marko.mattila@hut.fi> wrote in message
news:9r67o2$nre$1@inn.qnx.com…
Hello
Does anyone know how to read the realtime clock in interrupt handler.
Get_time and qnx_getclock commands hang the computer?The CPU is 486 so i can’t use the pentiums rtdsc command to read the clock
ticks. Is there some way to read the clock or processor ticks?time_t __far timep; / fast grab at time */
struct _osinfo osdata;
if(qnx_osinfo(0, &osdata) == -1) {
perror(“osinfo”);
return -1;
}
timep = MK_FP(osdata.timesel, offsetof(struct _timesel, seconds));
You can get offset into various element of _timesel as well, nsec for
example.
These are incremented by the kernel, hence they won’t increment inside an
interrupt.
struct _timesel is defined in /usr/include/sys/osinfo.h
Marko
Mario Charest <mcharest@clipzinformatic.com> wrote:
“Marko Mattila” <> marko.mattila@hut.fi> > wrote in message
news:9r67o2$nre$> 1@inn.qnx.com> …
HelloDoes anyone know how to read the realtime clock in interrupt handler.
Get_time and qnx_getclock commands hang the computer?The CPU is 486 so i can’t use the pentiums rtdsc command to read the clock
ticks. Is there some way to read the clock or processor ticks?time_t __far timep; / fast grab at time */
struct _osinfo osdata;
if(qnx_osinfo(0, &osdata) == -1) {
perror(“osinfo”);
return -1;
}
timep = MK_FP(osdata.timesel, offsetof(struct _timesel, seconds));
Note: do all the setup to this point before entering the interrupt
handler.
These are incremented by the kernel, hence they won’t increment inside an
interrupt.
Actually, I think they are incremented in a (os attached) interrupt
handler for irq 0 (the timer). This means that they could be
updated inside your interrupt handler, if you are a lower priority
interrupt than interrupt 0.
But, if you’re only reading the 32 bit seconds value, this won’t be
a problem. If you want the seconds & nanoseconds, then people usually
write a loop:
struct _timesel far *timep;
…
do {
tsec = timep->seconds;
tnsec = timep->nsec;
} while ( (tsec == timep->seconds) && (tnsec == timep->nsec) );
QNX Training Services
I do not answer technical questions by email.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:9r6jha$1h3$1@nntp.qnx.com…
Mario Charest <> mcharest@clipzinformatic.com> > wrote:
“Marko Mattila” <> marko.mattila@hut.fi> > wrote in message
news:9r67o2$nre$> 1@inn.qnx.com> …
HelloDoes anyone know how to read the realtime clock in interrupt handler.
Get_time and qnx_getclock commands hang the computer?The CPU is 486 so i can’t use the pentiums rtdsc command to read the
clock
ticks. Is there some way to read the clock or processor ticks?time_t __far timep; / fast grab at time */
struct _osinfo osdata;
if(qnx_osinfo(0, &osdata) == -1) {
perror(“osinfo”);
return -1;
}
timep = MK_FP(osdata.timesel, offsetof(struct _timesel, seconds));
Note: do all the setup to this point before entering the interrupt
handler.
These are incremented by the kernel, hence they won’t increment inside
an
interrupt.Actually, I think they are incremented in a (os attached) interrupt
handler for irq 0 (the timer). This means that they could be
updated inside your interrupt handler, if you are a lower priority
interrupt than interrupt 0.
Only interrupt 1 and 2 (unless you change priority in Proc32 ) are
lower then 0 and these are usually “reserver”. I was trying to express
that you can’t really reliably measure elapse time from within
the interrupt handler itself.
But, if you’re only reading the 32 bit seconds value, this won’t be
a problem. If you want the seconds & nanoseconds, then people usually
write a loop:struct _timesel far *timep;
…
do {
tsec = timep->seconds;
tnsec = timep->nsec;
} while ( (tsec == timep->seconds) && (tnsec == timep->nsec) );-David
QNX Training Services
I do not answer technical questions by email.
Mario Charest <mcharest@voidzinformatic.com> wrote:
Actually, I think they are incremented in a (os attached) interrupt
handler for irq 0 (the timer). This means that they could be
updated inside your interrupt handler, if you are a lower priority
interrupt than interrupt 0.Only interrupt 1 and 2 (unless you change priority in Proc32 ) are
lower then 0 and these are usually “reserver”. I was trying to express
that you can’t really reliably measure elapse time from within
the interrupt handler itself.
ALL of the second-bank of interrupt (9-15) come in at interrupt 2. So,
they’re all lower-priority than interrupt 2. Interrupt 1 is the keyboard,
not reserved per se, but usually used by a keyboard.
QNX Training Services
I do not answer technical questions by email.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:9rc5h5$hkh$1@nntp.qnx.com…
Mario Charest <> mcharest@voidzinformatic.com> > wrote:
Actually, I think they are incremented in a (os attached) interrupt
handler for irq 0 (the timer). This means that they could be
updated inside your interrupt handler, if you are a lower priority
interrupt than interrupt 0.Only interrupt 1 and 2 (unless you change priority in Proc32 ) are
lower then 0 and these are usually “reserver”. I was trying to express
that you can’t really reliably measure elapse time from within
the interrupt handler itself.ALL of the second-bank of interrupt (9-15) come in at interrupt 2. So,
they’re all lower-priority than interrupt 2.
Hum, that’s news to me, I always though priority was set in QNX4 to ,
from high-to low:
3-4-5-6-7-8-9-10-11-12-13-14-15-0-1-2
Interrupt 1 is the keyboard,
not reserved per se, but usually used by a keyboard.
I don’t think it can be shared hence it’s pretty much reserved (on
a standard PC I mean), but I see your point.
-David
QNX Training Services
I do not answer technical questions by email.
Mario Charest <mcharest@voidzinformatic.com> wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:9rc5h5$hkh$> 1@nntp.qnx.com> …
Mario Charest <> mcharest@voidzinformatic.com> > wrote:
Actually, I think they are incremented in a (os attached) interrupt
handler for irq 0 (the timer). This means that they could be
updated inside your interrupt handler, if you are a lower priority
interrupt than interrupt 0.Only interrupt 1 and 2 (unless you change priority in Proc32 ) are
lower then 0 and these are usually “reserver”. I was trying to express
that you can’t really reliably measure elapse time from within
the interrupt handler itself.ALL of the second-bank of interrupt (9-15) come in at interrupt 2. So,
they’re all lower-priority than interrupt 2.Hum, that’s news to me, I always though priority was set in QNX4 to ,
from high-to low:3-4-5-6-7-8-9-10-11-12-13-14-15-0-1-2
You have to remember, it is two chained PICs, and priority can only
be set on the first of them. Then all of the second bank irqs come
in as irq 2 on the first bank.
This means you get:
3-4-5-6-7-0-1-2
|
8-9-10-11-12-13-14-15
If you change which is the highest (e.g. Proc32 -i 0) you would get:
0-1-2-3-4-5-6-7
|
8-9-10-11-12-13-14-15
(And, running irq 0 as highest is not uncommon in order to get more
accurate timing or profiling of who is active.)
Interrupt 1 is the keyboard,
not reserved per se, but usually used by a keyboard.I don’t think it can be shared hence it’s pretty much reserved (on
a standard PC I mean), but I see your point.
On a standard PC, yes. In an embedded solution… you might not have a
keyboard, so why reserve an irq for one?
QNX Training Services
I do not answer technical questions by email.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:9rcaa1$kln$1@nntp.qnx.com…
Mario Charest <> mcharest@voidzinformatic.com> > wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:9rc5h5$hkh$> 1@nntp.qnx.com> …
Mario Charest <> mcharest@voidzinformatic.com> > wrote:
Actually, I think they are incremented in a (os attached) interrupt
handler for irq 0 (the timer). This means that they could be
updated inside your interrupt handler, if you are a lower priority
interrupt than interrupt 0.Only interrupt 1 and 2 (unless you change priority in Proc32 ) are
lower then 0 and these are usually “reserver”. I was trying to
express
that you can’t really reliably measure elapse time from within
the interrupt handler itself.ALL of the second-bank of interrupt (9-15) come in at interrupt 2. So,
they’re all lower-priority than interrupt 2.Hum, that’s news to me, I always though priority was set in QNX4 to ,
from high-to low:3-4-5-6-7-8-9-10-11-12-13-14-15-0-1-2
You have to remember, it is two chained PICs, and priority can only
be set on the first of them. Then all of the second bank irqs come
in as irq 2 on the first bank.This means you get:
3-4-5-6-7-0-1-2
|
8-9-10-11-12-13-14-15If you change which is the highest (e.g. Proc32 -i 0) you would get:
0-1-2-3-4-5-6-7
|
8-9-10-11-12-13-14-15
Ok
On a standard PC, yes. In an embedded solution… you might not have a
keyboard, so why reserve an irq for one?
That make sense indeed, but wouldn’t most chipset have that hardwire?