When the program returns from the interrupt

208	PICAXE Microcontroller Projects for the Evil Genius

' === Directives ===
#com 4 ' specify com port #picaxe 20X2 ' specify compiler mode #no_data ' save time downloading #no_table
' save time downloading #terminal 19200 ' open terminal window

' ============================= Begin Main Program ============================= setfreq m16 ' set frequency to 16MHz
dirsB = %11101111 ' configure pinB.4 as input
dirsC = %10111111 ' configure pinC.6 as input
pullup %00000010
' enable internal pullup on C.6 adcsetup = %0100000001000000 ' see "adcsetup" in Manual
compsetup %0101010101, 0 ' see "compsetup" in Manual
setintflags %00010000,%00010000 ' see "setintflags" in Manual

Chapter 15 I

select case key ' decode key

case < 364 : char = 65 ' A

case < 476 : char = 57 ' 9

case < 502 : char = 85 ' U

case < 733 : char = 53 ' 5

case < 804 : char = 52 ' 4

sertxd ("key = ",char,cr,lf) ' display keypress on terminal

sound horn,(50,20) ' beep

The slow rate at which the LED toggles enables the program to demonstrate two important
characteristics of interrupts. If you press a key shortly after the LED changes state, you’ll notice that it again changes state the instant the key is released. From this program behavior, you can deduce both of the characteristics I have in mind. First, the interrupt condition (C1 output change) is checked for continuously during the wait statement (this is also true for pause statements). Second, when the program returns from the interrupt, it does not complete the wait (or pause) statement; it

Project 15
A Simple MPD Operating System

	I	Approximately 80 percent of 20X2 memory

I All user-developed programs have access to the

interrupt-driven keypad input.

Over 10 Million Study Resources Now at Your Fingertips