Interrupts prematurely cancelling pause and waits - fix on the horizon?


New member
Does anyone know if there are any plans to resolve the issue with prematurely cancelling pause and waits on interrupt? I have a work around by defining a subroutine with a 100mS pause in a loop, which is OK for me. I problem is that I teach young students using the PICAXE platform and this is a complication they really don't need.


Senior Member
It has been a 'feature' for a long time. I don't think there are any plans to change the handling of an interrupt during a pause (or, should I say "resuming a pause after an interrupt"). I avoid using the 'pause' command almost as much as I avoid the 'goto'. There are better ways of programming but I can understand the challenge this brings when teaching young students.


As IWP has indicated above, it is more a case of a documented feature.
see note 4

Accordingly, no “fix” has ever been considered.

The usual recommended method for those who do have pauses of extended duration has been, as you have mentioned, to place a shorter pause period within a loop to achieve the desired overall delay.

Consider the case where someone sought a pause of a very specific length - let’s just say 1 second.
Now an interrupt is introduced into the equation.

How long will the interrupt take to execute.
Ideally and recommended is the the INTERRUPT routine performs minimal actions and rather is used to set a flag to indicate to the main code that an Interrupt event has occurred. In this case the Execution of entire interrupt routine may be completed in say a few milliseconds.

However, other folks include the code for the entire reaction to the interrupt event within the interrupt subroutine.
Now there is the extended time for performing some maths and maybe a serial communications to a display so the total time may now be approaching that 1 second.

Therefore the question would be: how much time from the original pause must be allowed to complete the task to retain the original timing?

For those who use a loop and a short pause duration AND perform minimal tasks within the INTERRUPT routine then the overall sought timing will remain relatively close.

However, for those who include a lot of tasks within the interrupt routine then, it may be a case where the resultant overall timing is in fact extended beyond the original sought 1 second.


New member
Thanks guys. What you say makes sense. I think I would have opted for letting the delay run its course and if the interrupt routine hadn't been written to exit extremely quickly, then that would have been the coders problem, rather than just cancelling the delay. Although I suspect there is a good reason behind cancelling the delay instead and this was a conscious design decision. At least I have a valid reason to tell the students now which is excellent. It would be good to update the user manual with the reasoning behind cancelling delays, so others don't assume it is just a bug.


Senior Member
Since @Technical has not weighed in on this discussion I'll say the following, which often influences how technologies evolve (or don't evolve).

The early PICAXEs were designed and built at a time when the concept was emerging and the raw chips were comparatively more expensive, often offering less features. Firmware space, program space and RAM were in short supply (just look at the features of the original PICAXE 08, 18 and 28). Coding to have an interrupt return to an ongoing pause statement could easily take code and storage space that was better used for other features or commands. The entire PICAXE range, while adding more and more features and capability, has an amazingly consistent command behaviour over all models since it inception. The pause-vs.-interrupt struggle is one that has behave consistently since interrupts were first introduced.

I, too, have been 'caught out' with pauses and interrupts at least a couple of times over the years. Perhaps we can hope for another "pause" derivative (we already have pause, pauseus, wait and sleep), that allows execution to return to complete a pause when an interrupt terminates. We may have to wait for the M3 or X3 models for that! But let's think about all possibilities: what would happen if the pause should keep ticking in the background and completes its time span while the interrupt routine is executing? A new type of anomaly would be revealed.


Senior Member

It's relatively easy to divide a long PAUSE into a number of sub-Pauses, to ensure a minimum total PAUSE time, but the additional instructions will extend the assumed Pause time (unless compensated-for) by a small amount. Furthermore, if the approximate execution time of the Interrupt is known, then the "sub-Pause loop counter" could be decremented accordingly, to achieve a more consistent overall delay time. That could be written as a "System Macro" within PE6 (there are lots of similar Macros, like BINTOASCII), but very often I prefer to write my own functions anyway, to be faster, more compact or to suit the application better.

Also, IMHO using PAUSE is rather "poor" (or perhaps "lazy") programming, but the PICaxe execution speed and architecture does rather encourage it. For example, it's much easier to write PAUSE 5 than to construct code to test if an external serial EEPROM has completed its WRITE cycle (which it probably will have done anyway, by the time the "checking" code has completed its execution). Ideally, one could, or should, check the progress of time from a local "clock" and indeed the TIME variable (PICaxe M2s only) is available (and should be used) for "long" (many seconds) Pauses. It's also possible to check "short" delays (up to 20ms), by using the "Timer 1 SFR" as I demonstrated in a recent Code Snippet.

But sadly there is no (Programmer) access to the "pre-scaler" (divide by 50 counter) between Timer1 (overflowing) and the TIME variable (background counter). If there was any simple "update" planned for the PE or M2/X2 chips, that's what I'd vote for. ;)

Cheers, Alan.


Senior Member
I have been moving a project from PICAXE to teensy, and while working on that I have found that being able to access the running clock to be helpful.
Its essentially the same as Allycats' suggestion and consists of reading the time, storing it, then reading and comparing to to the time that is needed.

A surprisingly good example is the "Blink without delay" example on the arduino site.
the millis() command in arduino, the ARM_DWT_CYCCNT register on the teensy 4 is the same as peeking the timer 1 sfr on PICAXE. Although the teensy register spits out how many clock cycles has past instead of the time, but the built FPU can be used to calculate that easily enough