Interrupt sequence
- Thread starter russbow
- Start date
As expected; you can indeed set a flag variable inside the interrupt and then check that flag within the main program code and go to main when set, or you could issue a RESET command within the interrupt.
Perhaps describe what you are trying to achieve and the reasoning for that and members may be able to find the best solution for what you need.
Perhaps describe what you are trying to achieve and the reasoning for that and members may be able to find the best solution for what you need.
You're quite right Hippy - not enough detail.
I have a program that measures temperature, humidity and air pressure and writes the results to external eeprom at pre-set intervals. Currently I interrogate the eeproms by re-programming the picaxe ( 20m2 ) with a simple " get the data and sertxd it " routine. All works fine.
The downside is that I have to re-install the original program to continue recording.
I considered the "get the data" routine could be put in an interrupt, controlled by a push button, but the return point would be anywhere within the main prog and that would screw up the logging sequence.
I need to go back to probably the Init: label prior to the main: label to ensure the whole process kicks off from the start.
I like the reset suggestion. Maybe needs trying
I have a program that measures temperature, humidity and air pressure and writes the results to external eeprom at pre-set intervals. Currently I interrogate the eeproms by re-programming the picaxe ( 20m2 ) with a simple " get the data and sertxd it " routine. All works fine.
The downside is that I have to re-install the original program to continue recording.
I considered the "get the data" routine could be put in an interrupt, controlled by a push button, but the return point would be anywhere within the main prog and that would screw up the logging sequence.
I need to go back to probably the Init: label prior to the main: label to ensure the whole process kicks off from the start.
I like the reset suggestion. Maybe needs trying
Bolting an interrupt onto an existing program that wasn't designed to integrate with interrupts is often not a good solution, as it leads to (apparent) needs just like you (think) you have.
A "proper" (flame suit on) program design is
Init: do one off init stuff
DO
do normal program stuff
read flags set by interrupt and do other stuff depending on what they say
LOOP
Interrupt: Set flags
...not a goto/false return to someplace else/jump back to the original init/RESET the processor in sight
Also, personal opinion, attaching interrupts to buttons is a Bad Idea (tm) but PICAXE often forces you to do that as it doesn't have enough different, or fast enough, interrupts to do "normal" button processing in microcontroller apps via fairly fast (say 5mS) timer interrupts, polling button states, debouncing in software (using vertical counters for extreme speed), and setting button-related flags for the main loop to deal with.
Maybe worth revisiting your overall program design - 95% of you code will be unchanged, you'll just be changing the high level structure
A "proper" (flame suit on) program design is
Init: do one off init stuff
DO
do normal program stuff
read flags set by interrupt and do other stuff depending on what they say
LOOP
Interrupt: Set flags
...not a goto/false return to someplace else/jump back to the original init/RESET the processor in sight
Also, personal opinion, attaching interrupts to buttons is a Bad Idea (tm) but PICAXE often forces you to do that as it doesn't have enough different, or fast enough, interrupts to do "normal" button processing in microcontroller apps via fairly fast (say 5mS) timer interrupts, polling button states, debouncing in software (using vertical counters for extreme speed), and setting button-related flags for the main loop to deal with.
Maybe worth revisiting your overall program design - 95% of you code will be unchanged, you'll just be changing the high level structure
inglewoodpete
Senior Member
A couple of years ago, I wrote a similar application. The download of the data occurs at bootup (ie first up), so no special download process is required. A button can to clear the EEPROM, which ends with a restart. No need for interrupts.
Thanks for the suggestions. I can only find reference to setintflags, but they are only relevant to X parts.
As the main loop is quite slow, I think the " Loop Until interruptFlag = 1 " will only save me keeping the button pressed until " if c.1=1 ".
I think I quite like the RESET within the interrupt, and will initially try this.
I like IWPs suggestion of a data dump at switch on as well, but that means I've got to ensure the prog lead is connected first.
Thanks for your help. Clearly what I want can't be done.
As the main loop is quite slow, I think the " Loop Until interruptFlag = 1 " will only save me keeping the button pressed until " if c.1=1 ".
I think I quite like the RESET within the interrupt, and will initially try this.
I like IWPs suggestion of a data dump at switch on as well, but that means I've got to ensure the prog lead is connected first.
Thanks for your help. Clearly what I want can't be done.
Last edited:
inglewoodpete
Senior Member
On re-reading my post #5, it is not the clearest. I'll try again.
The EEPROM is "formatted" to initialise it to all zeros. The data written to the EEPROM should be written as fixed length records, with a non-zero value in the first byte of each record (Eg the first byte of a date value). So the end of recorded data can be found when required via a subroutine (Eg at boot up) by stepping the pointer by <recordlength> until a zero byte is found.
At boot up, immediately check for a button being held. Record the state of the button, then dump the available data from the EEPROM every time. At the end of the dump, if the button had been pressed at startup, clear the EEPROM, then go into the main periodical data recording routine.
No fancy interrupts or restarts required. If you want to dump the data or clear the EEPROM, restart or power cycle the PICAXE.
The EEPROM is "formatted" to initialise it to all zeros. The data written to the EEPROM should be written as fixed length records, with a non-zero value in the first byte of each record (Eg the first byte of a date value). So the end of recorded data can be found when required via a subroutine (Eg at boot up) by stepping the pointer by <recordlength> until a zero byte is found.
At boot up, immediately check for a button being held. Record the state of the button, then dump the available data from the EEPROM every time. At the end of the dump, if the button had been pressed at startup, clear the EEPROM, then go into the main periodical data recording routine.
No fancy interrupts or restarts required. If you want to dump the data or clear the EEPROM, restart or power cycle the PICAXE.
inglewoodpete
Senior Member
As boriz noted below, I posted twice.
The first time, I got a message from the webpage (something like) "You are leaving the webpage without sending?/saving? your input...". I assumed I'd clicked on the wrong control so clicked on "Post Reply". Obviously, I had already clicked on "Post Reply" but the script had had a hiccup.
The first time, I got a message from the webpage (something like) "You are leaving the webpage without sending?/saving? your input...". I assumed I'd clicked on the wrong control so clicked on "Post Reply". Obviously, I had already clicked on "Post Reply" but the script had had a hiccup.
Last edited: