From: sleeper75se (sleeper75se_at_yahoo.se)
Date: 2002-01-24 01:48:25
--- In buildcheapeeg_at_yahoogroups.com, "John Morrison" <jmorrison_at_ahc.net.au> wrote:
> BUT we have to allow for ANY interface not only serial ports!
> USB, Infra red, plug in card, etc
That is not a problem either. Windows and Linux (with a non-realtime
kernel) are not real real-time OSes, so all input-channels are
buffered in one way or the other. The communication with various
input-devices and adaptation of the data to the software's internal
structures (a HAL if you like) can be done in just a few lines of
code per device. Moving this functionality to a separate thread
introduces a middleman that only buffers a buffer and does some
translation on top.
> Some processing could lag such as a reward system that averages
data.
Yes, it takes time, but it must still do its job fast enough. The
input buffers provided by the OS should be made large enough so that
no data is lost if the processing on occasion needs more time.
> How about a module that saves the data.
Sure! But the data should perhaps be saved along with other
variables, such as current session parameters, and that is perhaps
better handled by a thread further down the processing chain.
> > Basically, users with slower hardware must settle with less
> > processing. I don't think the requirements will be that severe
> > though, the first systems were designed ten years ago (or
> > something like that) for much slower computers.
> I agree the new computers could handle this with 1 CPU tied behind
> it's back. :-)
Now my computer says it feels old. It has only got one cpu. :-)
Anyway, don't worry about splitting up the data processing into two
threads. If reality shows that it is needed, let's do it! Until then,
let's pretend we don't.
/Andreas
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST