Dmitry Kiryashov wrote:
>
> Hi Tony.
>
> Can you explain what do you mean getting back in sync with internal clock ?
> Situation is following: prescaler=1, internal osc/4 is used.
>
> WBR Dmitry.
>
> > > > Another question: I still can't understand what was the real reason to introduce
> > > > 2 clocks delay in TMR0 increment after loading TMR0 with new value.
> > > I don't know either. I suspect that there's some kind of pipeline thing that has
> > > to get flushed and updated, but that's just a guess
> > To me it looks like the SYNC circuit takes two cycles to get back in
> > sync with the internal clock after writing to TMR0. (Another guess)

If you look at the data sheet and the TMR0 block diagram, you will see a
SYNC circuit following the PSA MUX. The data sheet mentions a (2 cycle
delay) under the SYNC block. Whether this is coincidence or related, I
don't know.

>> > > > Another question: I still can't understand what was the real
>>reason to introduce
>> > > > 2 clocks delay in TMR0 increment after loading TMR0 with new value.
>> > > I don't know either. I suspect that there's some kind of pipeline
>>thing that has
>> > > to get flushed and updated, but that's just a guess
>> > To me it looks like the SYNC circuit takes two cycles to get back in
>> > sync with the internal clock after writing to TMR0. (Another guess)
>
>If you look at the data sheet and the TMR0 block diagram, you will see a
>SYNC circuit following the PSA MUX. The data sheet mentions a (2 cycle
>delay) under the SYNC block. Whether this is coincidence or related, I
>don't know.

Would it be too simplistic to assume that for any TMR0 write, one
instruction cycle would be used for the instruction fetch, the second cycle
would be execute (on Q4 as per the diagrams), leaving the new value in TMR0
for the third instruction. Only during the third instruction can TMR0 be
incremented. Basically whatever happened to it during the fetch and execute
is ignored.