From: Rob Sacks (editor_at_realization.org)
Date: 2002-01-22 18:09:54
Hi Chuck,
> Ugh! :( But is that realtime, or is that polling?
It's not realtime. I guess you could call it a kind of
polling -- the application is polling a buffer maintained
by the operating system. But the port itself doesn't
get polled... the port itself gets read after each byte
arrives by the operating system's interrupt handler.
> Does this happen on the receipt of each character?
The operating system reads the port after receipt of
each character, but that has no connection to the timing
of anything in the application.
The application gets invoked at some periodic
rate specified by the programmer at compile time. I
think I have it set for 20 times a second. So 20 times
a second (the rate will not be superduper accurate
because there are variable latencies because this is
a multitasking operating system) my program wakes
up, looks in the buffer, and scoops out all the bytes
that arrived since last time it woke up. At a sampling
rate of 128 Hz, and an invocation rate of 20 Hz, on
average, my program will find 6 or 7 new bytes to
process on each timeslice.
By the way, it's possible to get much closer to realtime
with Windows than this ... but for purposes of this
program, this general plan seemed adequate.
> My segmented recursive DFT, in the ROSHI(AVS) software,
> operates on every sample, therefore, all operations,
> DSP and photo/magstim operate at 8 millisec; *brainstem* speeds :)
So you can tolerate up to 8 milliseconds between arrival
of a sample at the port and sending the signal to flash
the light? I think Windows could handle that easily,
even without any fancy stuff like the VxD's we talked
about last year.
Regards,
Rob
----- Original Message -----
From: "Chuck Davis" <roshicorp_at_roshi.com>
To: "Rob Sacks" <buildcheapeeg_at_yahoogroups.com>
Sent: Tuesday, January 22, 2002 1:52 AM
Subject: Re: [buildcheapeeg] ElectricGuru
> On 21-Jan-02, Rob Sacks, wrote:
> >Hi Chuck,
>
> >Well, actually, my program doesn't see the serial port
> >at all. It relies on Windows to read the port and put
> >incoming data in a buffer.
>
> Ugh! :( But is that realtime, or is that polling?
>
> > Later, at some unrelated time, Windows invokes
> >my program with a service called the multimedia timer,
> >and my program takes data out of the buffer.
>
> Does this happen on the receipt of each character?
>
> >I'm curious though... what's the maximum latency
> >that your stim signal requires? In other words,
> >how quickly does the CPU have to respond to
> >the signal at the serial port to make the stim
> >work?
>
> ROSHI responds to each and every byte that appears
> at the input buffer, separately; 128 sps.
>
> My segmented recursive DFT, in the ROSHI(AVS) software,
> operates on every sample, therefore, all operations,
> DSP and photo/magstim operate at 8 millisec; *brainstem* speeds :)
>
> >Best regards,
>
> >Rob
>
> /ChuckD....
>
> >----- Original Message -----
> >From: "Chuck Davis" <roshicorp_at_roshi.com>
> >To: "Rob Sacks" <buildcheapeeg_at_yahoogroups.com>
> >Sent: Monday, January 21, 2002 6:53 AM
> >Subject: Re: [buildcheapeeg] ElectricGuru
>
>
> >> Rob,
> >>
> >> This makes for good reading; that you modeled your serial
> >> communications after th HAL4. Kewl :) That means that your
> >> software can read the ROSHI(AVS) EEG frontend, while doing
> >> Roshi's EEG coupled magstim/photostim, at the same time.
> >>
> >> The only thing you will need to add is to set RTS, as I use
> >> that line to power the serial stuff.
> >>
> >> BTW, are you running those interrupts thru windoughs?
> >>
> >> /ChuckD....
> >>
>
> --
> .-. .-.
> / \ .-. .-. / \
> / \ / \ .-. _ .-. / \ / \
> -/--Chuck Davis -/-----\-----/---\---/-\---/---\-----/-----\-------/-------\
> RoshiCorp_at_ROSHI.com \ / \_/ `-' \ / \ /
> \ / `-' #11-9-01# `-' \ /
> `-' `-'
> On a Path to Peace of Mind...
>
>
>
> To unsubscribe from this group, send an email to:
> buildcheapeeg-unsubscribe_at_egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:36 BST