Hot!A question about interrupts.

Page: << < ..67 Showing page 7 of 7
Author
CVRIV
Junior Member
  • Total Posts : 71
  • Reward points : 0
  • Joined: 2017/09/06 13:49:25
  • Location: 0
  • Status: offline
Re: A question about interrupts. 2017/10/16 05:29:04 (permalink)
0
I'm so tired right now I want to read and understand what you wrote but I can't. Later on I'll have to comb through what you wrote and try to wrap my head around it. 
 
For now it's good enough for what I'm doing. I'm learning interrupts. I'm not trying to start/ keep bad habits. I am reading and remembering everything that everyone is telling me. Next lab I will try and write better code and see what everyone thinks. 
 
Messing around with exact or precise timing is something I might have to do on the side of what my professor needs me to do. I still have many labs to finish for him. What I'm doing is waaaay ahead of everyone else in my class. I'm actually doing a lot more than what he's asking for LOL. 
 
CVRIV
Junior Member
  • Total Posts : 71
  • Reward points : 0
  • Joined: 2017/09/06 13:49:25
  • Location: 0
  • Status: offline
Re: A question about interrupts. 2017/10/16 21:18:30 (permalink)
0
A question about the debounce code for my PORTB momentary switches.

Inside my ISR, the PORTB portion of the code checks if a bounce flag i created is high before even checking if the switches caused the interrupt. If the bounce flag is low the ISR will check which switch caused the interrupt and then execute code for it after setting the bounce flag high.

In my main loop, if the bounce flag is high, a counter is started. When this counter reaches zero, the counter is restored and the bounce flag is cleared. This code decreases the counter when TOIF is high. TOIF goes high ever milisecond. If the bounce flag is clear, this main loop code is skipped.

Does this sound about right?
qhb
Superb Member
  • Total Posts : 5824
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: A question about interrupts. 2017/10/16 22:06:14 (permalink)
+1 (1)
Are you still using change interrupts on PORTB?
The logic is a lot easier to follow if you have a timer interrupt every millisecond (or even every 10 milliseconds), and poll the pins in there.
You can then just wait until you see a stable state on PORTB for "x" milliseconds, simply by counting interrupts.
 
CVRIV
Junior Member
  • Total Posts : 71
  • Reward points : 0
  • Joined: 2017/09/06 13:49:25
  • Location: 0
  • Status: offline
Re: A question about interrupts. 2017/10/16 22:20:07 (permalink)
0
Yes, Im using change interrupts on only 4 of the pins on PORTB. Im using the interrupts for the momentary switches. I have TMR0 interrupting every milisecond.

What do you mean poll the pin in there? The ISR? How do you count the interrupts? I don't follow what your explaining.
qhb
Superb Member
  • Total Posts : 5824
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: A question about interrupts. 2017/10/16 22:54:09 (permalink)
0
CVRIV
What do you mean poll the pin in there? The ISR?

Yes, in the timer ISR.
i.e. disable change interrupts, and only use the timer ISR.
Save the previous state of PORTB in a global variable (ANDed with a mask to remove the bits you are not interested in)
 

How do you count the interrupts? I don't follow what your explaining.

Each time through the interrupt, you can increment (or decrement) a variable. That is "counting interrupts".
e.g.
Assume you have two variables (each is one byte)
        cblock
        old_portb
        debounce_count
        endc

and you have defined a mask of which PORTB bits you are using
SWMASK  equ     B'00001111'     ;switch mask
DBCOUNT equ     10              ;debounce period (#interrupts)

then you could do something like this to detect when no key has changed for ten interrupt cycles:
(note, I'm assuming all variables are in bank 0)
        BANKSEL PORTB
        MOVF    PORTB,W
        ANDLW   SWMASK          ;discard unused pins
        MOVWF   new_portb       ;save for later
        XORWF   old_portb,w     ;check if this is the same as the old value
        skipnz                  ;skip if non-zero
        GOTO    no_change
;here if buttons have changed
        XORWF   old_portb,f     ;update old_portb to match new value
        movlw   DBCOUNT
        movwf   debounce_count
        GOTO    swdone          ;done processing
no_change:      ;here if keys still the same
        MOVF    debounce_count,f
        skipnz
        GOTO    swdone          ;count was already zero, so nothing to do
;here if we are in the middle of debouncing
        DECFSZ  debounce_count,f;dec count, skip if zero
        GOTO    swdone          ;count > 0, so nothing to do yet 
;here if count has hit zero
;....... add code here to do something because a button has just changed
 
swdone: ;all code exits to this point

 
I just type the above off the top of my head, but I hope you get the idea.
The only "trick" I've used is the two XORWF instructions to avoid using a third variable for temporary storage of the new PORTB value
 
 
 
CVRIV
Junior Member
  • Total Posts : 71
  • Reward points : 0
  • Joined: 2017/09/06 13:49:25
  • Location: 0
  • Status: offline
Re: A question about interrupts. 2017/10/16 23:21:22 (permalink)
0
mbrowning
If the only thing the ISR is doing (for a given interrupt) is to set a flag that is handled in the background (main routine), then don't bother with the interrupt and poll the interrupt flag directly in main.


Well the ISR is doing more that just setting a flag. The ISR has a whole block of code for the TMR0 interrupt which is basically a stopwatch. The ISR also has some code specific for two of the momentary switches.

So like I said, in the main loop, TOIF is polled and if my bounce flag is high, a count begins. When the count hits 0, the bounce flag is cleared. TOIF occurs every 1ms.

If the bounce flag is high, none of the PORTB interrupt pins will even serviced. They'll only be serviced if the bounce flag is clear. I have most of the code in place. Almost done.
Page: << < ..67 Showing page 7 of 7
Jump to:
© 2017 APG vNext Commercial Version 4.5