You can 'condense' variable use by using a 'Temp' variable, and writing the results of the 'Temp' variable to an external EEPROM. If you attach your code, we may be able to show you some tweaks.
·Here is the code. The extra· variable will be for the gyro. And I still need to take three at rest readings from the accelerometer and save the avereage at data location 1.
Very nice code. 278 lines, nicely structured into subroutines. A 'syntax check' followed by a 'memory map' shows you have 3 full words (plus 15 bits) of RAM left, and more than half of the eeprom space left. And it looks like you already 'reuse' variables like 'n' as a loop counter.
Good use of 'CON' parameters too. And it looks like you're using an external EEPROM, well done.
Now, to the problems.
1. Your 'main' routine, such as it is (lines 48 to 73) does not 'end' (or loop) instead your code runs off the end and winds up in WriteEEPROM -- probably not what you want. I'm not sure what you DO want there -- a 'STOP'? A really long 'PAUSE'? an END?
2. It looks like "WriteEEPROM" tries to do a recursive call if EEPROM_Busy is true. The BS2 will do recursion, but only has an 8-call deep stack, so recursion will quickly cause problems. Also, the BS2 has NO 'local' variables, which limits how useful recursion could be. A 'WHILE' loop, calling "EEPROMreadstatus", would be more appropriate here.
3. SerialControl -- Line 137 and 138 -- the "IF" statements create an implied "GOTO". You can put in an explicit "GOSUB", which is probably what you want. Again, it looks like if there's a time-out, you try to do a recursive call, which is probably not what you want. Replace that line with a "GOTO SerialControl" would be better. And do you want to 'RETURN' from this call? If so, it's missing a RETURN statement.
4. I wouldn't name a subroutine "begin" or "ENDD" -- "StartTxfer" and "EndTxfer", or something like that, would be better. There's too much risk "Begin" would be a valid keyword in the future. Besides, it's ambiguous -- begin what?
Quite frankly, I did not expect such high quality code. It looks like you're already doing most of the 'best practices' for limiting your use of RAM variable space -- reuse variables, don't make variables bigger than they need to be. There's not a lot of variable use compression that you haven't already done.
From a Software Engineering perspective, Basic has a tendency toward "spaghetti code", where you GOTO all over the place. Good use of the GOSUB and RETURN tends to control this. And most of the time, you've made good use of the GOSUB and RETURN, but there's a few places you've either accidentally or intentionally left out a RETURN (wanting the 'fall-through', I guess, it's not clear from the code). And a few places you're using the default "GOTO" after the IF...THEN, where a "GOSUB" would be better.
And you'll need to replace any recursion you tried to use with a 'while' loop -- but these can be on 'bit' variables, so that shouldn't be a problem.
Your at-rest accellerometer readings can be written to the internal eeprom (using 4 locations -- Sum--Average, Reading1, Reading2, Reading3), and averaged from there with two variables.
So it looks like you're almost there. Good luck.
P.S. Oh, and note that it's not a limit of 26 variables.· It's a limit of 26 Bytes of RAM space.· You can divide that RAM space into any mixture of Words, Bytes, Nibbles and BITS.· So you've got 3 full WORDS (or 6 Bytes) left.· Click the little "check" button at the top of the IDE, then click the "percent" button.· This will give you a memory map of your compiled program, as·the IDE will load it into your BS2.
The "Ram Map" to the right is the amount of RAM space you've got allocated.
Post Edited (allanlane5) : 4/20/2006 10:01:47 PM GMT
Nice reply, allanlane5 ! I learned from that as well, as I use similar code ( especially the EEPROM stuff ) for my project.
Thats nice coding as well, Mike - A few things I can use there to improve mine!
I am far from understanding everything about coding, Mike - but I feel your pain, running all the sensors ( as I do too) can eat up variable space rather quick, with one or more Word-sized values for each sensor, plus the EEPROM. BTW, I learned from your code as well, as I didnt know you could Read/Write more than one value at the same time to memory! I use pretty much the same code to read/write my 25LC640, but did not see the obvious. Its great when others post code, as we all seem to look at problems differently - sure can be helpful!
Anyways, with the programming I did for my CanSat, I found that it is a trade-off. I used alot of temp variables with the same name without trying to keep the names functional ( adcin,MPX, ect). Made my code very hard to read, but I am the only one that really needs to read. I also wrote the original with better naming of variables to refer to if I forgot what all those temps were for in a particular line of code! Only thing I noticed is that my actual code grew, because I had to make sure that nothing was being written to all these similar variable names that I didnt want written ( assigned?). The trade -off for me was I used more BS2 EEPROM space to store code, but less variables Was a tricky balance , but I managed to get my CanSat programmed to read out and display GPS data, DS1620 temp, MPX4115 pressure, DS1302 RTC data (for time stamp), MEMSIC 2125 G and Tilt, plus write all the data to EEPROM. Still have barely enough space to add my RF, as soon as I figure out theses AeroComm modules. I need to also learn how to (if I understand correctly) store values (constants?) on external memory ( either external EEPROM, or perhaps the 1302 scratchpad) and that would probably leave me with a bit more space.
If you have 3 full Words left, plus half thr PROM, thats quite a bit to work with. Be creative
Alohas
Post Edited (Robert@HCC) : 4/21/2006 1:42:35 AM GMT
Still not sure how I can average with just two variables
"Your at-rest accellerometer readings can be written to the internal eeprom (using 4 locations -- Sum--Average, Reading1, Reading2, Reading3), and averaged from there with two variables."
While YOU may believe that "you are the only one that needs to read it", this forum has quite a few messages from people trying to deal with exactly that thought from the last programmer on their project (plus, as you so astutely pointed out, it is sometimes far more valuable to see how others are accomplishing something than to "grok the doc"...so why make it difficult for the rest of us? <g>)
Also, you might not be aware that "aliasing" variables does not take up any more space in the tokenized code, so that may be a solution to your variable reuse and later understanding of it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
' Note, you're using the on-module EEPROM to do this, so you don't want
' to do this very often -- you only get a million writes to each EEPROM location before
' that location won't accept data anymore.
Another approach would be to assign one WORD to keep a running average, and avoid the EEPROM use except for the total
Mike15
Posts: 109
Comments
Thanks,
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dave Andreae
Tech Support
dandreae@parallax.com
Http://www.parallax.com
·
I have used constants where ever possable.
And thanks for the help.
Good use of 'CON' parameters too. And it looks like you're using an external EEPROM, well done.
Now, to the problems.
1. Your 'main' routine, such as it is (lines 48 to 73) does not 'end' (or loop) instead your code runs off the end and winds up in WriteEEPROM -- probably not what you want. I'm not sure what you DO want there -- a 'STOP'? A really long 'PAUSE'? an END?
2. It looks like "WriteEEPROM" tries to do a recursive call if EEPROM_Busy is true. The BS2 will do recursion, but only has an 8-call deep stack, so recursion will quickly cause problems. Also, the BS2 has NO 'local' variables, which limits how useful recursion could be. A 'WHILE' loop, calling "EEPROMreadstatus", would be more appropriate here.
3. SerialControl -- Line 137 and 138 -- the "IF" statements create an implied "GOTO". You can put in an explicit "GOSUB", which is probably what you want. Again, it looks like if there's a time-out, you try to do a recursive call, which is probably not what you want. Replace that line with a "GOTO SerialControl" would be better. And do you want to 'RETURN' from this call? If so, it's missing a RETURN statement.
4. I wouldn't name a subroutine "begin" or "ENDD" -- "StartTxfer" and "EndTxfer", or something like that, would be better. There's too much risk "Begin" would be a valid keyword in the future. Besides, it's ambiguous -- begin what?
Quite frankly, I did not expect such high quality code. It looks like you're already doing most of the 'best practices' for limiting your use of RAM variable space -- reuse variables, don't make variables bigger than they need to be. There's not a lot of variable use compression that you haven't already done.
From a Software Engineering perspective, Basic has a tendency toward "spaghetti code", where you GOTO all over the place. Good use of the GOSUB and RETURN tends to control this. And most of the time, you've made good use of the GOSUB and RETURN, but there's a few places you've either accidentally or intentionally left out a RETURN (wanting the 'fall-through', I guess, it's not clear from the code). And a few places you're using the default "GOTO" after the IF...THEN, where a "GOSUB" would be better.
And you'll need to replace any recursion you tried to use with a 'while' loop -- but these can be on 'bit' variables, so that shouldn't be a problem.
Your at-rest accellerometer readings can be written to the internal eeprom (using 4 locations -- Sum--Average, Reading1, Reading2, Reading3), and averaged from there with two variables.
So it looks like you're almost there. Good luck.
P.S. Oh, and note that it's not a limit of 26 variables.· It's a limit of 26 Bytes of RAM space.· You can divide that RAM space into any mixture of Words, Bytes, Nibbles and BITS.· So you've got 3 full WORDS (or 6 Bytes) left.· Click the little "check" button at the top of the IDE, then click the "percent" button.· This will give you a memory map of your compiled program, as·the IDE will load it into your BS2.
The "Ram Map" to the right is the amount of RAM space you've got allocated.
Post Edited (allanlane5) : 4/20/2006 10:01:47 PM GMT
Thats nice coding as well, Mike - A few things I can use there to improve mine!
I am far from understanding everything about coding, Mike - but I feel your pain, running all the sensors ( as I do too) can eat up variable space rather quick, with one or more Word-sized values for each sensor, plus the EEPROM. BTW, I learned from your code as well, as I didnt know you could Read/Write more than one value at the same time to memory! I use pretty much the same code to read/write my 25LC640, but did not see the obvious. Its great when others post code, as we all seem to look at problems differently - sure can be helpful!
Anyways, with the programming I did for my CanSat, I found that it is a trade-off. I used alot of temp variables with the same name without trying to keep the names functional ( adcin,MPX, ect). Made my code very hard to read, but I am the only one that really needs to read. I also wrote the original with better naming of variables to refer to if I forgot what all those temps were for in a particular line of code! Only thing I noticed is that my actual code grew, because I had to make sure that nothing was being written to all these similar variable names that I didnt want written ( assigned?). The trade -off for me was I used more BS2 EEPROM space to store code, but less variables Was a tricky balance , but I managed to get my CanSat programmed to read out and display GPS data, DS1620 temp, MPX4115 pressure, DS1302 RTC data (for time stamp), MEMSIC 2125 G and Tilt, plus write all the data to EEPROM. Still have barely enough space to add my RF, as soon as I figure out theses AeroComm modules. I need to also learn how to (if I understand correctly) store values (constants?) on external memory ( either external EEPROM, or perhaps the 1302 scratchpad) and that would probably leave me with a bit more space.
If you have 3 full Words left, plus half thr PROM, thats quite a bit to work with. Be creative
Alohas
Post Edited (Robert@HCC) : 4/21/2006 1:42:35 AM GMT
"Your at-rest accellerometer readings can be written to the internal eeprom (using 4 locations -- Sum--Average, Reading1, Reading2, Reading3), and averaged from there with two variables."
Could some one show me an example?
Two small thoughts on your post...
While YOU may believe that "you are the only one that needs to read it", this forum has quite a few messages from people trying to deal with exactly that thought from the last programmer on their project (plus, as you so astutely pointed out, it is sometimes far more valuable to see how others are accomplishing something than to "grok the doc"...so why make it difficult for the rest of us? <g>)
Also, you might not be aware that "aliasing" variables does not take up any more space in the tokenized code, so that may be a solution to your variable reuse and later understanding of it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
TempWord2 VAR WORD
AverageAccel:
READ 2, TempWord2.LowByte
READ 3, TempWord2.HighByte
READ 4, TempWord1.LowByte
READ 5, TempWord1.HightByte
TempWord2 = TempWord2 + TempWord1
READ 6, TempWord1.LowByte
READ 7, TempWord1.HighByte
TempWord2 = TempWord2 + TempWord1
TempWord2 = TempWord2 / 3
Write 0, TempWord2.LowByte
Write 1, TempWord2.HighByte
RETURN
' Note, you're using the on-module EEPROM to do this, so you don't want
' to do this very often -- you only get a million writes to each EEPROM location before
' that location won't accept data anymore.
Another approach would be to assign one WORD to keep a running average, and avoid the EEPROM use except for the total
READ 2, Word tempWord2
READ 4, Word tempWord1
...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax