My confusion over variables.

Hugh

The attached code runs as I hoped and intended it would. In my (feeble) efforts to reduce the size of the code I started to delete some of the variables in the VAR section that are no longer referred to in the PUBs. To my surprise, deletion of any one of the VARs against which there are three asterisks in the attached code results in the code stopping working - it compiles, loads and partially executes and then stops.

I have searched for these and am sure they are not being used in the code - should they / could they be having such an effect when they are deleted?

[B]VAR [/B]   [B]byte [/B]Mode          
   [B]byte [/B]ModeMax
   [B]byte [/B]oldmode
 
   [B]byte [/B]Ign                    [COLOR=#8b4513] ' ***[/COLOR]
   [B]byte [/B]Start                  [COLOR=#8B4513] ' ***[/COLOR]
   [B]byte [/B]Choke                  [COLOR=#8B4513] ' ***[/COLOR]
   [B]byte [/B]Oil                    [COLOR=#8B4513] ' ***[/COLOR]
   [B]byte [/B]Neutral
   [B]byte [/B]Warn                   [COLOR=#8B4513] ' ***[/COLOR]          
   [B]byte [/B]rpm                    [COLOR=#8B4513] ' ***[/COLOR]

Any enlightenment gratefully received as always!

Hugh

BOAT14 - Archive [Date 2012.01.15 Time 17.58].zip

T Chap

Hi. It is possible that the unused bytes(locations) were getting used by one of the stacks if it did not have enough to run on. So when you get rid of the supposed unused vars, the stack starts robbing from the next location(s) immediately following the stack.

Another possible culprit is that you may be accessing a variable by an index factor that is exceeding the boundaries of the var you are trying to affect, and subsequently affecting another variable(location). I did not study the code to see if this might be possible in your case.

A way to test this is, to put back in the vars, create a method to display a message if the vars are changed. On the init of the program, set all the vars to 0, then If var > 0, display message. Do this for all vars and see if you see one actually getting changed.

I am not positive on this, but I believe that when you declare vars, the program starts with longs, words, and bytes in that order when arranging them, then it uses the order in which you have placed them. Hopefully someone can correct this if needed. This may make it easier to find the stack that is robbing, if that is the case.

Hugh

Thanks. I shall experiment further.

What surprised me today whilst trying to reduce memory usage, etc., is that the Propeller Tool included in the final binary PUBs (in other OBJects) that were not being used (as well as those that were, as expected). I had expected that the tool would identify which PUBs of other OBJects were being called and which were not, not bothering to include the latter. A few minutes commenting out a few of these 'orphan' PUBs reduced the memory usage from 4250 longs to 3670 longs, dwarfing the few longs saved by my work in the main code.

Is this commenting-out a stage of Propeller code development that I have otherwise missed? Surely the tool should be able to determine those PUBs that are required and those that are not?

The give-away for me was spotting in the Hex window strings of text that were nothing to do with my efforts.

Duane Degn

Brad's Spin Tool (BST) eliminates unused objects and methods. I've had programs that wouldn't compile with the Propeller Tool but had plenty of extra memory when I used BST.

Duane Degn

I think T Chap's right about an out of bound array. I don't think you have 15 longs after florate. This code could be causing the trouble.

          eeprom.VarBackup(@floCount, @floCount[15] + 3) 
          eeprom.VarBackup(@fuelrem,  @fuelrem[15] + 3)

Hugh

Duane Degn wrote: »

I think T Chap's right about an out of bound array. I don't think you have 15 longs after florate. This code could be causing the trouble.

          eeprom.VarBackup(@floCount, @floCount[15] + 3) 
          eeprom.VarBackup(@fuelrem,  @fuelrem[15] + 3)

Yes, it was.

(Schoolboy error)

Thank you!