From: Andris <pavenis AT lanet DOT lv>
Organization: Pavenis
To: djgpp AT delorie DOT com, "Sisco, Michael" <mdsisco AT qtiworld DOT com>
Subject: Re: Fw: uclock() within an interrupt handler
Date: Fri, 13 Sep 2002 17:46:43 +0300
User-Agent: KMail/1.4.7
References: <BDD73AE8AEE3EF438E07420C2600E9F65C913E AT qtiexch0 DOT qgraph DOT com>
In-Reply-To: <BDD73AE8AEE3EF438E07420C2600E9F65C913E@qtiexch0.qgraph.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Disposition: inline
Message-Id: <200209131746.43190.pavenis@lanet.lv>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g8DHiQA01017
Reply-To: djgpp AT delorie DOT com

On Friday 13 September 2002 17:31, Sisco, Michael wrote:
> Has anyone ever tried calling uclock() from inside an interrupt handler?
>
> I have an interrupt handler which (among other things) handles an interrupt
> generated by an encoder used to calculate the speed of a running printing
> press. In order to calculate this speed with any significant accruacy, I
> need the timing resolution of the uclock() function. However, uclock()
> appears to be less than accurate when called within my handler. I have
> timed the frequency of our interrupt handler with an oscilloscope and found
> it to be repeatable to within 0.1%, but the timings I'm calculating using
> uclock() occasionally make very wild fluctuations.

How good accuracy is needed? If microseconds, then perthaps some different
event registration system (perhaps hardware) is needed. 

At least I remember interrupt time jitter (measured with precedure analogous 
with uclock() in interrupt handler in real mode DOS TSR, DJGPP application
was running in foreground and comunicating with that TSR) was up to about 
100-200 microseconds on one 486DX2-66 box. But of course that depends
on hardware...

Andris