Gosub problems

Archiver · 2000-09-21 08:31

I ran this on my stamp + a few debug statments. It runs fine. Check to make
sure that when you are driving the outputs hight that you are not
overloading the chip. If the BS2 is overloaded it can brownout and restart.
Try unhooking your loads from the stamp and run it again. That would be a
good place to start.

Original Message

From: "David Peterson" <robodave1@h...>
To: <basicstamps@egroups.com>
Sent: Thursday, September 21, 2000 3:38 AM
Subject: [noparse][[/noparse]basicstamps] Gosub problems

> Has anyone had a problem with the gosub statement? My case involves the
> gosub going to the appropriate function, but the return in that function
> kicks the execution back to the start, rather than where the function was
> called. The stamp 2 manual talks about another problem with gosubs that
> require the stop statement to prevent code fall through, but that's not my
> problem. A typical code example is below. Instead of returning to the the
> calling point in the intro, I would hear the speaker again, over and over
as
> it goes through the wrong loop. Any ideas?
>
> '====Constants (pin assignments)
> LED con 1
> SPKR con 0
> lmotp con 4
> lmotn con 5
> rmotp con 6
> rmotn con 7
> '====Variables
> note var word
> ct var byte
> LLD var in10
> RLD var in11
> LIR var in12
> RIR var in13
> LBP var in14
> RBP var in15
>
> freqout SPKR,200,2093
> freqout SPKR,200,2637
> freqout SPKR,200,3136
> freqout SPKR,300,4186
> freqout SPKR,150,3136
> freqout SPKR,500,4186
> pause 1000
>
> intro:
> gosub forward
> gosub sense
> goto intro
>
> sense:
> if LIR=1 or RIR=1 then backward
> if LBP=0 or RBP=0 then backward
> if LLD=1 or RLD=1 then backward
> return
>
> backward:
> high LED
> high lmotp
> low lmotn
> high rmotp
> low rmotn
> pause 1500
> low LED
> return
>
> forward:
> high LED
> low lmotp
> high lmotn
> low rmotp
> high rmotn
> pause 1500
> low LED
> return
>
> low lmotp
> low lmotn
> low rmotp
> low rmotn
>
>
>
>
>

Archiver · 2000-09-21 08:38

Has anyone had a problem with the gosub statement? My case involves the
gosub going to the appropriate function, but the return in that function
kicks the execution back to the start, rather than where the function was
called. The stamp 2 manual talks about another problem with gosubs that
require the stop statement to prevent code fall through, but that's not my
problem. A typical code example is below. Instead of returning to the the
calling point in the intro, I would hear the speaker again, over and over as
it goes through the wrong loop. Any ideas?

'====Constants (pin assignments)
LED con 1
SPKR con 0
lmotp con 4
lmotn con 5
rmotp con 6
rmotn con 7
'====Variables
note var word
ct var byte
LLD var in10
RLD var in11
LIR var in12
RIR var in13
LBP var in14
RBP var in15

freqout SPKR,200,2093
freqout SPKR,200,2637
freqout SPKR,200,3136
freqout SPKR,300,4186
freqout SPKR,150,3136
freqout SPKR,500,4186
pause 1000

intro:
gosub forward
gosub sense
goto intro

sense:
if LIR=1 or RIR=1 then backward
if LBP=0 or RBP=0 then backward
if LLD=1 or RLD=1 then backward
return

backward:
high LED
high lmotp
low lmotn
high rmotp
low rmotn
pause 1500
low LED
return

forward:
high LED
low lmotp
high lmotn
low rmotp
high rmotn
pause 1500
low LED
return

low lmotp
low lmotn
low rmotp
low rmotn

Archiver · 2000-09-21 08:58

At 02:38 AM 9/21/2000 -0500, you wrote:
>Has anyone had a problem with the gosub statement? My case involves the
>gosub going to the appropriate function, but the return in that function
>kicks the execution back to the start, rather than where the function was
>called. The stamp 2 manual talks about another problem with gosubs that
>require the stop statement to prevent code fall through, but that's not my
>problem. A typical code example is below. Instead of returning to the the
>calling point in the intro, I would hear the speaker again, over and over as
>it goes through the wrong loop. Any ideas?

Try adding an END statement at the end of the program.
Probably not the cause, but it can't hurt.

>'====Constants (pin assignments)
>LED con 1
>SPKR con 0
>lmotp con 4
>lmotn con 5
>rmotp con 6
>rmotn con 7
>'====Variables
>note var word
>ct var byte
>LLD var in10
>RLD var in11
>LIR var in12
>RIR var in13
>LBP var in14
>RBP var in15
>
>freqout SPKR,200,2093
>freqout SPKR,200,2637
>freqout SPKR,200,3136
>freqout SPKR,300,4186
>freqout SPKR,150,3136
>freqout SPKR,500,4186
>pause 1000
>
>intro:
>gosub forward
>gosub sense
>goto intro
>
>sense:
> if LIR=1 or RIR=1 then backward
> if LBP=0 or RBP=0 then backward
> if LLD=1 or RLD=1 then backward
> return
>
>backward:
> high LED
> high lmotp
> low lmotn
> high rmotp
> low rmotn
> pause 1500
> low LED
> return
>
> forward:
> high LED
> low lmotp
> high lmotn
> low rmotp
> high rmotn
> pause 1500
> low LED
> return
>
>low lmotp
>low lmotn
>low rmotp
>low rmotn

Archiver · 2000-09-21 17:30

> if LIR=1 or RIR=1 then backward
>backward:
....
> return

The backward in the first routine is not a subroutine call, it is a simple
goto. The BS2 won't know what to do with the return in the backward
routine.

-- Tracy

Archiver · 2000-09-21 18:17

One thing that should have been added is that I've coded a work around using
goto statements, with the same devices hooked up. That program works as
expected.

Original Message

From: "David Peterson" <robodave1@h...>
To: <basicstamps@egroups.com>
Sent: Thursday, September 21, 2000 2:38 AM
Subject: [noparse][[/noparse]basicstamps] Gosub problems

> Has anyone had a problem with the gosub statement? My case involves the
> gosub going to the appropriate function, but the return in that function
> kicks the execution back to the start, rather than where the function was
> called. The stamp 2 manual talks about another problem with gosubs that
> require the stop statement to prevent code fall through, but that's not my
> problem. A typical code example is below. Instead of returning to the the
> calling point in the intro, I would hear the speaker again, over and over
as
> it goes through the wrong loop. Any ideas?
>
> '====Constants (pin assignments)
> LED con 1
> SPKR con 0
> lmotp con 4
> lmotn con 5
> rmotp con 6
> rmotn con 7
> '====Variables
> note var word
> ct var byte
> LLD var in10
> RLD var in11
> LIR var in12
> RIR var in13
> LBP var in14
> RBP var in15
>
> freqout SPKR,200,2093
> freqout SPKR,200,2637
> freqout SPKR,200,3136
> freqout SPKR,300,4186
> freqout SPKR,150,3136
> freqout SPKR,500,4186
> pause 1000
>
> intro:
> gosub forward
> gosub sense
> goto intro
>
> sense:
> if LIR=1 or RIR=1 then backward
> if LBP=0 or RBP=0 then backward
> if LLD=1 or RLD=1 then backward
> return
>
> backward:
> high LED
> high lmotp
> low lmotn
> high rmotp
> low rmotn
> pause 1500
> low LED
> return
>
> forward:
> high LED
> low lmotp
> high lmotn
> low rmotp
> high rmotn
> pause 1500
> low LED
> return
>
> low lmotp
> low lmotn
> low rmotp
> low rmotn
>
>
>
>
>
>

Archiver · 2000-09-21 19:47

>> if LIR=1 or RIR=1 then backward
>>backward:
>....
>> return
>
>The backward in the first routine is not a subroutine call, it is a simple
>goto. The BS2 won't know what to do with the return in the backward
>routine.

Oops, I took your code out of context. Your gosub followed by the branch
to another subroutine should work fine:

debug "top",7
intro:
gosub sense
goto intro

sense:
debug "here"
if in12=1 then back
return

back:
debug "back"
return

Did you post your entire program? GOSUBs nested more than 4 deep will take
execution back to the top. STAMP2W.EXE gives no warning. For example the
following program will crash back to the top:

debug "top",7
intro:
gosub sense ' 1st gosub
goto intro

sense:
debug "here"
if in12=1 then back
return

back:
gosub back1 ' 2nd gosub
return

back1:
gosub back2 ' 3rd gosub
return

back2:
gosub back3 ' 4th gosub
return

back3:
gosub back4 ' 5th & fatal gosub --> top
return

back4:
debug "back"
return

-- Tracy Allen
Electronically Monitored Ecosystems
http://www.emesystems.com

Gosub problems

Comments