Subject:
Re: [gnupic] problems with timer0/interrupts
From:
"George M. Gallant" ####@####.####
Date:
3 Sep 2008 14:17:55 -0000
Message-Id: <48BE9C5B.6040202@comcast.net>
Lope,
Just a some observations:
1. If you evr do get to hp_interrupt and it is not the change on rb,
you will be stuck here.
2. The time is enabled with setting a value.
3. Perhaps you could recode to use the timer interrupt.
4. Have you tried a simulator?
George
Lope Vega wrote:
> Hi guys,
>
> Thanks so much Robert, first of all. Both your code about table reads worked out of the box, and were also right about my missunderstanding of the variables' thing.
>
> I didn't think of trying to declare it as global and then try to use it in other modules.
>
> I'm having a problem now with interrupts/timer0.
>
> As petter suggested, I've started scanning 3 seven segment displays on my app's main function, while using interrupts to update a counter upon a switch's press/debounce.
>
> Then, what did was to setup interrupts for RB4:7 pins' state change, and within it's processing function, try to use timer0 to debounce the switch.
>
> However, when I program the device and place it on it's side of the breadboard, it seems the pic falls into the interrupt, and that the timer0 polling causes it to recurse into it undefinetely.
>
> I'm gonna paste the relevant part of the code for if anyone want to give me some explanation.
>
> this is my main file:
>
> ;;
> ;; variables
> ;;
> main_vars udata
> ;; main counter
> counter res 1
> ;; temp variables
> digit res 1
> aux res 1
>
> ;;
> ;; imported symbols
> ;;
> extern hp_interrupt
> ;; a table read function, with a `movwf segments_port'
> ;; at the end of it
> extern display
>
> ;;
> ;; exported symbols
> ;;
> global counter
> global digit
>
> ;;
> ;; reset vector
> ;;
> reset_vector code 0x0
> goto main
>
> ;;
> ;; high-priority interrupt vector
> ;;
> _hp_interrupt code 0x8
> goto hp_interrupt
>
> ;;
> ;; app's entry point
> ;;
> main:
> ;;
> ;; ports' setup
> ;;
>
> ;; porta
> clrf porta
> clrf trisa
>
> ;; portb, here I'm supossed to have a switch which is
> ;; active-low, thus, when pressed goes low, and this
> ;; ports' setup seems to be giving me problems also
> clrf latb
> movlw 0xff
> movwf trisb
>
> ;; portc
> clrf latc
> clrf trisc
>
> ;; portd
> clrf latd
> clrf trisd
>
>
> ;; porte
> clrf late
> clrf trise
>
> ;;
> ;; interrupts
> ;;
>
> ;; enable rb pins change interrupt, and it's pullups
> bsf intcon, rbie
> bcf intcon2, rbpu
>
> ;; clear it's flag bit
> bcf intcon, rbif
>
> ;; disable tmr0 interrupt
> bcf intcon, tmr0ie
>
> ;; setup timer0: internal clock, 8 bits, prescale 1:64
> movlw b'01000101'
> movwf t0con
>
> ;; globally enable interrupts
> bsf intcon, gie
>
> start:
> ;; just loop, I acutally have code here for decomposing
> ;; `counter' so I can display it on the segment leds
> ;; (leading 0's not being displayed)
> goto start
>
>
> and this is my `interrupts.s' file:
>
>
> ;;
> ;; variables
> ;;
> int_vars udata
> ;; these for high-priority interrupts
> hp_w res 1
> hp_bsr res 1
> hp_status res 1
>
> ;;
> ;; imported symbols
> ;;
> extern counter
>
> ;;
> ;; exported symbols
> ;;
> global hp_interrupt
>
>
> ;;
> ;; rb* interrupt-handler
> ;;
> _handle_rb_interrupt code
> handle_rb_interrupt:
> ;; clear it's flag bit
> bcf intcon, rbif
>
> ;; clear tmr0 and it's flag bit within `intcon',
> ;; and turn it on
> clrf tmr0l
> bcf intcon, tmr0if
> bsf t0con, tmr0on
>
> loop:
> ;; check for the flag bit being set as a result of an
> ;; overflow on the timer
> btfss intcon, tmr0if
> goto loop
>
> ;; then increment `counter' (should wait and debounce
> ;; the switch's release also)
> banksel counter
> incf counter, f
>
> ;; toggle on a led used as feedback @ rc0
> btg latc, rc0
>
> ;; turn off the timer
> bcf t0con, tmr0on
>
> ;; and return
> retlw 0
>
> ;;
> ;; high-priority interrupt vector
> ;;
> __hp_interrupt code
> hp_interrupt:
> ;; save registers' status. I don't know if I'd be using
> ;; also low priorities, so better to go this way just in
> ;; case (datasheet says `retfie fast' could be
> ;; unreliable if so)
> movwf hp_w
> movff bsr, hp_bsr
> movff status, hp_status
>
> ;; if the interrupt was caused by a change on rb4:7, go
> ;; to it's processing function
> btfsc intcon, rbif
> call handle_rb_interrupt
>
> exit_hp_interrupt:
> movff hp_bsr, bsr
> movf hp_w, w
> movff hp_status, status
> retfie 0x0
> end
>
> I tried with another led on ra0 and a `btfsc intcon, tmr0if btg lata, ra0' above, so what is happening that tmr0 is causing the chip to vector to 0x8 even when I explictly disabled it.
>
> Shouldn't be `tmr0if' just set, and not cause the chip to vector?
>
> Regards,
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>