Searching \ for '[PIC] 4550 TMR0' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: '4550 TMR0'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 4550 TMR0'
2007\06\27@083604 by Jinx

face picon face
I've spent way too much time on this today trying to figure out
what's going on. Maybe someone can see something I can't

Code for a s/w UART on an 18F4550 should have been straight-
forward, but TMR0 isn't doing what I expected

Fosc is derived from a 3.2768MHz crystal, and instruction cycles
are being measured as 101.72ns, so the PIC is running at 39.3216

The loading I have for TMR0 should make about 104us, which
is the bit time for an 8MHz 18F1320 set to receive 9615 baud
(eventually the 4550 will be bumped up to 48MHz for USB and
the s/w UART will also be transmitting at 9615 baud)

I calculate

$10000 - $0FC02 = $003FE = 1022, * 0.10172 = 104us

But TMR0 puts out 757.85us. I can't figure out what needs to
be done. It's not a recognisable multiple (~ 7.28), so counted
out a pre-scaler. The msdelay does put out the calculated 1ms,
so Fosc is good

No interrupts or WDT enabled. The h/w UART is comming
with an external device at 9600 baud, no problems

Any ideas ? Please ?

TMR0 set-up

        mov     b'000001000',t0con
;                  0          t0 off
;                   0         16-bit
;                    0        internal clock
;                     x
;                      1      no pre-scaler
;                       xxx

Test transmission

txa5     movlw   0x55
        call    txw
        call    msdelay
        movlw   0xaa
        call    txw
        call    msdelay
        bra     txa5

;================================================
;        Transmit byte from W - set dtx high/low (inverted)
;================================================

txw      movff    wreg,temp
        mov      8,cnt0
        bcf      dtx          ;Start bit
        call     bitdel

byte_out btfss    temp,0
        bra      zerobit
onebit   bcf      dtx
        call     bitdel
        bra      nextbit
zerobit  bsf      dtx
        call     bitdel

nextbit  rrncf    temp
        decfsz   cnt0
        bra      byte_out

        bsf      dtx          ;Stop bit
        call     bitdel
        return

; 1 bit delay, 104.004us

bitdel   mov      0x02,tmr0l
        mov      0xfc,tmr0h
        bcf      intcon,tmr0if
        bsf      t0con,tmr0on ;timer on
        btfss    intcon,t0if  ;wait for rollover
        bra      $-2
        bcf      t0con,tmr0on ;timer off
        return

2007\06\27@092019 by Tamas Rudnai

face picon face
Hi Jinx,

I think you have to write TMR0H first which is a latency byte only and it
updated when you write TMR0L. Reading is the opposite way, TMR0H updated
when you read TMR0L.

Regards,
Tamas


On 6/27/07, Jinx <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:
{Quote hidden}

> -

2007\06\27@093140 by Jinx

face picon face
> I think you have to write TMR0H first which is a latency byte
> only and it updated when you write TMR0L. Reading is the
> opposite way, TMR0H updated when you read TMR0L

Thanks Tamas. I've tried it both ways. I'm not so sure that's
important if the timer is stopped. The only time I saw any change
was when TMR0 was set to 8-bit and it counted almost a full
10000 Which shouldn't have happened. TMR0 is usually the
easy one !

2007\06\27@094436 by Dario Greggio

face picon face
Jinx wrote:

> Fosc is derived from a 3.2768MHz crystal, and instruction cycles
> are being measured as 101.72ns, so the PIC is running at 39.3216

Hi, some time ago somebody claimed that the Frequency to PLL can only be
4 MHz...
Could this be the issue?

And/or are you sure about your Osc/PLL Config Settings?

--
Ciao, Dario

2007\06\27@095422 by Jan-Erik Soderholm

face picon face
That is correct, but in this case (as I understod it)
TMR0L is never *read* and TMR0H is never written with
anything else then 0xFC, so the TMR0H-buffer whould have
the correct value anyway. But, I'd write them in
the correct order anyway...

Jan-Erik.

Tamas Rudnai wrote:
{Quote hidden}

>> --

2007\06\27@101426 by Tamas Rudnai

face picon face
Hi Jan-Erik,

I do not know, at the moment I have not access to 4450 but at least on
simulator (MPLAB 7.41) if I put in the order Jinx did TMR0H does not get
transferred into the TMR0 register tough I see it in the special
funct.regwindow like it was - I got something 6ms delay in this way,
but with the
order the datasheet describes I got the 104ns timings.

Tamas


On 6/27/07, Jan-Erik Soderholm <jan-erik.soderholmspamKILLspamtelia.com> wrote:
{Quote hidden}

2007\06\27@101614 by Tamas Rudnai

face picon face
Sorry, 104us, not ns of course :-)

Tamas


On 6/27/07, Tamas Rudnai <EraseMEtamas.rudnaispam_OUTspamTakeThisOuTgmail.com> wrote:
{Quote hidden}

>

2007\06\27@101643 by Jan-Erik Soderholm

face picon face
Well, it has nothing to do with stopped or not.
If the new "H" value i something else then the
last read or written "H" value, you will not
get what you think into TMR0. The H-buffer
is transfered when the L-value is written,
no matter how many times you write to the
H-buffer after thar...

Anyway, to stop this kind of comments, why not
simply write them in the order recomened
by the datahseet ? :-) :-)

Jan-Erik.

Jinx wrote:
{Quote hidden}

2007\06\27@184921 by Jinx

face picon face
> Anyway, to stop this kind of comments, why not
> simply write them in the order recomened
> by the datahseet ? :-) :-)

As I said -

> > I've tried it both ways

Currently it's

bitdel   mov      0xfc,tmr0h
        mov      0x18,tmr0l

rolling over at 757us. And that's the way I started. Yes,
I am aware of re-load order (although I said I wasn't sure
about whether the timer was running or not, subconsciously
maybe I was, because that's how I wrote the code), and
particularly as I read the 4550's TMR0 section to check
afterwards

"Similarly, a write to the high byte of Timer0 must also
take place through the TMR0H Buffer register. The high
byte is updated with the contents of TMR0H when a
write occurs to TMR0L. This allows all 16 bits of Timer0
to be updated at once"

So I'm still stumped. But thanks for the input guys, really

2007\06\27@192808 by Jinx

face picon face
> > Fosc is derived from a 3.2768MHz crystal, and instruction
> > cycles are being measured as 101.72ns, so the PIC is running
> > at 39.3216MHz
>
> Hi, some time ago somebody claimed that the Frequency to PLL
> can only be 4 MHz...
> Could this be the issue?

It's not for me to argue with a PIC, but it does seem to be running
fine with that crystal. Well, everything except TMR0 that is

> And/or are you sure about your Osc/PLL Config Settings?

Presently the CONFIG settings are few. The only one "I" think
is relevant to frequency is

        CONFIG  FOSC= XTPLL_XT

I'll have a look into the oscillator block. TMR0 is counting some
internal clock, because it rolls over consistently. Just why it's not
incrementing at 101.72ns is the mystery. Finding the relationship
between 104us / 03E8 / 757.85us / 101.72ns would be a clue. If
it came out to 4 or 8 you'd suspect a pre-scaler, but 7.28 ?

2007\06\27@192809 by Jinx

face picon face
> if I put in the order Jinx did TMR0H does not get transferred
> into the TMR0 register tough I see it in the special funct.reg
> window like it was - I got something 6ms delay in this way,
> but with the order the datasheet describes I got the 104ns
> timings

In the actual circuit I get 757.85us either way TMR0 is re-loaded.
So "something" doesn't care or is contrary to the manual

WTF ?

2007\06\28@053522 by Jan-Erik Soderholm

face picon face
Jinx wrote:
>> Anyway, to stop this kind of comments, why not
>> simply write them in the order recomened
>> by the datahseet ? :-) :-)
>
> As I said -
>
>>> I've tried it both ways

Yes, and your later findings using a 4.0 MHz xtal
also confirms what I wrote about that it *should*
not be an issue in *this* case since TMR0H will
be loaded with the correct value anyway, since it
is never changed.

But note that it is still the value loaded into
the TMRH-buffer from the *last* loop that us used,
so it's a "bug" just waiting to happen, so to speek.

If you for some reason later on decides that you want
different TMR0H values each loop, you'd had a very
nasty bug there... :-)

Jan-Erik.



2007\06\28@055548 by Jinx

face picon face

> Yes, and your later findings using a 4.0 MHz xtal
> also confirms what I wrote about that it *should*
> not be an issue in *this* case since TMR0H will
> be loaded with the correct value anyway, since it
> is never changed

> If you for some reason later on decides that you want
> different TMR0H values each loop, you'd had a very
> nasty bug there... :-)

I think my findings show that 3.2768 is an entirely
inappropriate crystal for OSC1/OSC2 and results in
incorrect operation of the hardware (note how that
previously ANY value written to TMR0 is ignored).
Now that a crystal is there that, I'm surmising, the PLL
can lock onto, the hardware is operating as it should

2007\06\29@004938 by Jinx

face picon face
Just for the record

        CONFIG  FOSC= XTPLL_XT

        CONFIG  PLLDIV = 1

        CONFIG  CPUDIV = OSC1_PLL2

4MHz crystal on OSC1/OSC2

        mov     b'00000000',osccon
;                        00  primary

PIC runs at 48MHz, TMR0 fine, all's well, God's in heaven,
birds are singing, raining cats and dogs but it's only water

Thanks for all the help and suggestions

2007\06\29@045936 by Alan B. Pearce

face picon face
>PIC runs at 48MHz, TMR0 fine, all's well, God's in heaven,
>birds are singing, raining cats and dogs but it's only water

Water - you are in Britain? I thought you lot were buried under snow at the
moment ;)))

www.nzherald.co.nz/category/story.cfm?c_id=104&objectid=10447953
http://www.nzherald.co.nz/category/story.cfm?c_id=104&objectid=10447696

2007\06\29@060314 by Jinx

face picon face
> I thought you lot were buried under snow at the moment ;)))

No snow in Auckland (yet) but last week the biggest hailstones
I've ever seen. Big 'orrible jaggy things, they'd hurt. A Couple of
-19C reported down South earlier in the week. That's cold

I'm almost glad I've got PIC bugs to keep me inside ! Almost

2007\06\29@114031 by Hector Martin

flavicon
face
Jinx wrote:
> I think my findings show that 3.2768 is an entirely
> inappropriate crystal for OSC1/OSC2 and results in
> incorrect operation of the hardware (note how that
> previously ANY value written to TMR0 is ignored).
> Now that a crystal is there that, I'm surmising, the PLL
> can lock onto, the hardware is operating as it should

Well, 3.2768 is probably an entirely inappropriate frequency for the PLL
input. I'm pretty sure the PIC doesn't care what frequency you plug it
into without using the PLL, as long as it's within core spec.

Very nice information to know though. I didn't expect the 4550 PLL to be
so picky. It's still strange though - why would TMR0 act weird, while
instructions work normally? As you've mentioned, there's probably a
logical explanation for all this in the silicon. We'll probably never
find out though.

Mental note: 4Mhz ONLY really means 4Mhz ONLY.

--
Hector Martin (KILLspamhectorKILLspamspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\06\29@132126 by Dario Greggio

face picon face
Hector Martin wrote:

> Mental note: 4Mhz ONLY really means 4Mhz ONLY.

"told you so" :-)))

(but it was not me stating it, when I hear it I did not want to believe
either...)

--
Ciao, Dario

2007\06\29@173350 by Jinx

face picon face
> > Mental note: 4Mhz ONLY really means 4Mhz ONLY
>
> "told you so" :-)))

Hehe. It's one of those beer-mat truths - you learn more from
your mistakes than your successes. And learning is important

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...