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
Extremely long delay loop on PIC16F84
Started by ●November 6, 2004
Reply by ●November 6, 20042004-11-06
"CFF" <cffung@myrealbox.com> schreef in bericht news:2560187f.0411060904.4ddbbf14@posting.google.com...> decfsz count3, f ; THIS GUY NEVER COME TO ZERO BUT 0xF5, WHY??? > goto delay > movlw 0xff > movwf count3Is there a watchdog enabled that resets the PIC? -- Thanks, Frank. (remove 'x' and 'invalid' when replying by email)
Reply by ●November 6, 20042004-11-06
"CFF" <cffung@myrealbox.com> wrote in message news:2560187f.0411060904.4ddbbf14@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 > > endThe value of f should be 1. I don't see f defined anywhere so it might default to 0 or 0xf, who knows? Just an idea, try removing the ",f" from each decfsz instruction or replace the "f" with a "1" like decfsz count3 // This way defaults destination to file or decfsz count3,1 // This way specifies save to file. Peter
Reply by ●November 9, 20042004-11-09
Reply by ●November 11, 20042004-11-11
In article <2560187f.0411060904.4ddbbf14@posting.google.com>, CFF <cffung@myrealbox.com> wrote:>I am working on my first project using a 4MHz PIC16F84.[Beating the Drum] The 16F84 is obsolete. You should upgrade to a part like the 16F88. Details on my 16F84 is obsolete page: http://www.finitesite.com/d3jsys/16F88 This project is a perfect example of why you should consider moving away from the 16F84.> 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.OK. As I said, there are better parts. For example with the 16F88 there is another timer (TMR1) that is specifically designed for such activity. It allows for a second external crystal/clock to drive the clock. If you use a 32768 Hz crystal to drive it, you can get a 2,4,8m or 16 second overflow signal to count instead of trying to track a 4 Mhz clock. I have used this in my sunrise sunset outside lite controller. You can find the code in the projects section of my PIC page above. That's my two cents. Better parts make for easier code. I'll let someone else tackle dealing with 16F84 code that could be trivially simple with the right hardware. BAJ
