Interrupt Subroutines
John Couture
Posts: 370
I think I understand how interrupts work but I'm having difficulty calling a subroutine later in the program.· In other words, readI2C below is a subroutine that reads from an I2C RTC (these are borrowed Jon Williams MEMOUT and MEMIN routines).· temp4 is just the memory location.
Error given by the compiler is:·"Invalid number of Parameters"
writeI2C is going to give me trouble too.
It seems odd that you have to declare the SUB calls AFTER the Interrupt declaration which may be why the compiler does not like those subroutine calls.· I need to use the read and write routines later in the program also so moving them before the Program Start does not solve the problem.
'
· INTERRUPT
'
ISR_Start:
· ·if Sensor = 0 THEN
····· for temp4 = 0 to 10
········ lcdChr = readI2C temp4
········ writeI2C temp4 + 20
···· ··· pause 1
····· next
····· SOUND Piezo, 80, 200 ' Audible Alert to say ready to get started
····· pause DelayForBounce
···endif
RETURNINT ' {cycles}·
'========
·· PROGRAM START
'========
readI2C·· SUB 1·····
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
Error given by the compiler is:·"Invalid number of Parameters"
writeI2C is going to give me trouble too.
It seems odd that you have to declare the SUB calls AFTER the Interrupt declaration which may be why the compiler does not like those subroutine calls.· I need to use the read and write routines later in the program also so moving them before the Program Start does not solve the problem.
'
· INTERRUPT
'
ISR_Start:
· ·if Sensor = 0 THEN
····· for temp4 = 0 to 10
········ lcdChr = readI2C temp4
········ writeI2C temp4 + 20
···· ··· pause 1
····· next
····· SOUND Piezo, 80, 200 ' Audible Alert to say ready to get started
····· pause DelayForBounce
···endif
RETURNINT ' {cycles}·
'========
·· PROGRAM START
'========
readI2C·· SUB 1·····
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
Comments
'
INTERRUPT
'
· GOTO ISR_Start
'
readI2C SUB 1
'
ISR_Start:
· if Sensor = 0 THEN
··· for temp4 = 0 to 10
····· lcdChr = readI2C temp4
····· writeI2C temp4 + 20
····· pause 1
··· next
··· SOUND Piezo, 80, 200 ' Audible Alert to say ready to get started
··· pause DelayForBounce
· endif
RETURNINT ' {cycles}
'========
PROGRAM START
'========
readI2c:
' put code here
RETURN
P.S. You don't give a complete program, but it is considered "bad form" for have delays in an interrupt routine. Normally you want the interrupt routine to be as fast as possible.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com
"I'm a man, but I can change, if I have to, I guess"
Red Green
Post Edited (Bean (Hitt Consulting)) : 9/29/2005 10:53:01 AM GMT
The SX/B template has the SUB statements after the PROGRAM START and here you have them before the Program Start. Is there any advantage / disadvantage to either technique?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
PROGRAM must be in the first code page, and SUBs must be in the first half of a code page. So as long as PROGRAM and SUBs come before any length of code your okay. Really the only code you should have is the GOTO ISR_Start.
When in doubt follow the Jon's template.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available now... SX-Video OSD module $59.95 www.sxvm.com
"I'm a man, but I can change, if I have to, I guess"
Red Green
·
I would actually go so far as to say that delays in interrupts are verboten. The whole idea of an interrupt is that no matter what is happening in the main code (polling, sleeping, executing, etc), the interrupt will always be executed as soon as an interrupt occurs. If you need pauses, they go in the main code since the interrupt will then be able to handle whatever problem needs attention right away, even if your main code is busy in a delay. If you put delays in your interrupt handler, you basically defeat the entire purpose of the interrupt.
I know you have already explained why you had the pauses, but I just wanted to clarify that delays in interrupt code aren't just bad form but actually something you should never do.
Thanks, PeterM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College
P.S.· I have no clue what I'm talking about.
Post Edited (Lord Steve) : 10/5/2005 2:24:16 PM GMT