From: "drmabuce" Date: Sat Feb 7, 2004 2:45 pm Subject: msg from the front 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)