Post by thread:[PIC]: Timer 0

I'm confused. I've set timer0 to run, and I'm polling as follows for the T0IF bit. Comm_Bit_Loop: btfss INTCON,T0IF ;Check for timer hitting zero goto Comm_Bit_Loop ;If not, then keep looping It appears that the int flag is never set. Ints are disabled, but I thought I read that the int flag would still be set on rollover. If this isn't workable, then how do you detect rollover? 16F627 if it matters. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

In message <spam_OUT4.3.2.7.2.20010103130231.02372bf0TakeThisOuTmail.cedar.net>, David VanHorn <.....dvanhornKILLspam@spam@CEDAR.NET> writes >I'm confused. > >I've set timer0 to run, and I'm polling as follows for the T0IF bit. > >Comm_Bit_Loop: > btfss INTCON,T0IF ;Check for timer hitting zero > goto Comm_Bit_Loop ;If not, then keep looping > >It appears that the int flag is never set. >Ints are disabled, but I thought I read that the int flag would still be >set on rollover. > >If this isn't workable, then how do you detect rollover? How about Comm_Bit_Loop: btfsc TMR0,7 ;Check for timer hitting zero goto Comm_Bit_Loop ;If not, then keep looping bsf TMR0,7 {Quote hidden}> >16F627 if it matters. >-- >Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics > > ******************************************************* Broadcast Warehouse ( FM Transmitters and accessories ) Website: http://www.broadcast-warehouse.com Email: infoKILLspambroadcast-warehouse.com Phone: sales: +44 (0) 208 5409992 tech support: +44 (0) 208 5409993 Fax: +44 (0) 208 5409994 ******************************************************* -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 01:05 PM 1/3/01 -0500, you wrote: >I'm confused. > >I've set timer0 to run, and I'm polling as follows for the T0IF bit. > >Comm_Bit_Loop: > btfss INTCON,T0IF ;Check for timer hitting zero > goto Comm_Bit_Loop ;If not, then keep looping > >It appears that the int flag is never set. >Ints are disabled, but I thought I read that the int flag would still be >set on rollover. > Maybe: bcf INTCON,T0IF . . . Comm_Bit_Loop: btfss INTCON,T0IF ;Check for timer hitting zero goto Comm_Bit_Loop ;If not, then keep looping bcf INTCON,T0IF . . BTW, don't try this on scenix. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> >How about > >Comm_Bit_Loop: > btfsc TMR0,7 ;Check for timer hitting zero > goto Comm_Bit_Loop ;If not, then keep looping > bsf TMR0,7 I guess that works, but it's not really what I had in mind. Is it true that the int flag is set, even when not enabled? Figure 6-1 and 6-6 show no dependencies between the timer register and the T0IF bit. 6-1 text states that the int is generated whenever the counter rolls over, but it may be masked. (implying that the int bit would be set even if masked) -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

>>How about >> >>Comm_Bit_Loop: >> btfsc TMR0,7 ;Check for timer hitting zero >> goto Comm_Bit_Loop ;If not, then keep looping >> bsf TMR0,7 I guess I don't understand this, since even if you clear the TMR0 register before entering this loop, it will show "zero overflow" according to the bit 7 test when TMR0 gets to 128, not 256. I NEVER use bit 7 for a 'pass zero' test unless you're using decf or otherwise subtracting a value less than 128. >I guess that works, but it's not really what I had in mind. I don't see how it could work. >Is it true that the int flag is set, even when not enabled? >Figure 6-1 and 6-6 show no dependencies between the timer register and the >T0IF bit. I've used the T0IF bit to detect TMR0 overflow without enabling the interrupt and it works fine. Yes, the datasheet is correct in stating that the flag bit is set regardless of the mask. Are you using the watch window to monitor the INTCON register for the T0IF bit? If so, what does it do when TMR0 overflows? Note that it doesn't get RESET - you have to clear the flag bit in software after it's set by TMR0 overflow. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

OK Dan, I'll bite. Why not try it on a Scenix? -- Rich Dan Michaels wrote: {Quote hidden}> > At 01:05 PM 1/3/01 -0500, you wrote: > >I'm confused. > > > >I've set timer0 to run, and I'm polling as follows for the T0IF bit. > > > >Comm_Bit_Loop: > > btfss INTCON,T0IF ;Check for timer hitting zero > > goto Comm_Bit_Loop ;If not, then keep looping > > > >It appears that the int flag is never set. > >Ints are disabled, but I thought I read that the int flag would still be > >set on rollover. > > > > Maybe: > > bcf INTCON,T0IF > . > . > . > Comm_Bit_Loop: > btfss INTCON,T0IF ;Check for timer hitting zero > goto Comm_Bit_Loop ;If not, then keep looping > bcf INTCON,T0IF > . > . > > BTW, don't try this on scenix. > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

It looks to be more basic, I inverted the test to btfss tmr0,7 and now I hang also, so it appears that the timer isn't running. It WAS running, but I guess someone killed it. (Can't sim this code..!#@$!) -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> >>I guess that works, but it's not really what I had in mind. > >I don't see how it could work. It dosen't really detect overflow, as you noted. The problem seems to be that my timer is getting shut off. Unfortunately, I can't sim this code very easily, it's "crash and burn" mode. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 11:43 AM 1/3/01 -0700, you wrote: >OK Dan, I'll bite. Why not try it on a Scenix? > >-- Rich > No T0IF - totally mind-boggling. [BTW, I promise to come to a near-future meeting of the 6502 - whatever that is - hacksters - but then of course, I'll have to leave the cave :)]. - danM {Quote hidden}> >Dan Michaels wrote: >> >> At 01:05 PM 1/3/01 -0500, you wrote: >> >I'm confused. >> > >> >I've set timer0 to run, and I'm polling as follows for the T0IF bit. >> > >> >Comm_Bit_Loop: >> > btfss INTCON,T0IF ;Check for timer hitting zero >> > goto Comm_Bit_Loop ;If not, then keep looping >> > >> >It appears that the int flag is never set. >> >Ints are disabled, but I thought I read that the int flag would still be >> >set on rollover. >> > >> >> Maybe: >> >> bcf INTCON,T0IF >> . >> . >> . >> Comm_Bit_Loop: >> btfss INTCON,T0IF ;Check for timer hitting zero >> goto Comm_Bit_Loop ;If not, then keep looping >> bcf INTCON,T0IF >> . >> . >> >> BTW, don't try this on scenix. >> >> -- >> http://www.piclist.com hint: The list server can filter out subtopics >> (like ads or off topics) for you. See http://www.piclist.com/#topics > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics > > > > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 01:44 PM 1/3/01 -0500, you wrote: >It looks to be more basic, I inverted the test to btfss tmr0,7 and now I >hang also, so it appears that the timer isn't running. > >It WAS running, but I guess someone killed it. (Can't sim this code..!#@$!) > Did you get MY message? -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> >Did you get MY message? I got A message.. Here's the whole routine. I enter at Comm_Bit_Long Comm_Bit_Long clrf TMR0 ; goto Comm_Bit_Go ; Comm_Bit_Delay: bcf STATUS,rp0 ;select bank two bsf STATUS,rp1 ; movfw comm_speed ;set timer 0 bcf STATUS,rp1 ;Back to bank zero movwf TMR0 ; Comm_Bit_Go: clrwdt ; bcf INTCON,T0IF ;Clear this off Comm_Bit_Loop: ;btfss INTCON,T0IF ;Dosen't exit (Original) ;btfsc TMR0,7 ;Exits btfss TMR0,7 ;Dosen't exit goto Comm_Bit_Loop ;If not, then keep looping return At this point, I think that Timer 0 isn't running. I've loaded it with zero, and the btfsc is exiting because it's not counted up that far. I did some hacking with the sim, and according to the sim, timer 0 should be running. I'm clocking from the internal clock, so nothing in hardware should have affected this. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

David, Enable interrupts (both global and rtcc), and wait for the rollover to trigger an interrupt. Then go in and do the housekeeping, take care of whatever it is you want to take care of, do housekeeping to renable the interrupts, and exit your interrupt service routine, and go back to what you were doing before the interrupt. Regards, Jim On Wed, 03 January 2001, David VanHorn wrote: {Quote hidden}> > I'm confused. > > I've set timer0 to run, and I'm polling as follows for the T0IF bit. > > Comm_Bit_Loop: > btfss INTCON,T0IF ;Check for timer hitting zero > goto Comm_Bit_Loop ;If not, then keep looping > > It appears that the int flag is never set. > Ints are disabled, but I thought I read that the int flag would still be > set on rollover. > > If this isn't workable, then how do you detect rollover? > > 16F627 if it matters. > -- > Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics .....jimKILLspam.....jpes.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 01:05 PM 1/3/01 -0500, David VanHorn wrote: >I'm confused. > >I've set timer0 to run, and I'm polling as follows for the T0IF bit. > >Comm_Bit_Loop: > btfss INTCON,T0IF ;Check for timer hitting zero > goto Comm_Bit_Loop ;If not, then keep looping > >It appears that the int flag is never set. >Ints are disabled, but I thought I read that the int flag would still be >set on rollover. I *know* for a fact that T0IF is set upon timer 0 rollover regardless of the state of T0IE. In fact, I have several dozen projects using that very technique. It lets me make my background task a polled routine and thus reserve the ISR for time critical routines. I would check the option register bit 5 (T0CS) - TMR0 can be configured for external clock input. It sure sounds like TMR0 isn't clocking. I also do a lot of work with 12 bit core parts - no T0IF. But its not much of a problem - I make my "flag test" routine look for TMR0 bit 7 to go low, then look for it to go high. i.e. . ... WaitBGflagLO btfss TMR0,7 goto WaitBGflagLO WaitBGflagHI btfsc TMR0,7 goto WaitBGflagHI ;BG task starts here You have to do both tests (bit 7 lo, then high) to avoid having to reset TMR0. dwayne Dwayne Reid <EraseMEdwaynerspam_OUTTakeThisOuTplanet.eon.net> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 16 years of Engineering Innovation (1984 - 2000) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 11:43 AM 1/3/01 -0800, James Paul wrote: > David, > > Enable interrupts (both global and rtcc), and wait for the rollover > to trigger an interrupt. Then go in and do the housekeeping, take > care of whatever it is you want to take care of, do housekeeping to > renable the interrupts, and exit your interrupt service routine, and > go back to what you were doing before the interrupt. I realize that I could do it this way, but I'd like to save that interrupt. From everything I've seen so far, the problem is that the timer isn't running in real life, but it IS running in the simulator. Obviously there's some hardware stimulus that isn't there in the sim, but I can't see why what I've got, would matter to the timer. I'm going to search through, and see if I have anything maybe writing to option with the wrong bank selected, or writing the wrong thing to option.. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

At 11:43 AM 1/3/01 -0800, you wrote: > David, > > Enable interrupts (both global and rtcc), and wait for the rollover > to trigger an interrupt. Then go in and do the housekeeping, take > care of whatever it is you want to take care of, do housekeeping to > renable the interrupts, and exit your interrupt service routine, and > go back to what you were doing before the interrupt. > Dave, do "exactly" the opposite. Don't enable interrupts [nor the WDT], but get the stuff running first in polled mode, only then go to interrupts. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Dave Van Horn wrote: ........ > From everything I've seen so far, the problem is that the timer isn't >running in real life, but it IS running in the simulator. Obviously >there's some hardware stimulus that isn't there in the sim, but I can't see >why what I've got, would matter to the timer. > >I'm going to search through, and see if I have anything maybe writing to >option with the wrong bank selected, or writing the wrong thing to option.. > Dave, here is the best advice anybody could ever give someone dipping their feet into PIC programming: 1 - take that simulator disk, and throw it in the can. 2 - setup a small pcb specifically for a 16F84, with an RS232 port, and a 3-pin machine pin socket for swapping xtals and resonators. If possible, add ICSP to the board. 3 - forget about '877 chips [for a couple of weeks at least]. 4 - disable the WDT and don't mess with interrupts initially. 5 - work thru all the basic routines and timer ops using small programs, and "always" use calls to subroutines for everything other than the main loop - ie, code as modules. 6 - start with tiny programs to attack every new operation you try, and test, test, test. 7 - once the basic things work as small modules, add complexity [interrupts, WDT, bank switching, page switching, etc], and integrate the small modules into large programs. It's just like designing and building hardware. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> >Dave, do "exactly" the opposite. Don't enable interrupts [nor >the WDT], but get the stuff running first in polled mode, >only then go to interrupts. I'm fine now, I just didn't realize that the WDT reset disabled the timer. I have no fear of ints. My first uC job was decoding barcodes literally while they were coming in under the pen. Total interrupt job, in fact the int code had to reconfigure the ints to get the opposing edges. I learned a lot, and fast, on that system! The best part is decoding a digit in UPC/EAN, from four timings, in five comparisons. From that, I get direction, parity, and digit. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> >Dave, here is the best advice anybody could ever give someone >dipping their feet into PIC programming: > >1 - take that simulator disk, and throw it in the can. Well, so far it hasn't done me wrong. Actually, I'm not new to this. I'm just not current on the pic. I do most of my work in the AVR, so it's just the minutiae that's biting me, and I don't have the degree of certanity that a more frequent user would, WRT issues where the databook is rather grey. I prefer the AVR's vectored ints, and generally less procrustean internal architechture. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> Dave, here is the best advice anybody could ever give someone > dipping their feet into PIC programming: > > 1 - take that simulator disk, and throw it in the can. I find the simulator can be very useful at times, especially when writing code before the target hardware is available or the emulator components are back ordered. > 3 - forget about '877 chips [for a couple of weeks at least]. Why? The 877, 876, etc are nice chips and there is nothing wrong with learning on them first if that's what you have available. Much of your advice was sound, but I take exception to presenting your personal superstitions as universally aggreed on facts without labeling them as such. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, olinspam_OUTembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Olin wrote: >> Dave, here is the best advice anybody could ever give someone >> dipping their feet into PIC programming: >> >> 1 - take that simulator disk, and throw it in the can. > >I find the simulator can be very useful at times, especially when writing >code before the target hardware is available or the emulator components are >back ordered. > All in all, there are much more efficient ways to do it - set up a little platform, as I said, for writing/testing. Simulators are the least efficient. ================ >> 3 - forget about '877 chips [for a couple of weeks at least]. > >Why? The 877, 876, etc are nice chips and there is nothing wrong with >learning on them first if that's what you have available. > Why not jump into the deep end with lead weights tied around your legs your first day at the pool? [same answer to both]. ================ >Much of your advice was sound, but I take exception to presenting your >personal superstitions as universally aggreed on facts without labeling them >as such. > Superstitions are advice given "before" field testing, not after. Experience is not a belief system. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

>All in all, there are much more efficient ways to do it - set >up a little platform, as I said, for writing/testing. Simulators >are the least efficient. As a rule I don't use simulators very often, but they DO have their place. This time I'm with Olin. >>Why? The 877, 876, etc are nice chips and there is nothing wrong with >>learning on them first if that's what you have available. >> >Why not jump into the deep end with lead weights tied around >your legs your first day at the pool? [same answer to both]. Very poor analogy. The water is only as deep as your ankles if you start with a '876 and don't use all the features. PLUS the ICD doesn't work too well on a '84. >Superstitions are advice given "before" field testing, not after. >Experience is not a belief system. Experience is not, but Interpretation of Experienced IS! And _that's_ what you just did. And Dan, you of all people should know better than to bring your religious views into the public. Andy -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

AndyK wrote: .............. >>Superstitions are advice given "before" field testing, not after. >>Experience is not a belief system. > >Experience is not, but Interpretation of Experienced IS! And _that's_ what you >just did. > >And Dan, you of all people should know better than to bring your religious views >into the public. > Andy, Olin, when somebody writes something like here is the best advice anybody could ever give someone >> dipping their feet into PIC programming: >> you guys shouldn't take it all too seriously. [BTW, Andy, I'm still waiting for your other "interpretation" off-list]. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> Andy, Olin, when somebody writes something like > > here is the best advice anybody could ever give someone > >> dipping their feet into PIC programming: > >> > > you guys shouldn't take it all too seriously. There is nothing in that statement that suggests to me that it is not intended seriously. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, @spam@olinKILLspamembedinc.com, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

At 02:00 PM 1/4/01 -0500, you wrote: >> Andy, Olin, when somebody writes something like >> >> here is the best advice anybody could ever give someone >> >> dipping their feet into PIC programming: >> >> >> >> you guys shouldn't take it all too seriously. > >There is nothing in that statement that suggests to me that it is not >intended seriously. > Of course, it "was" intended seriously, that doesn't mean you have to take it that way :). -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dear all, A propos this Timer discussion, I have a question: I have a watch crystal on Timer 1 which I use to control sampling of the ADC ports. I have a 10MHz crystal on the main Timer 0. I would like to be able to sleep, which means using an RC (or possibly resonator) on Timer 0, but RC is likely to be unsuitable because I am using a USART for data transmission and timing is critical. My question is: could I perhaps use the watch crystal on Timer 1 to keep the USART timing correct? TIA, Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: KILLspamkirtleyKILLspamcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to RemoveMElistprocTakeThisOuTinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

I guess I may be missing something but why can't you use the crystal and still use sleep. Unless it's the startup time restriction? I guess it might be possible to use the watch crystal to determine a calibration value for the RC such that it could be used for USART timing, you might time a set time using the watch xtal and count how many times a loop cycles, then load the loop count into SPBRG. By loading the loop with the right amount of delay you should be able to generate valid SPBRG values directly. Alternatively a software serial port might get it's timings from the watch xtal rather than the normal cpu cycle counting method. Slow. Oliver. {Original Message removed}

At 08:26 PM 1/9/01 +0000, Oliver Broad wrote: >I guess I may be missing something but why can't you use the crystal and >still use sleep. Unless it's the startup time restriction? You can use sleep, but timer 0 stops counting during sleep. -- Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

I have done this thing. one variety --wakes up and sets WDT prescaler 1:4 --sets a dog flag --clears 'magic' register --repeatedly calls a subroutine that lasts 1 msecand increments counter --when watchdog barks, the number of msec is in magic. now i adjust the sleep length to get exactly 10 minutes knowing how many magic counts the wdt will take. oh, and a routine at the reset vector watches for the dog flag so it knows it this is a deliberate or accidental watchdog timeout. alice {Quote hidden}> I guess I may be missing something but why can't you use the crystal and > still use sleep. Unless it's the startup time restriction? > > I guess it might be possible to use the watch crystal to determine a > calibration value for the RC such that it could be used for USART timing, > you might time a set time using the watch xtal and count how many times a > loop cycles, then load the loop count into SPBRG. By loading the loop with > the right amount of delay you should be able to generate valid SPBRG values > directly. > > Alternatively a software serial port might get it's timings from the watch > xtal rather than the normal cpu cycle counting method. Slow. > > Oliver. > > {Original Message removed}