Re: [buildcheapeeg] Re: SOFTWARE: Input Stage -> Processing (data Stream)

From: Doug Sutherland (wearable_at_earthlink.net)
Date: 2002-01-24 02:22:35


sleeper75se wrote:

> Moving this functionality to a separate thread introduces
> a middleman that only buffers a buffer ...

Don't spin threads "just because you can" ... :)

I've done quite a bit of multithreaded java programming
(sweet threading model), I think I will try with this
effort too (blackdown java on linux). Both threading and
serial port code is much simplified in java. Grab the
Thread class and make it an RS232 listener, just a few
lines of code, as you say, it's already buffered. Java
might be too slow, but I will give it a whirl. If I were
to avoid (hefty) Swing it might be not too bad.

>> 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. :-)

Multiprocessing doesn't impress me. Soon you'll probably
need that to run winders <grin>. Look at Win2K, the thing
is like a 1GB of code. The real challenge, IMO is not in
making things bigger/faster (hairballs?), it's in making
them smaller and more practical/functional, like in my
pocket, or on my hip. My fastest machine is 233Mhz and it
will stay that way, I'm resisting the idea that I need a
1+ GHz monster. Would be nice for multimedia, but I want
to play around on the low end of hardware. I think that
Atmel AVR is an impressive processor, I'm tempted to try
bolting the EEG right onto a vacuum flourescent display
and a small matrix keypad, I have the parts here. I also
have some cool 8-segment bar-graph LEDs. I wonder if an
AVR would be fast enough to do FFT?

-- Doug



This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST