Extremely long delay loop on PIC16F84

C

CFF

Guest
I am working on my first project using a 4MHz PIC16F84. The whole
purpose of the project is to set portb<0> pin from HIGH to LOW for a
prolong period (as much as 30 minutes) before tuning back to HIGH upon
detection of activity at porta pins.

My idea is to cascade a series of fully loaded counters (I am using 4
8-bit file registers, i.e. count1 to count4, in my experiment) so as
to generate the required lengthy delay. The idea is simple but it
doesn't work out as expected however.

What's strange about the counting process is count3 will only count
from 0xFF to 0xF5 before reseting itself to 0xFF. That is where my
trouble is about. It has been confirmed both on simulator and my
hardware circuit. If I load the counters with smaller initial values,
say 0x0F, the problem disappears. Of course, smaller values doesn't
generate long delay. Can somebody give me some idea about why the PIC
behaves differently from what the programme logic states?

Below is the problematic code that I've been experimenting. Thanks for
any help.

;;;;;;;;;;;;;;;;; PROBLEMATIC PIC CODE ;;;;;;;;;;;;;;;
list p=16F84
radix hex

porta equ 0x05
portb equ 0x06
count1 equ 0x0c
count2 equ 0x0d
count3 equ 0x0e
count4 equ 0x0f

org 0x000 ; processor reset vector
goto start

start movlw 0xff
tris porta ; configure porta as input port

movlw 0x00
tris portb ; configure portb as output port
clrf portb ; set portb LOW

scan btfss porta, 0
call timer
btfss porta, 2
call timer
btfss porta, 3
call timer
goto scan

timer bsf portb, 0 ; set portb<0> HIGH

; initialise count1 to count4
movlw 0xff
movwf count1
movlw 0xff
movwf count2
movlw 0xff
movwf count3
movlw 0xff
movwf count4

delay decfsz count1, f
goto delay
movlw 0xff
movwf count1

decfsz count2, f
goto delay
movlw 0xff
movwf count2

decfsz count3, f ; THIS GUY NEVER COME TO ZERO BUT 0xF5, WHY???
goto delay
movlw 0xff
movwf count3

decfsz count4, f
goto delay

bcf portb, 0 ; set portb<0> LOW
return

end
 
CFF wrote:
I am working on my first project using a 4MHz PIC16F84. The whole
purpose of the project is to set portb<0> pin from HIGH to LOW for a
prolong period (as much as 30 minutes) before tuning back to HIGH upon
detection of activity at porta pins.

My idea is to cascade a series of fully loaded counters (I am using 4
8-bit file registers, i.e. count1 to count4, in my experiment) so as
to generate the required lengthy delay. The idea is simple but it
doesn't work out as expected however.

What's strange about the counting process is count3 will only count
from 0xFF to 0xF5 before reseting itself to 0xFF. That is where my
trouble is about. It has been confirmed both on simulator and my
hardware circuit. If I load the counters with smaller initial values,
say 0x0F, the problem disappears. Of course, smaller values doesn't
generate long delay. Can somebody give me some idea about why the PIC
behaves differently from what the programme logic states?

Below is the problematic code that I've been experimenting. Thanks for
any help.

;;;;;;;;;;;;;;;;; PROBLEMATIC PIC CODE ;;;;;;;;;;;;;;;
Click to expand...
[snip]

decfsz count3, f ; THIS GUY NEVER COME TO ZERO BUT 0xF5, WHY???
Click to expand...
Is the watchdog resetting the processor?
 
It is possible the watchdog timer is interrupting you (that depends on the
other code present). Putting in a CLRWDT at the appropriate point would
solve that. I am not familiar with the PIC16F84, but don't most PICs have
SFRs at 0x0c through 0x0f? If this is true for the PIC16F84, they could
change because of the functional state of the associated peripherals.

"CFF" <cffung@myrealbox.com> wrote in message
news:2560187f.0411060908.64d9a65f@posting.google.com...
I am working on my first project using a 4MHz PIC16F84. The whole
purpose of the project is to set portb<0> pin from HIGH to LOW for a
prolong period (as much as 30 minutes) before tuning back to HIGH upon
detection of activity at porta pins.

My idea is to cascade a series of fully loaded counters (I am using 4
8-bit file registers, i.e. count1 to count4, in my experiment) so as
to generate the required lengthy delay. The idea is simple but it
doesn't work out as expected however.

What's strange about the counting process is count3 will only count
from 0xFF to 0xF5 before reseting itself to 0xFF. That is where my
trouble is about. It has been confirmed both on simulator and my
hardware circuit. If I load the counters with smaller initial values,
say 0x0F, the problem disappears. Of course, smaller values doesn't
generate long delay. Can somebody give me some idea about why the PIC
behaves differently from what the programme logic states?

Below is the problematic code that I've been experimenting. Thanks for
any help.

;;;;;;;;;;;;;;;;; PROBLEMATIC PIC CODE ;;;;;;;;;;;;;;;
list p=16F84
radix hex

porta equ 0x05
portb equ 0x06
count1 equ 0x0c
count2 equ 0x0d
count3 equ 0x0e
count4 equ 0x0f

org 0x000 ; processor reset vector
goto start

start movlw 0xff
tris porta ; configure porta as input port

movlw 0x00
tris portb ; configure portb as output port
clrf portb ; set portb LOW

scan btfss porta, 0
call timer
btfss porta, 2
call timer
btfss porta, 3
call timer
goto scan

timer bsf portb, 0 ; set portb<0> HIGH

; initialise count1 to count4
movlw 0xff
movwf count1
movlw 0xff
movwf count2
movlw 0xff
movwf count3
movlw 0xff
movwf count4

delay decfsz count1, f
goto delay
movlw 0xff
movwf count1

decfsz count2, f
goto delay
movlw 0xff
movwf count2

decfsz count3, f ; THIS GUY NEVER COME TO ZERO BUT 0xF5, WHY???
goto delay
movlw 0xff
movwf count3

decfsz count4, f
goto delay

bcf portb, 0 ; set portb<0> LOW
return

end
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top