Proposal: extension of SETINT command and functionality

[kranenborg]

The current implementation of the SETINT command implictly assumes an "AND" condition on the inputs as specified by the "mask" (subject to the input conditions as prescribed by the "input" variable/constant) for the interrupt routine to be called. I think this choice has serious drawbacks for the following reasons:
1) Interrupts are mostly asynchronous by nature, so in general {condition xxx OR condition yyy} should trigger an interrupt, not {condition xxx AND condition yyy}.
2) To implement 1) (i.e. the OR) external components (diodes) are necessary -even in the most simple situations, plus an extra interrupt input pin has to be sacrified. (i.e. 3 input pins for 2 "ORed" interrupts), which counts heavily on the 08/08-M.
3) The retrieval of information on which input pin(s) caused the interrupt currently needs to be done by one or possibly even two separate BASIC commands, causing a relatively long time delays, whilst an interrupt service routine should be as quick as possible
4) The implicit AND approach is incompatible with other processors (Basic Stamp for example)

I therefore propose the following backward-compatible extension:

SETINT input,mask,AND/OR(opt.),reason(opt.)

where AND or OR describe the condition of the interrupt action (optional keyword, if not present AND is assumed for compatibility), and the "reason" variable contains "1"s on those positions where the corresponding inputs have caused the interrupt (of course in agreement with the settings of both the "input" and "mask" variable/constants ). Again, "reason" is optional for compatibility reasons. Implemented in this way the "reason" variable can be used directly to jump to the appropriate service routines.

Â*

[moey]

I could use those OR interrupts.

I have a project using SETINT to interrupt when either of 2 buttons are pressed (up/down temperature setting). The buttons are diode ORed into a third input.

But there is a small annoying lag between pressing a button and the expected action because the button press first causes the interrupt and then it jumps to the interrupt sub-procedure to read either of the 2 buttons.

With 'OR interrupts' I assume things would speed up a tiny bit since code would execute immediately depending on which button caused the interrupt.
________

[hippy]

I have to agree that the argument is sound. I have not used interrupts which have been anything other than an OR arrangement on a PICAXE. There are uses for AND type interrupts, but they aren't applicable to button handling or for independant interrupts.

An alternative solution might be to allow ...

- SETINT NOT pinValue , pinMask

The interrupt occurs when the input pins masked do not equal the pinValue.

This would have an advantage over choosing between AND or OR operation as initially suggested because it would work with buttons which go active high or active low when pushed, and even a mix of each ...

- SETINT NOT %00000110, %00000111

Interrupts when pin0 goes high, or pin1 goes low, or pin2 goes low. It also has the advantage that existing hardware using diode-mixing would still work with this command.

In the Firmware the test for when an interrupt occurs ...

- IF ( pins AND pinMask ) = pinValue THEN Interrupt

would then simply become ...

- IF ( pins AND pinMask ) <> pinValue THEN Interrupt

Implementing the solution could be interesting as the above check is right in the heart of the Firmware interpreter and any change rather than an addition would break existing software. However, when it comes to downloading, the Programming Editor knows if a SETINT, SETINT NOT or neither were used, and knows the Firmware Version being downloaded to so it can easily indicate if a command has been used which isn't supported by that PICAXE.

Such a change would get my vote.

Storing the pins read when the interrupt was triggered ( in a variable or elsewhere ) would also be advantageous. As it stands now, an interrupt can occur, and by the time the first line of the interrupt ( a 'bVar=pins' usually ) gets executed, the signal which caused it may have disappeared.

[krypton_john]

I'll third that.

OR allows multiple interrups. The implicit AND allows a single complex interrupt. The former is much more useful IMHO.

Cheers,
JohnO

[BeanieBots]

This is now available in the X1/2 product range.