Scott Dattalo wrote:

>I think you can extend the concept to 16 samples (or whatever) per loop
>instead of 8 and do something like this

I'll look at that.


>> The other observation is slightly more serious, I think.  If the routine
>> exits without incrementing any counters, (enters the routine but the pin
>> went or was non-active - zero time) an erroneous result will occur.  I think
>> the solution is simple: relpace the 'SKPZ' below with 'SKPC'.  Of course - I
>> might be out to lunch . . .
>
>I thought about that too. The skpc to skpz change won't fix it though.
>It may be easier to add a flag that's initialized before the sampling
>begins, and is cleared in the loop. Then during the normalization you
>can check the flag and process the counters accordingly. It might also
>be necessary to sample the IOPORT once before the loop begins and abort
>if it's already high. Tell us how you decide to solve it :).

Scott - how about a little bit different slant on things.  Instead of
shifting the counter bytes over to make room for the LSBs accumulated by
the main loop, why not just add those LSBs to the count, propogating
carries as required.  The main loop doesn't have to be a power of 2 states
and allows easy addition of the overflow logic.

That is:

Counter routine that gives 3-cycle resolution:

        CLRF    count_3lsbs
        CLRF    count_low
        CLRF    count_mid
        CLRF    count_high

loop
        BTFSC   IOPORT,IOBIT
         goto   went_high_1st

        MOVLW   1
        BTFSC   IOPORT,IOBIT
         goto   went_high_2nd

        ADDWF   count_low,F
        BTFSC   IOPORT,IOBIT
         goto   went_high_3rd

        RLF     count_3lsbs,W   ;shift C into W (add 0 or 1 to next byte)
        BTFSC   IOPORT,IOBIT
         goto   went_high_4th

        ADDWF   count_mid,F
        BTFSC   IOPORT,IOBIT
         goto   went_high_5th

        RLF     count_3lsbs,W
        BTFSC   IOPORT,IOBIT
         goto   went_high_6th

        ADDWF   count_high,F
        BTFSC   IOPORT,IOBIT
         goto   went_high_7th

        CLRWDT
        BTFSC   IOPORT,IOBIT
         goto   went_high_8th

        SKPC                    ;test for overflow
         BTFSC  IOPORT,IOBIT
          goto  went_high_9th

        BTFSS   IOPORT,IOBIT
         goto   loop

went_high_10th
        INCF    count_3lsbs,F

went_high_9th
        INCF    count_3lsbs,F

went_high_8th
        INCF    count_3lsbs,F

went_high_7th
        skpnc
          goto  overflow
        SUBWF   count_high,F
        INCF    count_3lsbs,F

went_high_6th
        INCF    count_3lsbs,F

went_high_5th
        tstf    count_low       ;had low byte wrapped?
        skpnz
         decf   count_mid,F
        INCF    count_3lsbs,F

went_high_4th
        INCF    count_3lsbs,F

went_high_3rd
        DECF    count_low,F
        INCF    count_3lsbs,F

went_high_2nd
        INCF    count_3lsbs,F

went_high_1st

        MOVF    count_3lsbs,W
        ADDWF   count_low,F
        SKPC
         goto   done

        INCFSZ  count_mid,F
         goto   done

        INCFSZ  count_high,F
          goto  done

overflow                        ;wrapped past ff ff ff - hold at ff
        movlw   ff
        movwf   count_low
        movwf   count_mid
        movwf   count_high

done


Now, having done all that, I think that I see a fundamental problem with
the middle byte in your routine.  Assume that the loop terminated at the
6th, or later exits.  There is no way of knowing whether the middle byte
had incremented or not: the carry information is lost.  In other words,
just because the high byte didn't increment, that doesn't say that the
middle byte didn't also.  The middle byte could have incremented without
wrapping.  I fixed it by seeing if the low byte was zero at that point.
I think that it will work (I'll try tommorrow, after I've heard your
thoughts).

dwayne