From: Joerg Hansmann (info_at_jhansmann.de)
Date: 2001-08-08 22:53:44
Hi Rob ,
----- Original Message -----
From: Rob Sacks <editor_at_realization.org>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Wednesday, August 08, 2001 5:51 PM
Subject: Re: [buildcheapeeg] comADC-EEG
> Hi Joerg,
>
> > However I am not sure about interrupt latency
> > time in a windows 98 system.
> > If it is constant and / or below 1us it would be ok.
>
> According to Microsoft the interrupt latency under
> NT in 1995 was 1.8 - 2.9 usec. I can't find any
> other published results. (I've looked before for
> this info.)
Probably today with faster machine latency time
will be half of it. That is promising...
> > > Could you evaluate if it could respond in 1us ?
>
> It would probably be a lot of work for me because
> I've never written a device driver for Windows.
>
> > The counter loop is a small problem compared
> > with getting synced on the begin of the pulse.
>
> What if the hardware generates an interrupt
> 5 usec before the pulse
That will not be needed since I redesigend
the hardware so that the timer is triggered
by the PC software.
> and 5 usec before the
> end of the pulse?
Before the end is bad, because I would need
a second comparator.
However after the end would be relatively easy
and would do the job also .
>Each time, the interrupt
> handler is invoked and begins polling. It polls
> until the actual event (start or end of pulse).
> Then it records the system time (measured in
> .8 usec units) in a buffer and goes to sleep. That
> way we'd only need to disable interrupts for a
> few usec. This would bring the total resolution
> to 1.6 usec, wouldn't it?
Yes. With the above mentioned trigger technic,
the first 0.8usec inaccuracy could be eliminated.
So the total resolution would be 0.8 usec.
That would be enough for 10 bit.
However the small polling loop at the pulse end
would decrease resolution to about 8 bit
because port-polling is incredible slow.
(at least on my pc one "in" op-code needs about
4 usec)
If latency on present-day machines is 1usec,
the polling loop would be superfluous.
> > Now a hi-speed timer (also available under Windows ?)
> > can generate whatever sampling clock is desired.
> > ( <= 512Hz should be possible )
>
> The timer for scheduling (invoking code) uses
> intervals that are integral numbers of milliseconds:
> 1 ms, 2 ms, 3 ms, etc. = 1000 Hz, 500 Hz, etc.
> The max resolution is 1 ms. I posted test results
> yesterday showing the accuracy of it.
Where did you post the results ?
> There's also a "counter" for measuring intervals.
> On Intel CPUs the resolution is .8 usec.
That is the old PIT timer counter.
On Pentium class machines (and Athlon ) something much
better exists:
A 64 bit counter clocked with the internal CPU speed.
This counter can be read with the
RDTSC opcode (see appendix).
On my 600Mhz Athlon it has a resolution of 1/600Mhz,
(that is 1.66 nano seconds)
(Again thanks to JBilderback who provided this info)
Regards,
Joerg
-------------------------------------------------------------------------------------
__int64 get_cpu_clock()
{
__int64 retval;
unsigned long high_buf;
unsigned long low_buf;
_asm{
push eax
push edx
rdtsc
mov high_buf, edx
mov low_buf, eax
pop eax
pop edx
}
return retval = ((__int64)(high_buf))<<32 | ((__int64)(low_buf));
}
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:32 BST