Constants and variable space in the eeprom...

deno

Hello fellow Basic Stamp users...Having been using Basic Stamps for various homerew projects over the years, and now writing code into the BS2p, I was wondering why there seems to be no limit to the number of CONSTANTS one can set up in a program. Variable space as you know is limited. I am running a EMIC speech module on my robot, and with all the program slots available, I have managed to define almost a 100 CONSTANTS in the first program slot with eeprom addresses in other program slots. (Different phrases that are called a various times for the robot to speak as he roams around the yard.)
I guess my question is: Where are the CONSTANTS stored??

My second question, or recommendation, on the Basic Stamp editor, and I know this is probably asking alot, but it sure would be nice to be able to label the bookmarks (instead of just numbers) and have the labeled bookmarks be non-volitable so when you return the the code, one could navigate to various bookmarks to make adjustments to the code in a sub routine.

So, thanks to all who might read this, and looking forward to a reply at least to the first paragraph.

Deno

Chris Savage

deno,

·· Constants do not use RAM because they are not variable.· That is, they cannot be changed.· Only changing values, or variables use RAM space.· Also, at compile time the·constants are substitued for the values you assigned them, so the length of the names doesn't make them use more program space.· They won't use memory until the constant is used within the program.· Therefore you can assign tons of constants, and they won't even be used unless you use the name elsewhere in the program.

·· As for your second request, I will pass that information on to the appropriate application engineer.· No guarantees that it will be implemented though.·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

allanlane5

Yes a 'CON' is merely a compile-time directive to the compiler -- like a '#define' mapping in C. When compiled, the CON symbol gets replaced immediately with the appropriate value in the code, in the EEPROM. This gives you the best of both worlds -- you can easily change the 'CON' entry in one place, and your change will be propagated all over your code by the compiler.

So you can 'CON' 2000 BYTE values before you run out of EEPROM space for them (depending on how many places they are used, of course)

Oh, and if you only declare, but never actually USE a particular one of your constants, then that constant·actually takes up NO space in the EEPROM.

deno

I see the light....thanks for the reply

Deno

Jeff Martin

Hi Deno,

The first question was answered by the time I got here, so I'll answer the second.

We have considered making the bookmarks non-volitile. The problem is that doing so would require them to be stored somewhere (in the same file, in a separate file, in the registry, etc). We don't want to save them in the original file because that would, of course, change the file by adding something that, technically, should be hidden from the user in the actual code. Since it is just a pure text file, it's not very practical to do that without causing some other side effect (people using other editors, accidentally modifying it and partially deleting the bookmark data, etc). The option of saving them in a separate file is also not very attractive to us because we don't like littering a user's development directory with many files (some compilers require that, but we try to avoid that as much as possible).

The last option, storing a limited number of them in the registry, is what we will likely do if we do indeed add this feature. This would seem to work well because the purpose of the bookmarks are for quick navigation during development time, thus we can store the positions for the last 10 files accessed, and that should be sufficient for the intended use of bookmarks.

We have never considered creating names for them. I can understand why you'd want to do that, but don't understand why it would be of much use because you can easily put a bookmark next to a label in the code, and since it is most convienent to access bookmarks with the Ctrl+# shortcut, having names would mean you'd have to use the shortcut menu or main menu to access a named bookmark. Since that feature is really intended for very brief usage during development, it doesn't seem to be worthwhile to name them.

Thank you for your suggestions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.