Dear Erik,

I'm really astonished, why you not see, what is obvious.

Again, loading and counting are not the same !

And on the 8051 both are done in different clock cycles of the 12 xtal clocks of every CPU cycle, so no interference can occur.

Following an example code, which read a counter with two ways, the XCH way works right but the MOV way works wrong as I already expected it.

Thus after the second routine was finished only the P1.7 was set.

The only difference, this example code use mode 1 and not mode 3. But this make no difference, if an overflow from the low byte increment the high byte or set the overflow flag.

        mov     p1, #0
        mov     tmod, #1        ; T0: Mode 1
        setb    tr0             ; run TR0

        mov     r0, #0F0h
m1:     mov     tl0, r0
        mov     th0, #0
        mul     ab              ; 4 cycle delay

        clr     a
        xch     a, tl0          ; read and clear simultaneous !!!
        mov     r7, a
        mov     r6, th0

        cjne    r6, #0, m2      ; >= 256
        cjne    r7, #0F0h, m3
m3:     jnc     m4              ; >= 0F0h
        setb    p1.4            ; error, val < 000F0h
        sjmp    m4
m2:     cjne    r7, #020h, m5
m5:     jc      m4
        setb    p1.5            ; error, val > 00120h
m4:     inc     r0
        cjne    r0, #0FCh, m1

        mov     r0, #0F0h
m11:    mov     tl0, r0
        mov     th0, #0
        mul     ab              ; 4 cycle delay

        mov     a, tl0          ; read
        mov     tl0, #0         ; clear to late !!!
        mov     r7, a
        mov     r6, th0

        cjne    r6, #0, m12     ; >= 256
        cjne    r7, #0F0h, m13
m13:    jnc     m14             ; >= 0F0h
        setb    p1.6            ; error, val < 000F0h
        sjmp    m14
m12:    cjne    r7, #020h, m15
m15:    jc      m14
        setb    p1.7            ; error, val > 00120h
m14:    inc     r0
        cjne    r0, #0FCh, m11

        sjmp    $
end

I tested it with the simulator and the real target (AT89C4051) and all what I can tell is, that the result was exact this, what I tried to tell you alle these posts above.

Now I'm unable to do more.

Please check it the next time, before you tell, that something was wrong.


Naturally there exist other ways to read a timer on the fly.
And also it is possible to stop the timer and perform a 16 bit addition to correct the timer value by the cycle count, during which the timer was stopped.
But all these ways need more code.


Peter