Just a nudge about an INCLUDE directive
Harbor
Posts: 73
I've been away from stamps for a couple of years. (Sometimes the call of·real life is too loud to be ignored.) So I may be missing a technique, but a directive to include a file would be a tremendous help when programming the models with banks, like the BS2P. And it would be pretty useful in other situations as well.
I have in mind something like:
#INCLUDE "Var_Declarations.bs2"
at the start of the code for each bank. Having to copy the variable declarations in each time is a very error prone part of development for these models.
I remember looking unsuccessfully for this editor feature the last time I was coding stamps. Has something been developed and I'm just not hitting on the right syntax? I can't find a reference with any of the obvious search terms.
I have in mind something like:
#INCLUDE "Var_Declarations.bs2"
at the start of the code for each bank. Having to copy the variable declarations in each time is a very error prone part of development for these models.
I remember looking unsuccessfully for this editor feature the last time I was coding stamps. Has something been developed and I'm just not hitting on the right syntax? I can't find a reference with any of the obvious search terms.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
Errors arise because the other files already contain some previous form of that file. So even if you use strict discipline to never edit declarations in a code file, and always go to that special text file, it is easy to forget to paste the revised form into each of the code files in turn. And when you do, no error message appears in most cases.
Suppose for example you changed a nibble variable to a byte and you remember to paste the revised declaration file into four of your other code files, but not two of them. Those two will continue to treat the variable as a nibble, with the subtle errors and odd symptoms you might expect from that discrepancy. They will have the variable declared, so no error will be reported during syntax analysis, but the code will sometimes run and sometimes not, depending on the value actually in the variable at a given time. Not to mention that sometimes the order of declaration will cause one bit of code to overwrite part of another variable entirely because of the size discrepancy.
One way to get bit using this technique, is to develop a set of routines you expect to need --·to drive a particular LCD for example. Then you change your mind about which LCD to use, save the routines in case you need them later, and start working from a new version modified to match the new LCD (or any other part with multiple choices of course). Later still in the project, you decide (or often the revealed requirements they never tell you about at the beginning 'decide') that both LCD's are going to be needed. So you haul up those routines, check them quickly, and they compile. Great! And they seem to run fine. But in that time those routines were out of the project, you were debugging late one night and had to change an array of 7 bytes to one of 8 bytes. Or vice versa. You remembered to change all the code files that are part of the project, but now you've retrieved some code you thought was no longer needed.·And you were so tired, you forgot to log that change anywhere. Those old routines still have that old version of the declarations. And they usually run, but...
Very nasty problems to diagnose when you're doing it that way. Much safer to let·the compiler 'include' a common file for you.·I try to remember to periodically go back and re-copy the text file into each of the other code files on general principles, but this isn't easily remembered in the heat of development, especially since it is a habit needed only with Basic Stamps.
Certainly the answer is "don't make that mistake" but that's the answer to all coding errors. Not to mention design errors and so forth. We try to make our tools so they decrease the likelihood of error, because Heaven knows we programmers are a rich source of them. Errors, that is.
In any case, this isn't a major complaint. The Basic Stamp tools are excellent. But it would be nice to have this on the "nice to have" list if it isn't already.
Post Edited (Harbor) : 6/3/2006 2:24:51 AM GMT
Sorry, but you haven't missed anything, we don't have that feature in the software because it creates a problem for the compiler that is difficult to solve. We haven't disgarded the idea yet, but so far have not found an optimal solution.
Thank you for the suggestion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin
· Sr. Software Engineer
· Parallax, Inc.