From: Joerg Hansmann (info_at_jhansmann.de)
Date: 2001-08-09 11:24:42
Hi Rob ,
----- Original Message -----
From: Rob Sacks <editor_at_realization.org>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Thursday, August 09, 2001 10:45 AM
Subject: Re: [buildcheapeeg] comADC-EEG
> Hi Joerg,
>
> > That will not be needed since I redesigend
> > the hardware so that the timer is triggered
> > by the PC software.
>
> Great idea. Does your clock still control
> the time when the measurement is taken (as
> opposed to when the pulse is generated)?
No. I have removed the 256 Hz clock.
> (Maybe this is a good idea because the
> intervals will be more accurate with your
> clock than the PC -- see timing results below.)
The greatest deviation I see, is about 40usec.
That is 1% jitter at 250 Hz sampling clock.
However I assume we have to use multiples
of 1 ms ?
So we can have 500Hz, 333Hz, 250Hz,
200Hz etc. but no power of 2 frequencies.
But I think that is ok.
>
> > 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.
>
> If the polling loop is eliminated, could you
> expand the length of the pulse duration?
> Doubling the length to a maximum of 2 ms
> would add a bit to the resolution, wouldn't it?
That is right.
...
> But I think, actually, the .8 usec Windows timer is built on
> the RDTSC instruction. Maybe Windows reports the
> result with partial resolution so the units will be uniform
> on all x86 systems? (Windows reports the result as
> a 64-bit number.) If I remember correctly, the old timer
> chip has a maximum resolution of 1/64k second (but I haven't
> done that kind of programming in 15 years so my memory
> is suspect).
The PIT (8253) is clocked with 1.19318 MHz.
The 16-bit divider has been set to 65536 under DOS
and produced the legendary 18.2 Hz
1 / 1.19318 Mhz gives 0.838 usec ... and that is your
.8 usec Windows timer.
I am pretty sure it has nothing to do with RDTSC.
> One comment about the code you attached -- I just
> checked the Intel documentation about RDTSC (I didn't
> know anything about it until you told me). Intel says
> this kind of code should contain a CPUID instruction
> before the RDTSC to force all preceding instructions
> to complete. Otherwise the code can execute out-of-order
> and spoil the timing results.
What does out of order execution mean ? (something with
the pipelines ?)
And why should this be a problem ?
Regards,
Joerg
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:32 BST