Gosub not returning to point it was called

[smeagol]

Hi all,

First attempts with a picaxe and starting to develop some code. this code is nowhere near complete but a working model that I am running through simulate.

Subroutine noise calls 2 other subroutines, the first one, setthresh, works fine and the return goes back to noise however noise then calls setdelay but the return here jumps to setthresh instead of noise where it was called from.

I can't understand why this is happening, to my, thinking the return in setdelay should go back to the point in noise where it was called from. or am I barking up the wrong tree?

Programming editor 5.3.1

P.S any valid critiques of the code so far also welcome.

; Camera Thingy fire flash on various inputs and Intervalometer
; V1

;Define symbols for input and output pins
symbol LEDShutter = b.0
symbol LEDFlash = b.1
symbol Focus = b.2
symbol Shutter = b.3
symbol Flash1 = b.4
symbol Flash2 = b.5
symbol FlashHV = b.6
symbol Unused = b.7
symbol Sensor1 = c.0
symbol Sensor2 = c.1
symbol LCD = c.2
symbol ButtonSET = pinc.5
symbol ButtonUP = pinc.6
symbol ButtonDOWN = pinc.7

;Define Symbols to control Outputs
symbol AllOff = %00000000		;All Outputs Off
symbol FireFocus = %00000100		;Focus On
symbol FireShutter = %00001101	;Focus, Shutter & LEDShutter On
symbol FireFlash = %01111111		;Focus, Shutter, Both LEDs and all Flash On

;Define Variables
symbol Threshold = b0			;Threshold for microphone trigger (0-255) Check figures for sensitivity
symbol Delay = b1				;Delay before firing flash (maybe needs to be a word)

;Setup input and Outpit pins
let dirsb = %11111111			;All B pins set as Output
let dirsc = %00000100			;All C pins as Input except c.2 output for LCD

pause 1000
serout LCD,N2400,(254,128,"      The       ")
serout LCD,N2400,(254,192," Camera Thingy  ")
pause 1000

main:
	serout LCD,N2400,(254,128,"Sound Activated ")
	if buttonset = 1 then goto noise			;add other menu options here
	pause 10							;Debounce?
	goto main
	

noise:
	serout LCD,N2400,(254,128,"  Sound Sensor  ")
	gosub setthresh
	gosub setdelay
	
	
setthresh:
		serout LCD,N2400,(254,192,"Threshold = ",#Threshold," ")
		if buttonup = 1 then
			inc threshold
		else if buttondown = 1 then
			dec threshold
		else if buttonset = 1 then
			return
		endif
		pause 10				;delay needed for debounce?
		goto setthresh
		
setdelay:
		delay = 0
		return

 

[Adamey]

You need a "goto main" line as the last line of your noise routine.

 

[smeagol]

Cheers adamy.

Now it works as expected.

Tops marks for a fast answer as well

 

[eclectic]

Two quick suggestions:

1. Print it our and use a pencil to follow the logic.

2. Use the simulator.

The program never actually gets "home"

e

 

[smeagol]

Good suggestions, and that is what I was doing.

What I didn't realise was that I had to return to main

I haven't done any programming in a loooooong time, and even then it wasn't anything major.

Anyone remember Blitz basic on the Amiga? I wish I had a Picaxe back then I was doing simple stuff that a Picaxe could easily handle but using the Amiga as the hardware interface

 

[Adamey]

Two quick suggestions:

1. Print it our and use a pencil to follow the logic.

That's exactly what I do. I get out my kids coloring pencils and trace my code, using different colors for different branches my code might take.

Even when you know how to program, sometimes doing the simple things can spot something you've overlooked a dozen times in the editor.

 

[SAborn]

I see in your program you use 2 gosubs and only have the 1 return statement, it would be a wise practice to have a return for each gosub at the end of each routine.

 

[westaust55]

I see in your program you use 2 gosubs and only have the 1 return statement, it would be a wise practice to have a return for each gosub at the end of each routine.

Both subroutines do have a return.
For the subroutine 'setthresh:" the reutn is "hidden" withint he IF...THEN...ELSE structure which is still valid.

that is:

else if buttonset = 1 then return​

The missing

goto main​

at the end of the "noise:" section as already identifed was the problem.

@smeagol
you can tentatively keep incrementing (INC command) or decrementing (DEC command) your variable threshold forever
suggest you consider setting some limits. as it is, if it reaches 255 then it will just roll over to zero(0) on the next INC command. likewise wth the decrement function.

 

[John West]

I make a habit out of including the word "return" in my code. I figure it makes it easier for someone not well versed in BASIC to understand, just in case someone other than myself ever winds up working with it.

 

[premelec]

Syntax check for RETURN

Oh wizards of editor writing....

It seems to me every proper subroutine has a RETURN somewhere in it's description - so why doesn't the syntax check look for this and report an error when no return is found? I understand that you may have different entry points before a return occurs but it still seems that lack of return is syntax checkable and could be included in the editor's wizardry...

At worst this might preclude some valid sloppy programming and be an annoyance or mystery to the programmer - probably would rarely preclude some wondrous clever programmer's move.

Oh.. I sense I'm treading on sacred ground of programmer's freedom of expression - no more rules about where I may place my subroutines etc... so back to the real work of doing it...

RETURN !

 

[hippy]

I sense I'm treading on sacred ground of programmer's freedom of expression

That's about the sum of it.

The more one allows a programmer the freedom to do something however they want the harder it is to determine that any rules are being broken. The more rigidly imposed the rules the less freedom the programmer has to do it the way they might choose to.

Plus, for constrained devices, or when up against limits, enforcing rules can be detrimental when a solution which has been excluded could save the day.

 

[smeagol]

Both subroutines do have a return.

@smeagol
you can tentatively keep incrementing (INC command) or decrementing (DEC command) your variable threshold forever
suggest you consider setting some limits. as it is, if it reaches 255 then it will just roll over to zero(0) on the next INC command. likewise wth the decrement function.

Valid point but it's a deliberate function, I had to test it to make sure it worked, it's quite useful to enable faster navigation with minimal coding or extra hardware. But as I said this is very early development code to test the principle, refinements will be added later.

 

[westaust55]

A structure like the following pseudo code would then fail because there are two gosubs but only one associated return, yet it is a frequent structure used by many.

Main:
  Fetch a byte
  GOSUB sendbytetoLCD
  GOTO Main

sendbytetoLCD:
  extract high nybble
  GOSUB sendnibble
  extract low nibble

Sendnybble:
  ;output the nibble
  RETURN

Allowing the user to create code with errors and then debugging the resultant code is a part of the normal lifecycle of a program. It's all part of a cycle of
-definition,
-flesh-out (flow chart or whatever on paper),
-code,
- test,
- debug and modify,
-test again until correct else go back a step,
-document, and of course
-BACKUP, BACKUP and BACKUP again during the code/test/debug/modify phases.

IMHO, trying to make it impossible to create an error is removing some of the learning process.