|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Ahh! Program trick confusing!
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
|
|||
|
|||
|
Re: Ahh! Program trick confusing!
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
|
|||
|
|||
|
Re: Ahh! Program trick confusing!
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
|
|||
|
|||
|
Re: Ahh! Program trick confusing!
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 RIVE CODE:LIFT CODE :SEROUT GOTO MainLoop ************************************* New Method: rogram 0:Initialization Code :RUN Program 1 :------------ rogram 1:SERIN :LIGHT CODE :RUN Program 2 :------------ rogram 2 RIVE 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 ![]() 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
|
|||
|
|||
|
You're right. The first program is 0.
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 : RIVE CODE: :LIFT CODE : :SEROUT : GOTO MainLoop : ************************************* : New Method: : rogram 0: :Initialization Code : :RUN Program 1 : :------------ : rogram 1: :SERIN : :LIGHT CODE : :RUN Program 2 : :------------ : rogram 2: RIVE 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 ![]() : 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
|
|||
|
|||
|
OK... new question
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
|
|||
|
|||
|
YES
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
|
|||
|
|||
|
Just a few nits (not ninnies) to pick
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 ;-) 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 :-) 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
|
|||
|
|||
|
Re: Just a few nits (not ninnies) to pick
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
|
|||
|
|||
|
Oops. Thank you for the correction
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! |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| 2-week FIRST summer program @ WPI | ColleenShaver | General Forum | 20 | 31-05-2009 03:02 |
| initialization program and speed controllers | rosebud | Programming | 15 | 05-10-2004 03:35 |
| Fried program slots? | Jeff Waegelin | Programming | 18 | 19-03-2003 18:08 |
| Credits for FIRST program. | archiver | 2000 | 6 | 24-06-2002 00:16 |
| An invitation for HS Juniors | archiver | 2000 | 0 | 23-06-2002 22:51 |