From: Rob Sacks (editor_at_realization.org)
Date: 2002-01-23 13:36:33
Hi John,
> I agree BUT it wouldn't hurt to start brainstorming. After all
> this is the design stage and we can always add to the design
> before coding begins. :-)
Well, here's how I did it in ElectricGuru. This is the same
way I'd be inclined to do it again.
We learned yesterday that the programmer needs the option
of building either integer or floating point versions, so I would
typedef the numbers that represent microvoltages. I'll use the
word "number" here for their datatype.
Stage 1 maintains queues (one for each channel) with
numbers in consecutive order. Number1, number2,
number3, number4.... as simple as that.
Stage 2 reads the queues.
Synchronization of the numbers across queues is maintained
by flushing the queues periodically (in practice, Stage 2
flushes the queues each time it's called, which is 20 times
a second).
The queues come with iterators so they can be used
several times by various parts of the program before
they are flushed.
Now, I can imagine that synchronization could become a
problem (although it never did in ElectricGuru). In that case,
we could have instead a single queue of a struct that looks
like this:
{
number channel1,
number channel2,
number channel3 ...
}
I can imagine that queues and iterators might seem a
little forbidding to some of the people who might
want to contribute to this code... it would be nice to
make the interfaces between modules so simple and
easy that novice programmers are able to jump in and
fiddle with things.
In that case, we could just provide a function in Stage1
that is called by Stage2:
number get_next_number ( channelX );
This appears to have more overhead than reading queues
but the difference is actually negligible because it can be
implemented inline and at any given time, only a few
values are read.
Stage 1 also provides functions that Stage 2 uses to (1) ask
how many channels are available; (2) ask the range of
values represented by the numbers (might be necessary
for integer versions).
So the whole interface out of Stage 1 could be as simple
as this (I'm forgetting the queues for a moment and thinking
only of making this as easy as possible for novice programmers):
get_channel_quantity ();
get_low_end_of_range ( channelX );
get_high_end_of_range ( channelX );
flush (channelX );
get_next_number (channelX);
(If we try to do the nearly-real-time stuff that
Chuck Davis was talking about yesterday, there
will also have to be a Stage 1 service that the rest of
the program uses to register a function of its
own that Stage1 calls when data comes in, but
that's for later.)
> BTW I'm talking about a multi-treaded program here.
> So stages can work independently!
I wouldn't do that. I think it will make the program
unmanageably complex and buggy. Especially
considering that most people here are probably working
on single-processor machines, so they won't see bugs
that we are creating.
When I wrote ElectricGuru, it was initially multithreaded
and then I changed it to single because it turned out not to
offer any advantages in this context, but it did contribute
the disadvantage of increasing overhead.
Best regards,
Rob
----- Original Message -----
From: John Morrison
To: buildcheapeeg_at_yahoogroups.com
Sent: Wednesday, January 23, 2002 1:56 AM
Subject: RE: [buildcheapeeg] SOFTWARE: Input Stage -> Processing (data Stream)
Before we decide the Stage 1 output format, I'd like to
see the output protocols for more machines including
different types of machines.
I agree but whatever format we use it'll have to take account for all machines so maybe time stamps or at least a header containing
the sampling rate should be added to the DataStream or set up directions....
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST