Program mode switching

M

mikie_121

Member
Is there an easy way to continuously monitor a single input and jump to a different section of code and stay there?

I understand the interrupt subroutine, but that is the problem: it's a subroutine and when it finishes it jumps back to where it was before the interrupt occurred. I don't want to go back, I want to start executing different code and stay there until the button is pressed again.

Eg:

Mode 1 runs on powerup.
Mode button is pressed, Mode 2 runs.
Mode button is pressed, Mode 3 runs.
..
..
..
Mode button is pressed, Mode 1 runs.

Thanks
 
D

Dippy

Moderator
You can still use interrupt surely? It would be the easiest way to pick up brief button presses.

Your interrupt routine would increment a variable , maybe called MyMode. It then pops back your main code.
And the main routine could control where your code went with a conditional.
You can switch Interrupt on/off whenever sutiable.

Or, forget interrupts and have your routines in loops and test for button press. Don't forget to test for button release too. When I've done button presses in the past I've arranged my detction code to detect a press but not do anything until button released - like cocking a gun and then firing it.

My poor brain never got to grips with the 'button' command. Maybe you can suss it and tell me.
 
T

Texy

Senior Member
Use a flag to set the mode level, increment the flag on exit of the interrupt, then check the flag in the main loop of the program. Are you even using interrupts? What does the main program do?

Texy
 
J

Jeremy Leach

Senior Member
I was reading a post in the code section by Hippy last night (which I can't locate now!) that seemed to suggest you could get to the internal Stack. So I wonder if there's a way of 'removing' the return address off the stack after interrupt, and then simply goto wherever you want at the end of the interrupt routine instead of returning? Might be a question for Hippy ;)
 
Last edited:
D

Dippy

Moderator
With resepct to people new at this: why turn something so simple into something difficult?

Texy: Like what I said in Post#2 para 2 ;)
I thought the Forum had gone into echo..cho..cho mode like it does often.
 
T

Texy

Senior Member
Dippy said:
With resepct to people new at this: why turn something so simple into something difficult?

Texy: Like what I said in Post#2 para 2 ;)
I thought the Forum had gone into echo..cho..cho mode like it does often.
Click to expand...
look at the timing tho - we were clearly typing at the same time:D

Texy
 
D

Dippy

Moderator
I was just kidding you. It happens a lot. Especially when a thread reaches Nesbiticity and no-one is going to read pages 3 and 4 when the thread is 10 pags long.
 
J

Jeremy Leach

Senior Member
Yes, except letting the main program branch isn't necessarily good enough. For instance you might not want the main program to execute ANY more commands .....it might do something that will ruin data just received that lead to interrupt etc ... so checking now and then in the main code might not be sufficient. The only real way of aborting is to not return from the interrupt.
 
S

SD2100

New Member
Jeremy Leach said:
The only real way of aborting is to not return from the interrupt.
Click to expand...
Here's a quick and dirty way to not return from the interrupt, it's not the right way to do it but it resets the program counter to zero and clears all variables instantly. I've been using this for a long time on 08m's with no problems but if you want to retain variables you have to save them to eeprom before the restart. I'd like to see Hippy's gosub stack thing though...

Code: 
interrupt:
'do something here
poke $0A,0: poke $02,0 'restart program
 
J

Jeremy Leach

Senior Member
Now that's a good solution, because it truly aborts ! I like that, and yes, can just use EEPROM for anything important on startup (with a branch routine to GOTO if necessary).
 
J

Jeremy Leach

Senior Member
"I don't want to go back, I want to start executing different code and stay there until the button is pressed again"

Yes, you might be able to just set a flag and return and then check for the flag, but I still think this reset solution is the only one so far that allows a way of 'aborting' the main code completely and doing something else.

As an example .... say you were half way through updating a display when you press a button which fires the interrupt. You now want to display something entirely different and DONT want to then return to finishing off displaying the original thing. So instead you set an eeprom jump variable, poke to reset, the startup routine collects the eeprom variable and jumps to the new routine. I think this is a nice solution.
 
Last edited:
D

Dippy

Moderator
Oh, so slow.... :)

I've done a very similar thing on PIC but with event trapping rather than input interrupts.
 
D

Dippy

Moderator
I was thinking of something along these lines.

Did it in hurry and get muddled with Syntax as was originally done in different language.
It's me age you know..

Anyway, the interrupt modifies variables/flags and the main prog does the 'distribution' i.e. selects the routine. If I've got 'wrong end of stick' as to what was required then OOPS. And I forgot to reset interrupt, but you get the idea.
 

Attachments

M

mikie_121

Member
Back from 'death boredom' :)

Thanks to all of the fantastic ideas.

I will definitely try the 'abort' code with an EEPROM check and case jump. I have done C coding on a plain 16F819 and I didn't realise we could access SFR's (special function registers) from the Picaxe code. Oh a world of possibilities just opened up...

Mikie
 
You must log in or register to reply here.
Top