More interruptions..

[rolfi@tisco.no]

In manual2 (vs. 6.09 06/2009), the description of the SETINTFLAGS on p. 184, states that this is a so-called "polled interrupt", and further on: "It is the only type of interrupt available in the PICAXE system."

On the other hand, on p. 69 (Hintsetup for X2 chips) we find this:"The hardware interrupt pins (INT0, INT1, INT2) constantly background monitor for an edge based trigger. As they operate in the background the PICAXE program does not have to poll the input to detect a change in state.... The hardware interrupts are triggered and processed extremely quickly."

To me, the latter sounds like a real interrupt, which might interrupt - let's say - a pending serin-cmd. Can technical please verify or clarify this?

 

[hippy]

All interrupts are "polled" which in PICAXE terms means they are checked between each command line to see if an interrupt condition exists and if so a GOSUB to the 'Interrupt:' routine is invoked, the RETURN takes it back to where it was.

For software interrupts ( SETINT ) the interrupt condition must exist at the time it is checked so short pulses may not trigger an interrupt if they occur while a command is being executed. If the pulse is gone before the PICAXE is between commands no interrupt will be seen.

What the hardware interrupts do is set internal flags as soon as the interrupt condition occurs so pulses and other conditions are not missed and then these flags are checked ( or "polled" ) between commands to determine if there has been an interrupt condition. Thus it's not a "real interrupt" where control immediately passes to 'Interrupt:', no matter what, but deferred interrupt.

 

[rolfi@tisco.no]

Again thanks a lot for a swift answer, hippy, it was indeed clarifying!
I must, however, admit that it was not what I hoped to hear, but may be real interrupts are extra hard to implement in an interpreted, non-compiled system...

 

[hippy]

The main problem is what to do about interrupts which occur in things like COUNT commands which have to be bit-banged; any immediate interrupt, especially entering the "Interrupt:" routine, may destroy the validity of the result obtained, an INFRAOUT won't generate the correct output and INFRAIN won't receive the correct data if an interrupt occurs within them and so on.

Dealing with interrupts can be problematic enough when you have native instruction control of a processor and it becomes even more complicated for a general purpose, interpreted micro system. It's one of those areas where one has to somewhat compromise to maximise overall usefulness which may not be as perfect as would be liked in specific cases.