Ahh! Program trick confusing!

FIRST General Forum
#1

Posted by Gui Cavalcanti at 03/17/2001 1:01 PM EST

Student on team #422, Mech Tech, from Governor’s School (GSGIS) and Verizon.

OK… wait. I’ve just read that entire segment dedicated to the extended programming trick that involves multiple programs… but i’m confused. Do you add subroutines before or after the “RUN” command line in your programs? For example, i’ll give you the following…

Program 1:
Initialization
SERIN command
light subroutine

RUN Program 2:

Program 2:
Initialization
Major subroutines

RUN Program 3:

Program 3:
Initialization
minor subroutine
SEROUT command

RUN Program 1:

Is that right, or did I really screw something up?

-Gui Cavalcanti
422 (Mech Tech)

#2

Posted by Stephen at 03/17/2001 3:38 PM EST

Student on team #122, NASA Knights, from Grafton High School (Robotics team is at NHGS) and NASA.

In Reply to: Ahh! Program trick confusing!
Posted by Gui Cavalcanti on 03/17/2001 1:01 PM EST:

That seems right; just remember that what you want in program 1 goes before you type “RUN program 2”, and so on.

#3

Posted by Gregory Ross at 03/18/2001 2:15 AM EST

Engineer on team #330, Beach Bots, from Hope Chapel Academy and NASA/JPL.

In Reply to: Ahh! Program trick confusing!
Posted by Gui Cavalcanti on 03/17/2001 1:01 PM EST:

I can see a possible problem or two with your pseudo program.

Remember, every time you “run” one of the programs in your BASIC Stamp project, it is run from the beginning – including any initialization code. This will happen every time through the main loop – approximately 40 times per second. More than likely, this is not what you want to have happen.

Obviously, as with any programming problem, there will be more than one way to overcome it.

Probably the easiest way (and not the way I did it when I split up our program) is something like this:

Program 1:
Initialize
RUN Program 2

Program 2:
SERIN command
perform light routine
perform compressor control
RUN Program 3

Program 3:
perform steering functions
RUN Program 4

Program 4:
perform lift control functions
RUN Program 5

Program 5:
perform bridge balance function
SEROUT command

RUN Program 2

Note: In the initialization, everything needed for all programs should be initialized. The only exception is anything that needs to be initialized in EEPROM (which can be accessed only from its own program.) If you need to initialize anything in EEPROM, I would suggest something like:

Program 1:
Initialize
RUN Program 2

Program 2:
if first time then Initialize
SERIN command
perform light routine
perform compressor control

RUN Program 3

Program 3:
if first time then Initialize
perform steering functions
RUN Program 4

Program 4:
if first time then Initialize
perform lift control functions
RUN Program 5

Program 5:
if first time then Initialize
perform bridge balance function
SEROUT command

RUN Program 2

You also need to remember that all of the variable space and all of scratchpad RAM is common between programs. You need to be sure to use the same variable definitions and scratchpad memory map in all your programs. The easiest way to do so is to declare all your data in an include file, and use the BASIC Stamp Preprocessor which I wrote to insert my include file into all my project files. I’m still not quite ready to formally release it, but if you are interested in beta testing it, let me know, and I will e-mail it to you.

Gregory Ross
Team 330, Beach Bots (Los Angeles Regional co-champs!)

: OK… wait. I’ve just read that entire segment dedicated to the extended programming trick that involves multiple programs… but i’m confused. Do you add subroutines before or after the “RUN” command line in your programs? For example, i’ll give you the following…

: Program 1:
: Initialization
: SERIN command
: light subroutine

: RUN Program 2:
: -----
: Program 2:
: Initialization
: Major subroutines

: RUN Program 3:
: -----
: Program 3:
: Initialization
: minor subroutine
: SEROUT command

: RUN Program 1:
: -----

: Is that right, or did I really screw something up?

: -Gui Cavalcanti
: 422 (Mech Tech)

#4

Posted by Travis Hoffman at 03/18/2001 9:00 AM EST

Engineer on team #48, Delphi E.L.I.T.E., from Warren G. Harding High School and Delphi Automotive Systems .

In Reply to: Ahh! Program trick confusing!
Posted by Gui Cavalcanti on 03/17/2001 1:01 PM EST:

: OK… wait. I’ve just read that entire segment dedicated to the extended programming trick that involves multiple programs… but i’m confused. Do you add subroutines before or after the “RUN” command line in your programs? For example, i’ll give you the following…

It depends on your definition of “subroutine”. All subroutines within a particular program called with the GOSUB instruction from the program body must be placed AFTER the RUN statement in that program:

'Program 1 body

pump = on
GOSUB Pumptimer

RUN 2

'Pumptimer subroutine

Pumptimer:
'pumptimer code
RETURN

If, by “subroutine”, you are instead referring to a smaller piece of your original unmodified program body that you placed in one of the subprograms of the new method, then this code should go BEFORE the RUN statement, just like any other regular code:

Original Program:

:Initialization Code

MainLoop:

:SERIN
:LIGHT CODE
:DRIVE CODE
:LIFT CODE
:SEROUT

GOTO MainLoop

New Method:

:Program 0
:Initialization Code
:RUN Program 1
:------------
:Program 1
:SERIN
:LIGHT CODE
:RUN Program 2
:------------
:Program 2
:DRIVE CODE
:LIFT CODE
:SEROUT
:RUN PROGRAM 1 'Equivalent to GOTO MainLoop
:------------

You can see how program execution flows in exactly the same manner as the original program. The only difference is you have boatloads more program space to work with :slight_smile:

Also, shouldn’t PROGRAM 0 be your first program? I could be wrong, but I thought it had to be. Program 0 is where you modify the Basic Stamp directive to include the names of programs 1-7. I have my initialize code in program 0. I then loop back to program 1 at the end of my highest-numbered program.

Travis

: Program 1:
: Initialization
: SERIN command
: light subroutine

: RUN Program 2:
: -----
: Program 2:
: Initialization
: Major subroutines

: RUN Program 3:
: -----
: Program 3:
: Initialization
: minor subroutine
: SEROUT command

: RUN Program 1:
: -----

: Is that right, or did I really screw something up?

: -Gui Cavalcanti
: 422 (Mech Tech)

#5

Posted by Gregory Ross at 03/18/2001 9:25 AM EST

Engineer on team #330, Beach Bots, from Hope Chapel Academy and NASA/JPL.

In Reply to: Re: Ahh! Program trick confusing!
Posted by Travis Hoffman on 03/18/2001 9:00 AM EST:

Thank you for catching that.

Greg

: : OK… wait. I’ve just read that entire segment dedicated to the extended programming trick that involves multiple programs… but i’m confused. Do you add subroutines before or after the “RUN” command line in your programs? For example, i’ll give you the following…

: It depends on your definition of “subroutine”. All subroutines within a particular program called with the GOSUB instruction from the program body must be placed AFTER the RUN statement in that program:

: 'Program 1 body

: pump = on
: GOSUB Pumptimer

: RUN 2

: 'Pumptimer subroutine

: Pumptimer:
: 'pumptimer code
: RETURN

: If, by “subroutine”, you are instead referring to a smaller piece of your original unmodified program body that you placed in one of the subprograms of the new method, then this code should go BEFORE the RUN statement, just like any other regular code:

: Original Program:

: :Initialization Code

: MainLoop:

: :SERIN
: :LIGHT CODE
: :DRIVE CODE
: :LIFT CODE
: :SEROUT

: GOTO MainLoop
: *************************************

: New Method:

: :Program 0
: :Initialization Code
: :RUN Program 1
: :------------
: :Program 1
: :SERIN
: :LIGHT CODE
: :RUN Program 2
: :------------
: :Program 2
: :DRIVE CODE
: :LIFT CODE
: :SEROUT
: :RUN PROGRAM 1 'Equivalent to GOTO MainLoop
: :------------

: You can see how program execution flows in exactly the same manner as the original program. The only difference is you have boatloads more program space to work with :slight_smile:

: Also, shouldn’t PROGRAM 0 be your first program? I could be wrong, but I thought it had to be. Program 0 is where you modify the Basic Stamp directive to include the names of programs 1-7. I have my initialize code in program 0. I then loop back to program 1 at the end of my highest-numbered program.

: Travis

: : Program 1:
: : Initialization
: : SERIN command
: : light subroutine

: : RUN Program 2:
: : -----
: : Program 2:
: : Initialization
: : Major subroutines

: : RUN Program 3:
: : -----
: : Program 3:
: : Initialization
: : minor subroutine
: : SEROUT command

: : RUN Program 1:
: : -----

: : Is that right, or did I really screw something up?

: : -Gui Cavalcanti
: : 422 (Mech Tech)

#6

Posted by Gui Cavalcanti at 03/18/2001 6:09 PM EST

Student on team #422, Mech Tech, from Governor’s School (GSGIS) and Verizon.

In Reply to: Ahh! Program trick confusing!
Posted by Gui Cavalcanti on 03/17/2001 1:01 PM EST:

I’m starting to get it, except for one last teeny thing. Do you need to declare variables in every program? (i.e. before the start of each main program do the massive list of variables:

p1_x VAR byte
throttlecontrol VAR p1_x

etc.) I realize they are shared, but wouldn’t all the variables in the first program carry over to the rest? The only reason I ask is because that would sink more program space that you could use for actually programming…

Thanks,
Gui

Team 422 - Mech Tech
Richmond, Virginia

#7

Posted by Stephen at 03/18/2001 8:58 PM EST

Student on team #122, NASA Knights, from Grafton High School (Robotics team is at NHGS) and NASA.

In Reply to: OK… new question
Posted by Gui Cavalcanti on 03/18/2001 6:09 PM EST:

Yes, variable and constant declarations have to be the same in every program. This can be a pain if you want to change one thing - you would have to change it in all programs. I have written a short perl program to take input from one file (or many), and put that into the specified part of each program. All you have to do is tell the program what file or files your variable and constant declarations are in, and it automatically puts those into every file in the folder with a .bsx extension ( you could change this part by just changing the list to the files your programs are in, just in case you only wanted the code to effect certain programs in a directory). If you want the program, just e-mail me, and I’d be glad to send it to you.

#8

Posted by Gregory Ross at 03/19/2001 1:28 PM EST

Engineer on team #330, Beach Bots, from Hope Chapel Academy and NASA/JPL.

In Reply to: YES
Posted by Stephen on 03/18/2001 8:58 PM EST:

I hate it when my kids get nit-picky, but I guess they come by it honestly :wink:

Steven,

Actually, constants don’t need to be defined in every program (unless, of course, they are used in multiple programs) since they take up no variable space.

…and Gui,
It’s true that the variable data stays in memory between programs, but one program has no idea of variables defined in another program, or how much variable space is used by other programs unless you tell it (by defining all variables in all programs.)

Also, defining variables takes up no PROGRAM space (EEPROM) only VARIABLE space (RAM). (I realize that may have been what you meant when you wrote “program space” – Just wanted to be sure all those nasty little nits were gone :slight_smile:

Of course, since variable space is so much more limited (26 bytes) than program space(64Kytes per program), then conserving variable space may be of much greater concern.

Maybe an example would be helpful: Consider the case where you have one program that fills 10 byte variables, and another program that sums those ten bytes and stores the result into a word variable.

If the first program only defined the 10 bytes, then since the interpreter puts word variables first in memory, the word variable defined in the second program would overlay the first two byte variables from the first, and the summation would be of the last eight bytes and two undefined bytes!

#9

Posted by Gui Cavalcanti at 03/19/2001 10:05 PM EST

Student on team #422, Mech Tech, from Governor’s School (GSGIS) and Verizon.

In Reply to: Just a few nits (not ninnies) to pick
Posted by Gregory Ross on 03/19/2001 1:28 PM EST:

: Of course, since variable space is so much more limited (26 bytes) than program space(64Kytes per program), then conserving variable space may be of much greater concern.

Actually, I thought that the actual program space (ASCII space) was only 2kbytes… which is why this discussion was brought up. By linking the programs, you could get up to 16 kbytes of space to work with.

-Gui

#10

Posted by Gregory Ross at 03/20/2001 1:06 AM EST

Engineer on team #330, Beach Bots, from Hope Chapel Academy and NASA/JPL.

In Reply to: Re: Just a few nits (not ninnies) to pick
Posted by Gui Cavalcanti on 03/19/2001 10:05 PM EST:

: Actually, I thought that the actual program space (ASCII space) was only 2kbytes… which is why this discussion was brought up. By linking the programs, you could get up to 16 kbytes of space to work with.

Oops. You’re right. I couldn’t remember how big each program slot was, so I quickly scanned the BASIC Stamp manual PDF file for the information. The first thing I came across was the number 65535 in the description of the DATA command (which defines data to be stored in EEPROM) and without thinking, converted to KBytes, and wrote 64KB. It turns out that 65535 is the largest data VALUE that can be STORED in EEPROM, and not the highest address available.

Let’s not rest until all those nits are extirpated!

#11