Re: GNAT R/T Annex and Win95

["Theodore E. Dennison" <dennison@escmail.orl.mmc.com>]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:
> 
>     Well, not quite a "straight NT question." It's related to using
>     Ada & WNT in real-time data acquisition systems. A quality
>     compiler capable of real-time work may be pathetic in behavior if
>     the underlying OS doesn't support what you need to do the job.

I know where you are comming from here, but if it isn't a "straight
NT question", it at least ends up being a straight NT answer. You 
typically don't want to rely on language facilities like the delay
statement (especially the delay statement) in a true real-time 
environment. You HAVE to use OS calls, which are (mostly) language
independent. 

> >The second is the "Multimedia Timer". This timer allows you to define
> >a callback that will get called directly by an interrupt, without any
> >message queue processing overhead. The resolution is said to be
> >"about 16 (Intel) milliseconds". Whatever that means, you can get the
> >exact resolution on your system via a call to "timeGetDevCaps". (Oddly
> >enough, Microsoft's example uses a resolution of 5 milliseconds) This
> >is a little more useful, but still not what we would like to see.
> >
>     That's useful to know about the clock. Would you happen to know if
>     this is the mechanism used by GNAT (or other implementations) for
>     the "delay" statement?

I don't happen to know, but I do know enough about NT to tell you that
that would be HIGHLY unlikley. I'd expect to see a delay on NT use the
SleepEx call to suspend the thread for a given number of milliseconds.

You can't really use "delay" for real-time timing anyway (how do you
account for processing time between delay statements?) You need
something that iterrupts you at a given, reliable interval no matter
what other processing you are doing.

>     I think that one of our biggest concerns is not necessarily clock
>     resolution, but more one of behavior in a non-dedicated
>     environment. Some of our systems run stand-alone and in such a
>     case you can generally make things work because there won't be any
>     suprises. But in other systems, we may be collecting data in
>     real-time from an engine test and an operator might be using the

It looks like a multimedia timer iterrupt actually puts the rest of the
OS on hold to call your interrupt callback (my manual isn't real 
specific about this). So no matter what priority your process/thread is,
your ISR will get called at the specified interval. The manual warns 
about degragated system performance when using small intervals.

The other option, I guess, would be to set up a timer, and jack up the
priority of the process that services its message queue to real-time.
This solution isn't hard real-time, but does prevent your servicing 
thread from having the CPU witheld when its needs it.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |