msg from the front
2004-02-07 by drmabuce
Hi All,
The PSIM will soon be at large among it's user base. I
enjoyed a rather exclusive privilege in getting an early opportunity
to explore it's capabilities. Little by little now, more of you
folks will face the same blank canvas that I have over the last
month. So here are my very personal and particular tips.
Before I expound on this I want to clarify that the PSIM is a
hybrid device and resultantly, there are two lines of responsibility:
Hardware & Software. Brice, aka Synthmodules.com covered the hardware
implementation of the microprocessor. His gadgetry turns the buzzing
1's and 0's into smooth CV's and vice versa .
In the OTHER realm, Basicmicro's Atompro24 is what
you're talkin' to on that screen,; The Software. So , for
example, if the FOR/NEXT loop syntax that you learned in college
doesn't work like it `should' in your humble opinion.
There's nothing that Brice or any body but you can do about it.
Overall, my experience with the PSIM system boils down this
way:
So far, there is no wiggle, leap, or fancy gesture in the
sub-audio (control voltage) realm at which the software balksÂ…IF
you take the time to work within the idiosyncrasies of the
AtomPro's BASIC syntax.
The key resource here is time. I develop ERP and industrial
process control software in BASIC (and other languages) for my
livelihood. That is not necessarily an advantage. If you already
`know' BASIC, keep in mind that what you know is what creates
blind spots. This blind spot is the basis for my first tip:
1) RADICAL MODULARITY.
DEVELOP IN RIDICULOUSLY TINY CHUNKS
And thoroughly test them as you go. Thus, your early
developments will be frustratingly slow , painstaking, elementary and
UNspectacular, just when your enthusiasm for the new toy is highest.
Live With It! Assembling a `toolbox' of PROVEN modular
routines early on in the game will make your life positively
luxurious later! The alternative is a miasmic debugging quagmire. I
learned the hard way that debugging a tiny `primitive'
routine is INFINITELY preferable to stepping through a gigantic
flawed `masterpiece' of straight-line MBASIC code.
2) IF/ THEN IS QUIRKY BUT MAKES UP FOR IT BY BEING FAST
Or
LONG SECTIONS OF SOURCE CODE DON'T NECESSARILY RUN
SLOWER THAN SHORT ONES
I'll open with an example:
IF VAR1 >= VAR2 THEN VAR3 = VAR3 + 32
Does not seem to work as reliably as:
IF VAR1 >= VAR2 THEN
VAR3 = VAR3 + 32
ENDIF
I don't understand why and I don't care because the
latter form runs completely reliably and as far as I can hear, just
as fast. This illustrates the subtle point that in a compiled &
tokenized BASIC environment, verbose code does not run slower that
terse code. So there! Style Nazi's!
This is not a RULE, it's a guideline and I have gotten
along perfectly well so far using only my ears to tell me if my code
is running fast enough. Grant Richter did us all the immense service
of tweezing the fat out of a set of fundamental I/O routines
(LOADALLDACS & SCANADC) if your code is stammering undesirably, rest
assured that your calls to those routines are not at fault. Grant
used a well-calibrated scope to `photofinish' the horse-race
among various I/O routines. After that, in the control-voltage realm,
My ears have been sufficient to tell me when a routine needs to be
faster.
Here are the guidelines I'm using based on my
observations so far:
- IF/THEN/ELSE/ENDIF is just as fast as homemade GOTO
branching
-GOSUBS are slower than `in-line' or GOTO transfers
of control
-FOR/NEXT /STEP loops are just as fast as homemade GOTO loops
-DO/WHILE loops are no faster than FOR/NEXT/STEP loops
-assignments, ie DAC1V = VAR1 are VERY fast, don't avoid them.
Which introduces the next tip
3) DON'T USE THE DACxV VARIABLES TO TRANSPORT DATA BACK FROM
LOADALLDACS.
There are 4 `standard defined' variables in my code (DAC1V,
DAC2V, DAC3V & DAC4V) that you load and send down to LOADALLDACS with
the number that you want squirted out of the the 4 CV outputs. Thanks
to some thorough experimentation on Brice's part, it is
discovered that DACxV gets mangled by LOADALLDACS. So the rule of
thumb is that you should use your own `private' variables to
ferry data among the sections of your code because loading data into
DACxV is a ONE WAY trip down to LOADALLDACS.
In concrete terms, this works:
VAR1 = VAR1 + VAR2
DAC1V = VAR1
GOSUB LOADALLDACS
IF VAR1 > 4095 THEN
VAR1 = 0
GOTO MAINLOOP
ENDIF
And this doesn't work
DAC1V = DAC1V + VAR2
GOSUB LOADALLDACS
IF DAC1V > 4095 THEN
DAC1V =0
GOTO MAINLOOP
ENDIF
And, to boot, the longer first form does not create any audible
latency
The next tip concerns the PC software rather than the code itself:
4) NEVER EVER EVER PUSH THE `PROGRAM' BUTTON WITH MORE THAN
ONE WINDOW OF CODE OPEN IN THE EDITOR OR ON AN EDITED COPY OF THE CODE
The procedure I've adopted is cumbersome but it is the only one
that has proven reliable:
Open ONE program (.bas file) into the editor
Work on it
SAVE AS to ENSURE that you are overwriting your previous version
(or a new version if you elect to change the name)
CLOSE the just-saved program out of the edit window and make
sure that the edit window is EMPTY
RE-OPEN your just-saved program
Then push the PROGRAM button to flush it into the AtomPro
The important part is that NO editing be done between the
(re-)OPEN step and the PROGRAM step.
I learned the hard way that, if you so much as touch a comment line
between opening and programming a piece of code , there is no
guarantee that you will not be running the previous , un-edited,
version on the PSIM. For those of you with experience, I don't
have to explain what catastrophe results from debugging a version (or
build) of the code that is NOT the one ACTUALLY running. (shudder!)
I realize that the procedure I'm recommending is overkill but
after you spend 8 hours `debugging' some thing that already
works because you forgot to clear the edit buffer before sending it
down to the PSIM, I feel certain that the added 20 seconds per
version will seem less intrusive
Those are my best tips so far.
I want to add that now that I have my sea legs with this platform, I
am still impressed with the UN-flakiness of it's execution . Once
a well-formed piece of code (hint hint) gets into the PSIM. The
hardware enters the Timex watch/Energizer Bunny (tm,tm) class of
robust performance. That is a solid achievement in my experience with
hybrid analog synth devices.
I look forward to seeing where other, more enlightened, folks take
this gadget and learning from them.
Best wishes,
-doc
(the foregoing statement is the lofty, polite way of saying that,
like all `professional' programmers in an open source realm,
I look forward to stealing the code that someone else sweat blood
debuggingÂ….
AVAST THERE!!!! YE SCURVY DOGS AND PUT YER PRETTIES ON THE DECK! OR
DO WE HAVE TO REMOVE YER HEADS TO FACILITATE THE TAKIN'????)
(arrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr)