PORT B edge trigger in interrupts
Keith M
Posts: 102
Can anyone tell me why my "if" statement is failing below?· I'm generating a good pulse, and I'm positive the interrupt is firing as a result of the edge trigger.·I've disabled the RTCC interrupts, so I know·the ISR is triggered as a result of the edge.· So the ISR is running, but my simple "if" is failing ---- and I have to be missing something.
I've read the appropriate collateral Daubach text section, Al Williams text, etc.
Here's the setup for port B
Then the ISR code that checks it
The IF here is failing even though I'm positive the only trigger here is RB.0.
Now you see that I grab the inputpin almost immediately, so I can check that to see if its a zero --- this is a possible workaround, but I don't like it.· Time has passed between trigger and sample, and I'd rather not risk missing the EDGE in a worst-case scenario.
I've looked at other example code, in both SX/B and assembly, and they are doing the same thing......
BTW: I also do a
But I don't think this has an effect on my port b edge triggers.
Thanks for any help.
Keith
·
I've read the appropriate collateral Daubach text section, Al Williams text, etc.
Here's the setup for port B
212 =00000075 start_point: ;start_point:
213
214
215 ; 'setup port b
216
217 0075 005F MODE $0F ; TRIS_B=%11111001 'direction bits rb.0 input, rb.1 & rb.2 output
218 0076 0CFA MOV FSR,#__TRISB
0077 0024
219 0078 0CF9 MOV W,#%11111001
220 0079 0020 MOV IND,W
221 007A 0006 MOV !RB,W
222 007B 0018 BANK $00
223
224 007C 005C MODE $0C ; ST_B = %11111110 'schmitt trigger for our drive input
225 007D 0CFE MOV !RB,#%11111110
007E 0006
226
227
228 007F 0059 MODE $09 ; WKPND_B = 0 'clear pending interrupts
229 0080 0C00 MOV !RB,#0
0081 0006
230
231 0082 005A MODE $0A ; WKED_B = %11111111 'set falling edge trigger
232 0083 0CFF MOV !RB,#%11111111
0084 0006
233
234 0085 005B MODE $0B ; WKEN_B = %11111110 'enable drive input interrupts
235 0086 0CFE MOV !RB,#%11111110
0087 0006
236
237 0088 005E MODE $0E ; PLP_B = %11111110 'enable pullups
238 0089 0CFE MOV !RB,#%11111110
008A 0006
Then the ISR code that checks it
80 =0000000E ISR_Start: ;ISR_Start:
81
82
83 000E 0061 CLR RTCC ; RTCC = 0
84
85 000F 0526 SETB RB.1 ; RB.1 = 1 'for debugging
86
87
88 0010 0706 MOVB samplepin,inputpin ; samplepin = inputpin 'grab the pin
0011 042C 0606 052C
89
90
91 0014 006F CLR pending ; pending = 0
92
93 0015 0059 MODE $09 ; wkpnd_b = pending 'is this an edge or a rollover
94 0016 020F MOV !RB,pending
0017 0006
95 0018 002F MOV pending,W
96
97
98 0019 0C01 CJE pending,#1,processedge ; if pending = 1 then processedge
001A 008F 0643 0A2C
The IF here is failing even though I'm positive the only trigger here is RB.0.
Now you see that I grab the inputpin almost immediately, so I can check that to see if its a zero --- this is a possible workaround, but I don't like it.· Time has passed between trigger and sample, and I'd rather not risk missing the EDGE in a worst-case scenario.
I've looked at other example code, in both SX/B and assembly, and they are doing the same thing......
BTW: I also do a
' turn on interrupts OPTION = $88
But I don't think this has an effect on my port b edge triggers.
Thanks for any help.
Keith
·
Comments
What bank is pending in? Another suggestion, just do
and W,#0x01
jnz pending
Also, option $88 puts the RTCC in location $01, which you want, and assigns
the prescaler to the WDT,· but enables the RTCC increment on instruction clock.
To disable the RTCC interrupt you need $c8.
The other thing you can do is set a breakpoint·at mov pending,w so you can see what·value is in pending, and single step though the compare and jump.
Mike C
Post Edited (Michael Chadwick) : 3/17/2005 5:40:02 AM GMT
What Michael said, but in SX/B lingo...
Change the if to "if pending.0 = 1 then processedge"
and change "OPTION = $88" to "OPTION = $C8"
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.sxvm.com
·
Yeah obviously when I said before that I disabled the RTCC(to be sure the edge was triggering), OPTION was $C8, not $88 as it is currently.
Bean: I didn't think about just testing the bit, but shouldn't "if pending = 1 then processedge" be the same thing? I don't have any other bits on port B set to be edge triggered, only bit 0, and so shouldn't WKPND_B contain %00000001 when triggered? I guess I really don't know what "unused" bits would be set at --- but I know I clear it with a WKPND_B=0 during the setup phase. I suppose the only other possibility might be %11111111 when the trigger is active...... which I haven't tried. I guess doing anything other than just checking the bit is irresponsible/bad form because it would break if another section of code decided to start using the 2nd bit or something.
I haven't used the debugger yet, mainly because I think I read of some limitations ---- like you can't run at 50mhz, etc. If I could get the value of pending right before the JNZ, I'd be golden. I was going to write in my original message, "if I could just do a printf("%d", pending); to the console, I'd be alright."
I've found in the C/C++ world anyways that debuggers aren't all they've cracked up to be, mainly because there are so many high level constructs and so many language/code optimizers that viewing asm is not very productive. Most of my "debugging" consists of printf's checking variables, etc.
With the SX, I'm guessing since things start pretty low-level that they are considerably more useful, that is, IF you can use them without any big restrictions. Is the SX debugger actually useful? [noparse]:)[/noparse]
Thanks.
Keith
OMG the debugger is very useful. The frequency range of the SX-Key is 300KHz to 100MHz, so you can debug at that frequency range.
You can add at WATCH for pending and then just put in a BREAK before the IF.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.sxvm.com
·
If I can get the debugger running, it'll be interesting to see what the other bits in WKPND_B are actually doing. If my "IF" was failing, then they couldn't have been all zeros.......I'm betting all ones because it would be consistent (I hope!) across all unused bits.
Betcha "if pending = 255 then processedge" would work.... where 254 is no trigger and 255 is trigger.....
Keith
Is the debugger useful? It's only one of the most useful features of the SX chip! One of the key strengths of the SX is that it has built in, full speed debugging support that can be accessed from the SX-Key and the IDE. You can set a breakpoint, run the chip at 50 MHz, and it'll stop on a digital dime. Very cool stuff.
As for not using a debugger in C/C++, I think you're missing the boat there as well. I program a ton in MS Visual Studio and the debugger is my best friend. There's no reason to look at the assembly output of a compiler unless you suspect a problem with the compiler's code generation, and every quality C/C++ debugger lets you debug at the source level.
Some of the best programming advice I ever read was to single step through every single line of code you write. Everyone always freaks when they hear that becuase they think that it'll take too long. Try it and see. I do it with every project I write. If you step though all the code you write and use the debugger to check out the value of all your variables as you go, you'll find all sorts of bugs right away. You'll also find that you start writing better code the first time out because you start to develop a sense of what your weaknesses are as a programmer.
Anyway, take the time to use the SX-Key debugger and find out how much cooler it is to debug when you can see and change the value of any memory location or register in the chip.
Thanks, PeterM