Working With Interrupts

Some platforms have a number of I/O lines that can work as interrupt inputs. To enable a particular interrupt line, select it using the io.intnum property and enable the line with the io.intenabled property:

Tibbo BASIC

							'enable interrupt line #0
							io.intnum=PL_INT_NUM_0
							io.intenabled=YES
						

Once the line has been enabled, a change in this line's state will generate an on_io_int event. The linestate argument of this event is bit-encoded: each bit of the value represents one interrupt line. For PL_INT_NUM_0, the corresponding bit is bit 0, for PL_INT_NUM_1 bit 1, and so on. A particular bit of the linestate argument is set when a state change (from LOW to HIGH or from HIGH to LOW) has been detected on the related interrupt line. The event handler for the on_io_int event can then determine what triggered the interrupt:

Tibbo BASIC

							sub on_io_int(linestate as byte)
							   'check if it is the interrupt line #0 that has caused the interrupt
							   if (linestate and &h01) <>0 then
							      'yes, interrupt has been triggered by the interrupt line #0
							      ... 
							   end if
							end sub
						

Please note that the word "interrupt" is used here in a somewhat loose sense. On traditional microcontrollers, an interrupt line status change causes a near-instantaneous pause to the execution of the main code and a jump to an "interrupt routine." Hence, the term "interrupt" — the execution of the main code gets interrupted.

With the io. object, the interrupt line state change does not disrupt the execution of any event handler or trigger the reordering of pending events in the event queue. The on_io_int event is added to the end of the event queue and is not handled until all earlier events are processed. Therefore, nothing is actually interrupted. Note that there is also no guaranteed interrupt response speed here — the time between line state change detection and the execution of the on_io_int event handler depends on the number of prior events waiting in the queue and, hence, cannot be predetermined with any certainty.

Further, there may be only one on_io_int event waiting in the event queue. Another such event will not be generated unless the previous one is processed (this prevents an event queue overflow). Therefore, some short-lived state changes may remain undetected.

Bottom line: The "interrupts" of the io. object should be viewed as a more-convenient alternative to the programmatic polling of the I/O lines.

Note that interrupt line names, such as PL_INT_NUM_0, are defined by the pl_int_num enum, which is platform-specific. The declaration of this enum can be found in the your device's platform documentation (for example, the EM1000's is here).