That may be all we can hope for: a cut & paste library of pre-written
useful stuff with some standards so people don't get too confused.
So, just to start the conversation, I vote to keep the main loop as
small as possible through the use of subroutines and functions. Don't
use goto if you can avoid it. I realize the performance issues here,
but unless it is absolutely clear that the stack overhead is hindering
an algorithm, I suggest modularity. Both for readability and
standardization purposes.
I'm ducking now, so fire away...
Mike
--- In
ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@...>
wrote:
>
> Good point. It would be an excellent opportunity to talk about
> libraries and such. Alas, I had the same experience with include as
> I did with C. I can't get it to work. I've tried it all sorts of
> different ways. I've posted help on the forums. I don't know
> anyone that ever got it to work. As such, all my programs are
> monoliths. I do have a template that I start with but then when I
> upgrade code I only sometimes retrofit it back into previous
> programs.
>
> Certainly we should define some fundamental subroutines and variable
> names. I've put a lot of utility routines in my template. For
> example, with the display I've written routines for byte to 3
> character ASCII (e.g. with leading 0's), degrees to 3 character
> ASCII, byte to SpeakJet, input averaging, etc.
>
> If interested, I can generate a list of my 'useful' subroutines.
>
> Dave
>
> --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> <michaelmarsh@> wrote:
> >
> > Hi All -
> >
> > We have been discussing the hardware architecture to some detail
> here
> > (which is good) but what about the a software
> > architecture/framework/toolkit? A good standard in this area will
> > facilitate code exchange and get stuff up quickly.
> >
> > Mike
> >
>