This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

16 bit up down counter

Hi

I have to use a 16 bit up/down counter...... I wrote the code for that in at89c51. The counting is made in external interrupt 0. The pulses are given by a linear scale.
the count values are stored in mem location 50 and 51. The up counting or down counting is decided by the state of the 3.0 and 3.1 pins

counter:
        jnb p3.0,ru
        jnb p3.1,rd
        reti

rd:     push acc
        mov a,51h  ;up counting
        add a,#01h
        jc bb
        sjmp aa
bb:     inc 50h
aa:     inc 51h
        pop acc
        reti

ru:     push acc  ;down counting
        mov a,51h
        clr c
        subb a,#01h
        jc dd
        sjmp cc
dd:     dec 50h
cc:     dec 51h
        pop acc
        reti

Now the issue that i face is that the pulses are too fast and most of the time he controller is in interrupt sub and does not have time for updating the lcd and send data serially.
so i might need a hardware up&down counter. I tried the at89s8252 but during down counting the th2 and tl2 registers are reset to zero and then the downcounting starts.

Is there any other way or should i use the 16 bit 2016 updown counter IC ( :-( too costly )

Thanks

Parents
  • How close are you to being able to handle the processing requirements? We could make suggestions to improve the addition routine, but it probably won't make a huge difference. If you're within a factor of two of being able to squeeze in the function, perhaps. Otherwise, you're going to need some hardware support or a faster CPU clock.

    Here's one possible tweak to the code. The 16-bit increment takes 6 instruction cycles, where the original took 12 (if both bytes needed to be incremented). The main trick here is avoiding the push/pop of the accumulator thanks to the exchange (xch) instruction.

    You could replace the increment of the upper byte with a test of the carry and an inc. This results in the same worst-case time, 3 cycles to increment the second byte, but only 2 cycles whenever the increment isn't needed. That is, 255/256ths of the time, it saves one clock.

    The 8051 assembly wizards in the forum might well be able to make more improvements. (Maybe there's a trick possible with INC DPTR, or DJNZ.) But if your pulse rate is three or more times as high as you can currently handle, then there's not much software optimization can do.

    counter:
            jnb p3.0,ru
            jnb p3.1,rd
            reti
    
    ru:     ; up counting
            xch  a,51h     ;1
            add  a,#01h    ;1
            xch  a,51h     ;1
    
            xch  a,50h     ;1
            addc a,#00h    ;1
            xch  a,50h     ;1
    
            reti           ;2
    
    ru2:     ; up counting version 2
            xch  a,51h     ;1
            add  a,#01h    ;1
            xch  a,51h     ;1
    
            jnc UpDone     ;2
            inc 50h        ;1
    UpDone:
            reti           ;2
    
    

Reply
  • How close are you to being able to handle the processing requirements? We could make suggestions to improve the addition routine, but it probably won't make a huge difference. If you're within a factor of two of being able to squeeze in the function, perhaps. Otherwise, you're going to need some hardware support or a faster CPU clock.

    Here's one possible tweak to the code. The 16-bit increment takes 6 instruction cycles, where the original took 12 (if both bytes needed to be incremented). The main trick here is avoiding the push/pop of the accumulator thanks to the exchange (xch) instruction.

    You could replace the increment of the upper byte with a test of the carry and an inc. This results in the same worst-case time, 3 cycles to increment the second byte, but only 2 cycles whenever the increment isn't needed. That is, 255/256ths of the time, it saves one clock.

    The 8051 assembly wizards in the forum might well be able to make more improvements. (Maybe there's a trick possible with INC DPTR, or DJNZ.) But if your pulse rate is three or more times as high as you can currently handle, then there's not much software optimization can do.

    counter:
            jnb p3.0,ru
            jnb p3.1,rd
            reti
    
    ru:     ; up counting
            xch  a,51h     ;1
            add  a,#01h    ;1
            xch  a,51h     ;1
    
            xch  a,50h     ;1
            addc a,#00h    ;1
            xch  a,50h     ;1
    
            reti           ;2
    
    ru2:     ; up counting version 2
            xch  a,51h     ;1
            add  a,#01h    ;1
            xch  a,51h     ;1
    
            jnc UpDone     ;2
            inc 50h        ;1
    UpDone:
            reti           ;2
    
    

Children