Interrupt query

stevecoulson

New Member
Hi, I am trying to get interrupts to work (again) but have hit a problem. My very simple code looks like this :-

Interrupt:
Low B. 1
If pin C. 1 = 1 then Interrupt
setint %00000100, %00000100
Return

The Picaxe editor does not like the line "If pin C = 1 then interrupt".
It tells me it is a syntax error but that line is taken almost exactly out of the Picaxe manual (page 83 of Getting Started). What am I doing wrong? Thanks in advance. Steve Coulson.
 

stevecoulson

New Member
Aaha. So simple! It downloaded easily after the correction. Many thanks. What is also rather splendid is that the interrupt worked!!! The first time I have ever had any success with them. Hurray!!
stevecoulson
 

stevecoulson

New Member
I think I shouted Hurray a bit too soon. I have got the interrupt to do what it should (get the 14M2 to go into Wait mode) but the interrupt seems to be making the program unstable when the 14M2 comes out of Wait mode and resumes sending signals to the H bridge ( which switches on, off and reverses a small geared motor).
I have inactivated the interrupt command by putting apostrophes in front of the relevant lines and all goes well. Remove the apostrophes, download and the switching becomes unpredictable again. I have done this several times with the same results.
I have tried two 14M2s and they both do the same thing.
I am activating the interrupt on C.1 of the 14M2 which the manual tells me is the right thing to do.
Do interrupts have a malevolent side?
stevecoulson
 

AllyCat

Senior Member
Hi,

Yes, potentially. Firstly the "gotchas", for example that they normally need to be re-enabled within the Interrupt routine, and that they terminate any PAUSE or WAIT instruction (i.e. it is NOT continued after the RETURN). Or the classic, main program "falling into" any type of (sub-) Routine.

More generally, Interrupts make the "Program Flow" much more complex because they may occur at any time and the main program will not be allowed to continue until after their RETURN. That's why the use of long processes, or any delays (PAUSES), inside the interrupt are "Highly Discouraged". You also need to be careful about using the same variables inside and outside of the interrupt routine.

Therefore, I always recommend NOT to use Interrupts (even in my own Programs ! ) unless they are really necessary. In many cases they can be replaced by a simple program "Polling" loop structure, IMHO particular examples to avoid interrupts are: Stepper Motor Drivers, Quadrature (Rotary) Encoders and Multiplexed (LED) Displays, etc. (examples where the Call - Return execution time also may be significant). However, we may need to see your actual Program/Code to identify the most likely cause.

Cheers, Alan.
 

stevecoulson

New Member
Hi,

Yes, potentially. Firstly the "gotchas", for example that they normally need to be re-enabled within the Interrupt routine, and that they terminate any PAUSE or WAIT instruction (i.e. it is NOT continued after the RETURN). Or the classic, main program "falling into" any type of (sub-) Routine.

More generally, Interrupts make the "Program Flow" much more complex because they may occur at any time and the main program will not be allowed to continue until after their RETURN. That's why the use of long processes, or any delays (PAUSES), inside the interrupt are "Highly Discouraged". You also need to be careful about using the same variables inside and outside of the interrupt routine.

Therefore, I always recommend NOT to use Interrupts (even in my own Programs ! ) unless they are really necessary. In many cases they can be replaced by a simple program "Polling" loop structure, IMHO particular examples to avoid interrupts are: Stepper Motor Drivers, Quadrature (Rotary) Encoders and Multiplexed (LED) Displays, etc. (examples where the Call - Return execution time also may be significant). However, we may need to see your actual Program/Code to identify the most likely cause.

Cheers, Alan.
Thanks Alleycat, I have learnt quite a bit today about interrupts from your reply and further reading about PICs. The main thing I have learn is "don't use interrupts". In fact I have got the set-up to work well with just an "If....Then" statement. A lesson we'll learnt. Thanks again. stevecoulson.
 

papaof2

Senior Member
Interrupts do have their place but like other powerful tools, you must use them with caution ;-)

Several years ago I used a water flow device from a Maytag clothes washer to build a "gallons used in irrigation" meter. The flow device used a spinning vane with imbedded magnet(s) and the magnet was sensed by either a reed switch or a Hall effect device (been too long and I don't remember the pulses/gallon). Anyway, the pulses from the flow device were every 0.x gallons so I checked time and counted pulses to get the amount of water used over time. Each pulse triggered the interrupt which incremented a counter, compared the counter value to the number of counts in a gallon, updated the gallon counter and cleared the pulse counter (if appropriate), then reset the interrupt to wait for the next pulse and the PICAXE went back to counting minutes. That worked for the relatively low flow levels I was using for drip irrigation. I'd probably need a much faster PICAXE if tracking the 11 gallons/minute from one or more of the rotating sprinkler heads ;-)
 

inglewoodpete

Senior Member
The main thing I have learn is "don't use interrupts".
Perhaps that statement is a bit strong. I use interrupts in practically every PICAXE application that I write.

The difference between my philosophy and Alan's is that we tend to use different PICAXE chips. I rarely use M2 chips and, by his admission, Alan rarely uses the X2s. (We're working on him, though ;)).

I just checked my last two M2 projects and neither uses interrupts. The main reason I avoid using M2 chips is due to their lack of timer interrupts (and the ability to time regular short periods). Generally, you have to use a pause command, which stops the chip from doing other sthings.

With (i2c and async) peripheral hardware accessing the scratchpad in background execution, along with programmable timer interrupts, the X2 chips have a greater need for using interrupts. Due to these background events, comms and timers often need prompt attention, usually best performed through interrupts. There is much less need for the Pause command in an X2 when using timer interrupts. And if you use a timer interrupt instead of a pause command, interrupts won't cancel the pause time(!).

In my opinion, one of the best uses for a timer interrupt is to debounce button presses (Eg period = 100mS) and to discriminate between short and long presses of a button (a count of multiple 100mS interrupts), allowing two functions with one input.

So, back to the original statement: "don't use interrupts". I'd say "don't avoid interrupts". Use them and learn how they can work for you.
 
Top