From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-01-23 14:36:09
> > 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.
For the software though we will have to decide on which to use from the
output of stage 1 on.
Otherwise Stage 2 would have to be written to handle both. :-(
> 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);
I think this would be the best as ANYONE would be able to use it and write
Stage 2 modules that use it.
> (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.)
This maybe another way of looking at it.
Stage 2 module(s) that want data from a stage 1 module register with that
module then wait for data.
This would eliminate LOOPS waiting for data from stage 1.
> > 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.
What I was thinking is that the multi-threading would built in as part of
the code/libraries that run each stage.
So unless the programmer wants to add their own multi threading for some
reason they shouldn't have to worry.
> 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.
With a single threaded program you really need to have a path through the
code. The software we are designing will have "plug in" modules that we
haven't even thought about yet but which the program will need to handle.
We don't' want the user to have to recompile the software after loading a
new module so multi threading is the only way I can see of doing it.
BTW I'm not sure about C/C++ but java handles all of this fairly easily. :-)
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST