Question on BS2p slot programming....

deno

Hello, again...The question that I can't quite figure out by reading the help files on the command STORE is:

First I know if I have only DATA statements in other slots..lets say slot 1,2,3 and the main program in slot 0, after I call slot 1 or 2 or 3 from slot 0 (using the STORE command) to read the data that I want, the program will go back to the default slot of 0 without me telling it to do so. This is OK.

But, if I now have a complete sub routine (not just DATA statements) in slot 4, and I call slot 4 from the main program (slot 0), and run code in slot 4, do I have to recall slot 0 to get back to the main program, or will a simple RETURN command at the end of that sub routine in slot 4 get me back to slot 0 (the main program). Am I making sence here, i hope so?

Thank you for reading and answering...

Deno

Chris Savage

Deno,

·· You can't call a subroutine in another slot, nor can you return to the original slot (Since you can't do the call).· What you can do is read up on a Nuts & Volts article entitled Multi-Bank Programming, which is available at the link below.· This could teach you a number of tricks on multi-bank programming, including how to·jumping to a specific routine in another bank, and return, all another way.

http://www.parallax.com/html_pages/downloads/nvcolumns/Nuts_Volts_Downloads_V3.asp




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

deno

Thanks Chris for the link on multi programming banks. The key word here is the RUN command, which I had forgotten about.

Also, thanks to Jon Williams for the article, as well.

Deno

Newzed

Here is a little trick that will help you navigate the slots.

Suppose you are oin slot 0 and you want to run a routine in slot 4.· You simply write:

RUN 4

Now then suppose you want to go back to a certain routine in slot 0 called "counter".· At the end of the routine in slot 4 you write:

com = 1
RUN 0

Now then, at the very beginng of the slot 0 program, after all declarations but before any instructions, you write:

if com = 1 then counter

With this technique you can jump to any label in any slot - it works just like a GOTO.· The com statements are called flags, and you can have as many as you want.· MY RFID inventory program has 30 and I'm not finished yet.· You can use the same com for each slot - just make sure you don't duplicate flags in any one slot.· I would also suggest that when you write a flag, you insert a comment to remind you what is happening, like this:

com = 1········ 'goes to counter in slot 0
RUN 0

Hope this helps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Need a bezel for your LCD?

Newzed@aol.com
·

Jon Williams

To extend Sid's suggestion ... I use BRANCH (or ON-GOTO) in these cases. I also place my task value into SPRAM slot zero so I don't have copy variable declarations from one slot to another (which Sid's suggestion assumes). So, my version works like this:

· PUT 0, taskNum
· RUN newSlot

.... then, at the top of the new slot:

· GET 0, myTask
· ON myTask GOTO Task0, Task1, Task2, Task3 ....

If you want to be more clever, you can put the calling slot into SPRAM location one and do a GOSUB type thing:

· PUT 0, taskNum
· PUT 1, thisSlot
· RUN newSlot

... then:

· GET 0, myTask
· ON myTask GOSUB Task0, Task1, Task2, Task3 ....
· GET 1, oldSlot
· RUN oldSlot

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Post Edited (Jon Williams (Parallax)) : 6/17/2005 5:15:08 PM GMT

Tracy Allen

Here is another take on the cross bank RUN technique, that I've been using since the BS2sx came out in 1998.

http://www.emesystems.com/BS2SX.htm#Crossbank

I dedicate the first byte in RAM as my cross bank pointer, and that means that I always declare a certain word variable first in each and every bank as part of my template.

The cross slot byte is divided into two nibs, the high nib being the slot to jump to, and the low nib being one of 16 destinations possible in the target slot . I also set aside one byte in scratchpad, which I call "back". A trip to a routine in another slot consists of PUTting the return index (a byte with high nib low nib as just defined) into "back", and then with the target index, RUNing the high nibble to get to the target slot, and then BRANCHing in that slot to the routine specified by the low nibble. The return consists of GETting the value from "back", RUNning the high nibble to jump to the target slot (usually back to the original slot), and a BRANCH there to the index specified by the low nibble (usually a location just after the orignal call). It is possible to expand that to a full stack implementation for nested RUNs, but I found that to be more trouble prone than it is worth.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

deno

Thanks for all the advice...I have gone with the BRANCH command and return location identifiers placed into scratch pad RAM to get me back to the various spots in the main program (slot 0).

Using the "EMIC" from Grand Idea I decided to include all DATA statements (phrases/sentences) with the approprate slot where that "talking" takes place. Keeping track of STORE voice_data_1, voice_data_2, etc was getting to complicated.

So, one slot talks the time of day, another slot talks the battery voltage of the robot, a third slot talks the various "slang expressions " that are used.

Jon, your column #87 July 2002 was a big help...thanks.

Deno

Jon Williams

Since you're using the BS2p, you can use READ across slot boundaries. This would let you store your main program in slot 0 and your strings to "say" in the other slots. That might be a little cleaner than jumping from slot-to-slot. In order to make things easier (and if you have the space), put your phrases on even boundaries so that you can us a bit of math. If, for example, your phases (plus zero terminator) would fit into 32 bytes, you could find the starting address of a phrase by multiplying its phrase number by 32. You would use STORE to point READ to the slot that holds the phrase, read, and transmit the bytes to the Emic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax