Pic 10F200 and Timer0

be80be · Nov 15, 2012

Now this baby is small and I'm old and slow now days, But I can't for the life of me figure this one out
I'm playing with some asm got to where I need to use the timer0 and dang there no flag on the chip that tell you that you hit 0 so what you do poll the timer that can't be good.

What Im trying to do is let the timer tick for 10mS and update a counter but.

Looks like a may just need to make a delay and but I really don't want the chip to sit and count all day

DirtyLude · Nov 15, 2012

Never used a 10f, but looking at the datasheet, the peripherals are basic to the point of being braindead. No interrupt processing at all that I can see. Maybe you can keep a check register for every time you poll the timer:

1. If timer < timer check variable then increment counter
2. timer check variable = timer.

You should be able to catch it by watching your polling times.

I've used a 12f enhanced core 8 pin before and it has a decent set of peripherals with timer interrupts. 12f1501 is an extra 40 cents.

EDIT: Hmm.. I noticed an issue with that psuedo code, though. If timer rolls over between 1 and 2, you'll miss a count. You'll have to complicate it up a little more to make sure you don't miss a count. One way is to use two variables.

1. copy 'timer0' to 'temp check variable'.
2. If 'temp check variable' < 'timer check variable' then increment counter
3. 'timer check variable' = 'temp check variable'

be80be · Nov 15, 2012

Yep I was checking If I lost my mind It's sure takes clever coding with these

On a side note I got one of them lounchpads MPS430 I Like IT

I'm going with delays looks doable

View attachment 68654

be80be · Nov 15, 2012

Well I tried on the receiver and it looks like it came from the chip it picked it up real good. Now to make all the code fit LOL

Pommie · Nov 15, 2012

If you don't mind a bit of jitter then you can do the following,

Set the prescaler to 64 and check bit 7 of the timer for it changing.
Whenever it changes add 8192 to a variable.
If the variable is greater than 10,000 then increment the 10mS location and subtract 10,000 from the variable.

By doing it this way you don't have to constantly poll and can execute any code you like as long as it takes less than 8000 cycles.

The way to check for bit 7 changing could be,

Code:

	movfw	Previous
	xorwf	TMR0,w
	movwf	Temp
	btfss	Temp,7
	goto	NoChange
; bit has changed
	movfw	TMR0
	movwf	Previous
;now do increment and checks.


NoChange

Mike.

be80be · Nov 15, 2012

Well I have to poll 3 buttons but if there pressed I'm out of business for 320 mS to 800 mS depending on what button is pressed
figured I could use the timer to get button up dates faster. But I may speed up the TX time And go with delays

dr pepper · Nov 16, 2012

I've used the same pic, I have some 8 pin dil and some smds, the ones you lose if you sneeze.
You'dve thought they'd give you a zero flag.
Do the 10f204 and 206 have different timer0 setups?, theres a seperate section for them in the data sheets as far as timer0 is concerned.

Mr RB · Nov 17, 2012

Juts keep a manual flag to compare against TMR0.F7 bit, you can poll TMR0 and manually compare that bit to make an event every 128 timer ticks or every 256 timer ticks (same as a timer roll).

Because there are no interrupts you were always in a situation of having to manually poll TMR0 at a rate of <256 ticks anyway.

be80be · Nov 17, 2012

Well i just went with a delay so it works fine what I did is I'm using a 3 switches .

sw1 sends a 8mS / high then 8mS \ low then 8 / 1mS high to \ low pulse then code come back and checks agin.

for new press which are using just longer pulse the start bit is the same On my scope this looks great.

Then my receiver just sits and looks for the start bits finds one reads the pulse test for size and then waits to see if it's repeated
Then act's on it.

Mr RB · Nov 18, 2012

Cool. How did you generate the timed periods without a timer? Just using inline code delays from the compiler?

You can generate thos 1mS periods using the TMR0, probably with more accuracy and almost certainly using less code (which might be an issue on a 10F series).

be80be · Nov 18, 2012

The code fit but it's ll all of the chip but it' works fine. But i'm going to use the timer0 just to see

Mike - K8LH · Nov 18, 2012

Mr RB said:
You can generate thos 1mS periods using the TMR0, probably with more accuracy and almost certainly using less code (which might be an issue on a 10F series).

I think you may be incorrect on both counts. A "cycle accurate" fixed delay sub-system might use less code space and it would eliminate the jitter inherent in a "polled" TMR0 sub-system.

be80be · Nov 18, 2012

Well I tested this code and it's dead on as far as timing goes a 8mS high comes out 8mS the inosc on these chip is really set right.

The code is simple

Code:

 bsf 
 call delay 
 bcf 
 call delay // till it sends 8 bits out

Mr RB · Nov 19, 2012

Mike said:
I think you may be incorrect on both counts. A "cycle accurate" fixed delay sub-system might use less code space and it would eliminate the jitter inherent in a "polled" TMR0 sub-system.

You may be right Mike, especially if both types were carefully handcoded in assembler. But my compiler (MikroC) and possibly others are not good at making inline delays with very little ROM. A "Delay_mS(1)" chunk might be 25 or 30 ASM words, and a few RAM vars off the stack too.

If using the TMR0 with a prescaler then a 1mS delay might be 1000 ticks, so you can use 1024 ticks which would be just clearing TMR0 and then waiting for bit7 to become set, that is the entire 1mS delay routine (assuming the right prescaler of 8:1 is selected);

clrf TMR0
btfss TMR0,7
goto $-1

So in 3 asm instructions that's a complete "1mS delay".

Of course the TMR0 can be written with a non-zero number at the start to remove some of that 24 ticks error (which may or may not matter);

movlw 3
movwf TMR0
btfss TMR0,7
goto $-1

in 4 asm instructions should give a delay of approx 125 timer counts at 8:1 prescaler and would be very close to 1000 counts, depending on the other code overheads like call/return etc.

be80be · Nov 19, 2012

alexasthoma said:
On a side note I got one of them lounchpads MPS430 I Like IT**broken link removed**

Yep but there not as small a 10f200 but there a 20 pin work horse

Mike - K8LH · Nov 19, 2012

Mr RB said:
You may be right Mike, especially if both types were carefully handcoded in assembler. But my compiler (MikroC) and possibly others are not good at making inline delays with very little ROM. A "Delay_mS(1)" chunk might be 25 or 30 ASM words, and a few RAM vars off the stack too.

Yes, I'm talking about hand coded assembler since Burt mentioned he was using assembly language in his initial post. Duh.

... So in 3 asm instructions that's a complete "1mS delay".

Ouch! While both of those examples are indeed very small, the first example executes in 1029 cycles and the second example executes in 1006 cycles, so they certainly couldn't be used as evidence to support your "more accurate" premise.

Your examples do suggest that there's a way to create "cycle accurate" TMR0 based subsystems that I hadn't thought of, but I suspect it will require a little more work and a few more instructions compared to the examples you provided. For example, here's a quickly thrown together TMR0 based subsystem that can generate precise "cycle accurate" delays of 9 to 528 cycles;

Code:

;*****************************************************************
;  K8LH TMR0 fixed delay subsystem macro creates 2 instructions  *
;*****************************************************************
clock   equ     4               ;
usecs   equ     clock/4         ;
        radix   dec

tmr0dly macro   delay           ; range 9..528 cycles
        movlw   (528-delay)/4
        call    deltmr-((delay-9)%4)
        endm

Code:

        org     0x000
        radix   dec

simtest
        tmr0dly(100*usecs)      ;
        nop                     ; <- simulator break point here

Code:

;*****************************************************************
;  K8LH TMR0 fixed delay subsystem timer subroutine              *
;*****************************************************************
        nop                     ; entry for (delay-9)%4 == 3
        nop                     ; entry for (delay-9)%4 == 2
        nop                     ; entry for (delay-9)%4 == 1
deltmr  movwf   TMR0            ; entry for (delay-9)%4 == 0
        nop                     ; 4 cycle loop (prescale 4)
        btfss   TMR0,7          ;
        goto    $-2             ;
        retlw   0               ;

While this example (using TMR0 prescale 4) has a very limited delay range, it does suggest there may be a number of creative methods yet to be discovered for developing efficient "cycle accurate" TMR0 based fixed delay subsystems for 12-bit core devices that compare favorably in size to non-TMR0 based "cycle accurate" fixed delay subsystems.

Best regards and happy Holidays...

Mr RB · Nov 20, 2012

Mike said:
...
Ouch! While both of those examples are indeed very small, the first example executes in 1029 cycles and the second example executes in 1006 cycles, so they certainly couldn't be used as evidence to support your "more accurate" premise.

Like any asm coded delay it can be as accurate as you need. Using the TMR0 prescaler of 8:1 limits granularity to 8 cycles. Any asm delay can be padded with NOPs as needed to give accuracy down to one cycle.

Burt had mentioned wanting to reduce code size, but had not seemed too concerned with per-cycle accuracy.

Mike said:
...
Your examples do suggest that there's a way to create "cycle accurate" TMR0 based subsystems that I hadn't thought of, ...

Sure there is. If that example above gives 1006 cycles delay then increasing the start value by 1 gives a 998 cycle delay, and 2 nops (or the old trick goto $+1) fill in the gap making it exactly 1000 cycles;

goto $+1 ; this is a 2 cycle delay
movlw 4 ; rest gives a 998 cycle delay
movwf TMR0
btfss TMR0,7
goto $-1

Anyway that still needs accounting for call/return cycling or whether it is an inline delay, or decision making in the code (delay/nodelay etc), all issues that probably don't matter in most cases when a user just needs a "1mS delay" in their code. Burt never said "exact 1000 cycle delay".

be80be · Nov 20, 2012

Mr RB your idea is fine Mike's Idea is Cool to my delays worked out 996 almost 1 mS 1996 almost 2mS and 3996 that close enough to 4 for what I'm doing.

Mike - K8LH · Nov 20, 2012

Mr RB said:
Burt never said "exact 1000 cycle delay".

Please remember I was simply challenging your opinion that a TMR0 based solution would be (1) "more accurate", "and" (2) "smaller" than a delay routine. There was never any question about what kind of accuracy was actually required.

Cheerful regards...

Mike - K8LH · Nov 20, 2012

Mr RB said:
... increasing the start value by 1 gives a 998 cycle delay, and 2 nops (or the old trick goto $+1) fill in the gap making it exactly 1000 cycles;

Code:

goto $+1 ; this is a 2 cycle delay movlw 4 ; rest gives a 998 cycle delay movwf TMR0 ; btfss TMR0,7 ; goto $-1 ;

Well... actually... your calculations are off. You're forgetting that you're polling a timer that increments once every eight cycles from within a three cycle loop so increasing the start value by one will not decrease the time delay by 8 cycles from 1006 cycles to 998 cycles. In this case, taking time for a more thoughtful response and/or a minute or two of simulation could have prevented you from posting something that isn't credible (doesn't stand up to your claims).

Pic 10F200 and Timer0

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Privacy & Transparency

Privacy & Transparency