Date: Mon, 31 Aug 1998 12:37:51 +0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com, "Alexander S. Aganichev" <asa AT lan DOT eed DOT miee DOT ru>
Subject: Re: uclock ()
In-Reply-To: <Pine.SUN.3.91.980831123101.22974d-100000@is>
Message-ID: <Pine.A32.3.91.980831123213.41874A-100000@ieva01.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk



On Mon, 31 Aug 1998, Eli Zaretskii wrote:

> 
> On Mon, 31 Aug 1998, Andris Pavenis wrote:
> 
> > There is no other way if one does not want to introduce compatibility 
> > problems. If somebody else will try to read PIC timer counter at the same
> > time (one process is interrupted in the middle of reading and the second
> > is doing the same reading) PIC timer will be messed up.
> 
> I think that's why `uclock' keeps reading the timer output until the 
> results are consistent.
> 

It's enough to mess PIC up and the results will be wrong for next 
readings (up to rebooting or some other messing up will recync 
input)

I have experience running TSR which reads channel 0 counter from PIC
(measuring time when IRQ handler is invoked) and user program simultaneusly 
that does the reading PIC counter for other timing task (joystick).
Failing to disable interrupts when reading timer causes further 
values read from PIC to be wrong.

Andris