Slot programming & Variables..?
Vern Graner
Posts: 337
Hi all.. I've been beating my head against using Slots on the Basic Stamp IIP and I'm confused on how exactly the variables interact with each other across slots. Is there a good tutorial out there that anyone can reccomend that details these intricacies?
I've heard that to "avoid confusion" you should just define the exact same variables at the beginning of each slot, but in my case this would be exceedingl difficult as I need just about all the variables in slot 1 and about 3/4 of them in slot 2! TIA for any help or pointers.. heh.. "pointers"..
Vern
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I've heard that to "avoid confusion" you should just define the exact same variables at the beginning of each slot, but in my case this would be exceedingl difficult as I need just about all the variables in slot 1 and about 3/4 of them in slot 2! TIA for any help or pointers.. heh.. "pointers"..
Vern
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Vern Graner CNE/CNA/SSE | "If the network is down, then you're Senior Systems Engineer | obviously incompetent so why are we Texas Information Services | paying you? Of course,if the network http://www.txis.com | is up, then we obviously don't need Austin Office 512 328-8947 | you, so why are we paying you?" ©VLG
Comments
The variables don't interact with each other across slots, they are all one and the same. If you're familliar with COMMON used in other Basic varients and in Fortran, that's essentailly what it is.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
·· I'm not sure what you mean by you need all of them in slot 1 and 3/4 of them in slot 2...But if you declare them the same in each slot they will all be there in all slots.· Optionally you can use SPRAM for storing data and use a temp variable to move the information back and forth.· The only tutorial I know of is linked below.· I hope this helps...Take care.
http://www.parallax.com/dl/docs/cols/nv/vol3/col/nv87.pdf
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Let me see if I can explain: To construct the program I am dealing with now, I first started by writing for the BSII (not the bS2p).
I wrote a program that could read inputs from 8 pushbuttons and operate an LCD to display menu items. This program consumed about 3/4 of the variable space in the BSII. The reason? I was using lots of data arrays to hold menu values and DATA statements to hold prompts for the LCD. I was also using the 74LS165 to expand the # of inputs to the stamp and a hitt consulting LED display (it consumes 8 bytes in and of itself!). With counters and flags thrown in, I was fairly tight on variable space.
I then wrote a program that would control a DC-16 and a Parallax Serial Servo controller. It used the 74LS165 for input expansion and a Serial LCD for out put along with the Hitt Consulting LED unit. I also had TWO uMp3 players & associated variables (volume, song names etc). When this mosnter was done I had bout 14 BITS of variable space remaining.
Both of these programs work appropriately when used as stand along programs. But, when I placed one into Slot 1 and then called the second one in Slot 2, lots of weird things started to happen. Flags would get reset and data displatyed by the LCD or LED would get corrupted. The Serial Servo controller would lose its seek points etc. Hence the post I made tonight.
I apppreciate the link to the article, I'll print and read over it tomorrow. In the meantime, I'm still puzzled by the "scratch pad RAM" feature of the IIp and why it would be needed and how it would be a used. A cursory glance at the PDF shows it might have some good info on that.
Thanks to all who responded. I'm gunna go get some sleep and see if things look clearer in the morning.
Vern
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Vern) : 8/3/2006 5:31:07 PM GMT
The following archive routine PUTs all 28 bytes of RAM into scratchpad. The retrieve routine GETs them back. The third routine exchanges the contents of all the RAM variables with the contents of a 32 byte scratchpad buffer, so when there are two slots, this can work both directions to maintain both sets of variables. Some kinds of routines use the SPSTR modifier to read in data into the SP ram starting at location zero, so in those cases you may want the buffer to start at a higher address, here named SPbuf.
' archive, using predefined names, buffer start at loc SPbuf in SPram
PUT SPbuf, b0
FOR b0 = 1 to 27
PUT SPbuf+b0, b0(b0)
NEXT
' restore, buffer SPram SPbuf to SPbuf+27
FOR b0 = 1 to 27
GET SPbuf+b0, b0(b0)
NEXT
GET SPbuf, b0
' exchange
PUT SPbuf+28, b0 ' save current slot b0 and b1
PUT SPbuf+29, b1
GET SPbuf, b0 ' retrieve old slot b0 and b1
GET SPbuf+1, b1
PUT SPbuf+30, b0 ' temporary save old slot b0 and b1
PUT SPbuf+31, b1
FOR b0 = 2 to 27 ' current slot becomes old slot and old slot becomes current
GET SPbuf+b0,b1 ' temporary get old value
PUT SPbuf+b0,b0(b0) ' current value saved
b0(b0)=b1 ' old value becomes current value
NEXT
GET SPbuf+28,b0 ' finish up exchange of b0 and b1
GET SPbuf+29,b1 ' from temporarly SP buffer
PUT SPbuf,b0
PUT SPbuf+1,b1
GET SPbuf+30,b0
GET SPbuf+31,b1
RETURN
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Also remember, if you're not actually using the same values between the banks, as it almost appears is the case, then the variables (In this case, those RAM locations) will still retain their values from one program/slot to the next rather than being initialized to 0 as in the case or a reset.· This can cause strange effects if you assume the variables to be at a given state.· It is possible that Tracy's suggestion would help in this case.· Take care Vern.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
SLOT 1 contains program "MAIN.BSp". "MAIN.BSp" has the following variable definitions:
' ************************ ' * Variables * ' ************************************************************************* ' Parallax Serial Servo Controller PSCchannel VAR Nib ' servo 0-15 PSCRate VAR Nib ' servo seek rate 0-64 PSCposition VAR Word ' servo position 250-1250 PSCBuff VAR Byte (3) ' buffer to hold answer from PSC ' ParallaxEFX DC-16 DC16Channel VAR Nib ' The output port number 1-16 DC16State VAR Bit ' The state (1=on 0=off) ' Hitt LED display LEDvalue VAR Word ' Holds value to display (0-9999) LEDzeros VAR Bit ' leading zeros 0=supressed 1-displayed LEDsegments VAR Byte (4) ' display routines & customer chars LEDcnt VAR Byte ' display routines LEDFlag VAR Bit ' update the LED only if changes are needed ' Rogue uMP3 player ' Volume VAR Byte ' uMP3 Volume control variable 0-255, 0= loudest ' 74LS165 Octal switches VAR Byte ' 74LS 165 input switches ' loop through button check Flag VAR Bit (9) 'Flag for buttons 11-15 PumpRunning VAR Bit (5) 'Flag for pump status cntI VAR Nib ' ' System variables PaintShots VAR Byte 'number of paint shots per play PaintTime VAR Byte 'amount of time to play Ticks VAR Byte 'incremented for each loop used for seconds countdown Seconds VAR Byte RunTime VAR Byte (4) 'used to hold timing for run time of pumpsThe above allocation of variables leaves the memory map looking like this:
MAIN.BSp works fine when I run it as a stand alone program (i.e. not using it as one of multiple slots). I then created MENU.BSp, and it's variable declarations look like this:
' ************************ ' * Variables * ' ************************************************************************* Flag VAR Bit (4) ' Flag for buttons up/dwn/left/right MenuPointer VAR Nib ' contains the current menut item # MenuItemValue VAR Nib (6) ' contains the value for each menu item idx VAR Word ' Used to hold the data index char VAR Byte ' used to read each character from the data text cntI VAR Nib ' counter used by FOR/NEXT loop switches VAR Byte ' 74LS165 input switches PaintShots VAR Byte ' number of paint shots per play PaintTime VAR Byte ' amount of time to playThis allocation of variables leaves the memory map looking like this:
The MENU.BSp uses DATA statements to hold text for displaying on the LCD like this:
' ************************ ' * Data Statements * ' ************************************************************************* ' Note: the "@10" means to leave 10 bytes free for recording settings SetAside DATA @10 MenuText0 DATA $80, "Pump Mode: ",0 MenuText0a DATA $94, "[noparse][[/noparse]Prime] Flush ",0 MenuText0b DATA $94, " Prime [noparse][[/noparse]Flush] ",0 MenuText1 DATA $80, "Inkjet msg: ",0 MenuText1a DATA $94, "[noparse][[/noparse]none/off] ",0 MenuText1b DATA $94, "Austin Robot G..",0 MenuText1c DATA $94, "First Night Au..",0 MenuText1d DATA $94, "www.robotgroup..",0 MenuText2 DATA $80, "Paint Shots: ",0 MenuText2a DATA $94, "[noparse][[/noparse]30] 60 90 ",0 MenuText2b DATA $94, " 30 [noparse][[/noparse]60] 90 ",0 MenuText2c DATA $94, " 30 60 [noparse][[/noparse]90] ",0 MenuText3 DATA $80, "Paint Seconds: ",0 MenuText3a DATA $94, "[noparse][[/noparse]30s] 60s 90s ",0 MenuText3b DATA $94, " 30s [noparse][[/noparse]60s] 90s ",0 MenuText3c DATA $94, " 30s 60s [noparse][[/noparse]90s] ",0 MenuText4 DATA $80, "Light Test: ",0 MenuText4a DATA $94, "[noparse][[/noparse]Off] Seq Flsh ",0 MenuText4b DATA $94, " Off [noparse][[/noparse]Seq] Flsh ",0 MenuText4c DATA $94, " Off Seq [noparse][[/noparse]Flsh]",0 MenuText5 DATA $80, "Save & Exit? ",0 MenuText5a DATA $94, "[noparse][[/noparse]No] Yes ",0 MenuText5b DATA $94, " No [noparse][[/noparse]Yes] ",0This results in a memory map that looks like this:
(Note the set aside of 10 bytes at the begining of my data statements is to reserve space for the values the menu system alters. I store/fetch these values on exit/starup of a slot). Again, this program works fine when I run it by itself, resulting in menu items being displayed on the Parallax LCD like this:
So, I then placed a specifier in MAIN.BSp to make MENU.BSp into a slot for use with MAIN by putting this in the first line of MAIN.BSp:
'{$STAMP BS2p, MENU}Then, I placed a command to call the menu program from the main program like this:
WAITING: IF IN15 = 0 THEN RUN 2 IF IN14 = 0 THEN StartProgram GOTO WAITING StartProgram:When I call the menu program from MAIN using the code shown above, and start to navigate the menus, I get this on the LCD:
So, to recap, these two programs, when run stand alone, work fine and operate as designed. However, if I call MENU from MAIN I get garbage (i.e. the data I'm reading gets munged). Again, I'm not needing to move data from one slot to another via variables (I'm actually able to do that by writing a small group of values to EEPROM when I move from MENU to MAIN). Can anyone give me an idea as to what is going on here? Any help appreciated.
Vern
PS: In case anyone wants to look at the actual code, let me know. I can provide it, but its pretty gigantic (MAIN is about 8 pages and MENU is like 6) so I didn't post it inline to save space here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris:
thanks for following along with me.
' ************************ ' * Variables * ' ************************************************************************* Flag VAR Bit (4) ' Flag for buttons up/dwn/left/right MenuPointer VAR Nib ' contains the current menut item # MenuItemValue VAR Nib (6) ' contains the value for each menu item idx VAR Word ' Used to hold the data index char VAR Byte ' used to read each character from the data text cntI VAR Nib ' counter used by FOR/NEXT loop switches VAR Byte ' 74LS165 input switches PaintShots VAR Byte ' number of paint shots per play PaintTime VAR Byte ' amount of time to play ' ************************ ' * Initialization * ' ************************************************************************* Clear all the variables to a known state: cntI=0 FOR cntI=0 TO 3 FLAG(cntI)=0 NEXT Menupointer=0 FOR cntI=0 TO 5 MenuItemValue(cntI)=0 NEXT idx=0 char=0 switches=0 PaintShots=0 PaintTime=0 cntI=0When called from the MAIN, MENU still produces this:
Vern
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Anotheer thing, though, is that you shouldn't use EEPROM for value transfers.
Use the SRAM for that as it doesn't 'wear out' as EEPROM might.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Thanks for responding & point well taken.
In my case, I'm using EEPROM to store just a few values so they are non-volatile when the machine is turned off. Then on the startup, the values are fetched and used by program "MAIN". I don't expect in final operation to have the menu accessed very often.. maybe once or twice in a month.
Vern
PS: I want all of you to know I really apreciate all the participation! I couldn't do spit w/o the help on this forum!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If I'm not mistaken, the IIp (which I haven't worked with) works like the BS2sx (which I have worked with) as far as the slots structure goes. That would lead me to believe you're not doing anything "illegal"! The only thing I would do differently is where you call the menu program:
WAITING:
IF IN15 = 0 THEN RUN 2
IF IN14 = 0 THEN StartProgram
GOTO WAITING
StartProgram:
The IF statement is really looking for a label, not a directive. So try this:
WAITING:
IF IN15 = 0 THEN RunMenu
IF IN14 = 0 THEN StartProgram
GOTO WAITING
StartProgram:
RunMenu:
RUN 2
Other than having bad LCD code in slot 2, it should run.
It may also be worthwhile doing a test of of a really simple slot 1 program calling a slot 2 program then getting back safely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk
http://www.siskconsult.com
·
·· With a small piece of code you could reset/clear all of the variables at the start of each block of code to prevent this problem.· I think that is what's happening.· Tracy once posted a piece of code to do this.· If you have a Byte or Word variable in your variable declarations you can refer to the entire memory as an implicit array and reset all VAR locations at once.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
Concerning this:
>' Note: the "@10" means to leave 10 bytes free for recording settings
> SetAside DATA @10
I just want to be sure you know that location 10 in slot 1 is not the same as location 10 in slot 0.
When the program in slot zero needs to use those settings that have been entered in slot 1 eeprom, it has to execute the STORE 1 command.
Now that I see what your two slots do, I see no reason for them to share the same variables at all. When the menu runs, it should work just as well as it does from startup. Hmmm. It may be an issue of initialization of the i/o port. Maybe the servo program is doing something that affects the LCD adversely. You might try initializing all the directions to inputs at the start of your menu slot.
DIRS=$0000
OUTS=$0000
That would put the i/o ports back the the reset conditions.
Also look carefully at the LCD initialization timing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Ok, I discovered the issue and got it resolved.
So, when the program was dloaded to the Stamp, the data was loaded at the top of the memory and the program at the bottom, except the program size on MAIN was large enough to OVERWRITE some of the data statments. Subsequenlty, when the menu would fetch the strings of data to display on the LCD, it was fetching the binary of the program that had overwritten the DATA info!
This lead to the corruption seen in the LCD pictures I included above. To solve this, I removed the STORE =1 directive from the MENU program, allowing it to store data in its own slot, then added a STORE=2 directive to the MAIN progrma so it would fetch the sotred menu values from the MENU slot! Poof! works fine now!
Thanks again to everyone for their thoughts and observations. [noparse]:)[/noparse]
Vern
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thanks Tracy! That got me started in the right direction to get this resolved! [noparse]:)[/noparse]
Vern
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔