Mail Archives: djgpp/1998/08/24/11:01:53
In artikel <35df0db3 DOT 0 AT news DOT uni-ulm DOT de>,
On 22 Aug 1998 20:28:03 +0100, bgleich AT blitz DOT chemie DOT uni-ulm DOT de
(Bernhard Gleich) wrote:
>Hi all.
>
>Mayby someone can suggest a smart solution to the following problem:
>
>I am doing some data aquisition and real time processing using DJGPP
>and ALLEGRO. Most time, my real time restrictions are not that tight
>and I have plenty of time to do the data displaying and storing
>things. But some time I have to react very fast to an event. I can
>predict this event to about 0.01s accuracy if it is still a long time
>to go. (If I am close to the event, the accuracy of prediction becomes
>better.) If the data, which indicate the event, are read, the program
>should react within 1e-4 seconds (faster is better).
>
>My solution now is to call a function that estimates how long it will
>take to the event. If it is close it waits for the event and reacts to
>it. Naturally this function has to be be called often enough which
>becomes very painful in a still growing program.
>
>A better solution would be to call this function by a timer
>interrupt. There is only one problem. As the function waits a not
>known time, some interrupts might be lost. So I could no more rely on
>the clock.
>
>Is there some easy solution for my problem, like counting the lost
>interrupts by the dely routine and adding them afterwards to system
>clock.
>
>Some solution without reprograming the timer chip myself would be
>prefered.
>
Why can't you use the input interrupts?
--
mvh.
Søren
Some random US email addresses: senator AT hutchison DOT senate DOT gov
sam DOT tx03 AT mail DOT house DOT gov rhundt AT fcc DOT gov jquello AT fcc DOT gov
sness AT fcc DOT gov rchong AT fcc DOT gov uce AT ftc DOT gov abuse AT localhost
- Raw text -