Interrupt routine with SX-SIM
Chet
Posts: 150
I have been trying to test the attached routine with SX-SIM.· When I click on the RB.0, I have to release it before the program goes further.· If I re-click it very quickly then the program seams to work correctly.·· The RC port is used to give fedback on the program activity only and will be deleter later.
Questions:
a) will the routine do what it is supposed to do
b) is the sx-sim behavior normal for interrupt handling. (have tried to find it in the documentation, hope I did not overlook it.
Thanks
Chet
Questions:
a) will the routine do what it is supposed to do
b) is the sx-sim behavior normal for interrupt handling. (have tried to find it in the documentation, hope I did not overlook it.
Thanks
Chet
Comments
to be honest, I'm not really an SX/B expert. I took your sample code, and tried it with SXSim. I can confirm that the program seems to "hang" in some waiting state when you activate RB.0 for a longer time.
I then had a look at the assembly code SX/B generated from your source.
The line at label ISR_Start:
WKPEND_B = WhichOne
is translated into
MODE $09
MOV !RB,WhichOne
MOV WhichOne, w
actually, the MOV !RB,WhichOne is a compound statement, so this is the code the SX "sees":
MODE $09
MOV w,WhichOne
MOV !RB, w
MOV WhichOne, w
Now comes the "tricky" part: The MOV !RB, w is not really a move operation but an exchange operation instead. IOW, after this instruction, w holds the former value of !RB (the WKPND_B bits), and the WKPND_B register contains the former value of w.
In this code, WKPND_B will be left with the contents of WhichOne. After the first interrupt, WhichOne contains 1 which is swapped into WKPND_B thus causing another imterrupt immediately after the RETURNINT is executed. This is what makes you think the program is "hanging" somehow. Actually, it is handling interrupts all the time. Look at SXSim's Interrupt Cycles display, to confirm that.
How can this be fixed? In assembly, I simply would insert a CLR w before the MOV !RB,w instruction. In SX/B, the compiler should do it automatically!
Rocklin: We have a problem !!!
At least, I'm happy that this is not an SXSim bug but that I could use SXSim to find it - thanks for the appause .
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
WhichOne = 0
WKPND_B = WhichOne
The SX/B help file states: When assigning values to the special registers [url=mk:@MSITStore:C:\Program%20Files\Parallax%20Inc\SX-Key%203.1\Compilers\SXB\SXB.chm::/sx_aliases.htm]WKPND_B[/url] and [url=mk:@MSITStore:C:\Program%20Files\Parallax%20Inc\SX-Key%203.1\Compilers\SXB\SXB.chm::/sx_aliases.htm]CMP_B[/url] a variable must be used and that variable will be exchanged with the SX register.
So WhichOne is being "Exchanged" with the register contents. So if you leave WhichOne as 1, then that is what will be put back into WKPND_B.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Ability may get you to the top, but it takes character to keep you there."
Post Edited (Bean (Hitt Consulting)) : 1/17/2006 6:56:58 PM GMT
Thanks Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
If i quickly click it again, it gives the correct response of a 1 result, else if I do not "re-click" RB.0 is give the 0 response.
I wil have pull-up resisters on the RB.0 line, so for a single interrupt source that should work.· If I include "· PLP_B = %11111110" or the inverted, I do not get a level 1 in RB.0.· Is ther any way of actually setting RB.0 high and then having the I/O panel take it low?
I will get into the more complicated stuff later, but I am still having fun......
Regards
Chet
The first important matter is taking care that the WKPND_B register is cleared within the ISR, otherwise a new interrupt would occur as soon as the RETURNINT is executed. As Bean suggested, you should add
WhichOne = 0 before WKPND_B = WhicOne.
Right now, I'm not sure if SXSim correctly handles the internal pull-up resistors, i.e. if inputs are assumed having high level when the pull-ups are activated. In addtition, the I/O Panel "buttons" provide a "hard" signal to the simulated inputs, i.e. either low or high, like a SPDT type switch with one end connected to high and the other to low. You can simulate a "pulled up scenario" by right-clicking on a button. This lock it, and the associated input gets high. In order to generate a high-low transition, you left-klick the button to release it again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Thanks
Chet