On Tue, 25 Feb 2003, Roman Black wrote:

> What about detecting the / edge with the capture int,
> but don't bother time check/subtract etc.
> When you capture a / edge, simply load one of the timers
> to 50uS (between your 2 pulse widths) and when that timer
> int occurs all you need to do is check the input, which
> will give 0 for 25uS pulse and 1 for a 75uS pulse.
> You don't need to do any period measurement and it's
> very low in cycles. ;o)

This is a good suggestion but it has two problems. First, there will be
some jitter between when the edge occurs and when the timer is started.
The CCP module records the value of the timer at the point when the event
occurs. The second problem is that it really isn't any faster. In fact, by
the time you get through initializing/unloading/reloading the counter
you'll have spent just as much time with the roll over arithmetic. Neither
of these issues really affect my application too much.

In my application, I'm actually measuring the width of two pulses
referenced to the same edge:

___--------------___________________________---------------
  |<---- P1 --->|
  |<-------------------- P2 -------------->|
  ^             ^                          ^
  +- start timer|                          |
                + read timer               |
              Read timer and restart timer +

The Read/Restart action happens at every rising edge. Instead of loading a
timer and monitoring the interrupt, I could envision code like this:

    movff    tmrxLo, RisingEdgeLo    ; save the current time
    movff    tmrxHi, RisingEdgeHi    ; save the current time

    clrf     tmrxLo                  ; Restart the timer
    clrf     tmrxHi

That's about twice as fast as reading the Captured time and using rollover
arithmetic. Well, okay it's not quite twice as fast since there is some
processing that I didn't show that takes advantage of the carry bits in
the arithmetic. But instead of loading the "count down" timer with a
16-bit value and waiting for the interrupt, I think it's faster to start
and restart the timer at the edges.

In the snippet of code I posted earlier, I didn't show the falling edge
processing. It's very similar to the rising edge processing, but takes
only 9 cycles instead of 13. But for grins, here it is:

process_falling_edge:

        MOVFF   CCPR1L,TC_PulseLo       ;Save the time when the last edge
        MOVFF   CCPR1H,TC_PulseHi       ;was captured

        MOVF    TC_LastRisingEdgeLo,W   ;Compute the time since the last
        SUBWF   TC_PulseLo,F            ;rising edge
        MOVF    TC_LastRisingEdgeHi,W   ;
        SUBWFB  TC_PulseHi,F

Again, for the timer start/restart approach, the falling edge processing
is about twice as fast as this.

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body