Mauro, Chuck wrote:
>
> Now this is more like it!
>
> It's these little pearls of wisdom that I was hoping to see on this
> list!
>
> This one goes in the code fragment tool box...  Thanks Scott!

Actually, you should thank Andy.

And then I wrote:

> > If I make it to work tomorrow then I'll re-post the gory
> > reasons why this works.

Well, I made it to work (barely) and here's a copy of the post
I sent last July that explains this stuff to a degree guranteed
to induce boredom.

Andrew Warren wrote:
> >        ; 5 cycles per count (2.5 uS per count)
> >
> >         CHECK_PULSE:
> >
> >             INCFSZ   pulse_width_lo
> >             DECF     pulse_width_hi
> >
> >             BTFSC    PULSE_PORT,PULSE_BIT
> >             GOTO     CHECK_PULSE
> >
> >         DONE:
> >
> >             MOVF     pulse_width_lo,W    ;**** Corrected
> >             ADDWF    pulse_width_hi

Was it only me or did anybody else out there appreciate the
significance of this code? Probably only half the list was impressed,
half could care less, and the remaining half of us miscounted the
number of cycles.

Here's how this beaut works:
  Each time through the loop, the low byte of the pulse width is
incremented. The high byte is decremented every iteration EXCEPT
when the low byte rolls over, i.e. when the low byte is incremented
from 255 to 0.

An arbitrary 16-bit number may be written in terms of two unique
8-bit numbers as:

  X = a*256 + b

And we want to count the number iterations so that we end up with:
  X = pulse_width_hi*256 + pulse_width_low
  or
  pulse_width_lo = b
  pulse_width_hi = a

At the label DONE the contents of the variables are:

  pulse_width_lo = b
  pulse_width_hi = (-255*a - b) mod 256

In other words, we already have the low byte. The high byte requires
some explanation. First, the number of times the low byte rolls over
is 'a' times. For each rollover, we decrement the high byte 255 times.
This accounts for the "-255*a". The remaining 'b' times we also
decrement the high byte. The "mod 256" just emphasizes that we
are dealing with 8-bit variables.

MOD identities:
 The pulse_width_hi expression can be simplified:

  pulse_width_hi = (-255*a - b) mod 256

                 = ( (-255*a) mod 256 - b mod 256 ) mod 256

                 = ( ((-255 mod 256)*(a mod 256)) mod 256 - b ) mod 256
      because i) b mod 256 = b   by definition
             ii)  (x*y) mod z = ( (x mod z) * (y mod z) ) mod z

                 = ( ((1 mod 256) * a) mod 256 - b) mod 256
      because i) a mod 256 = a   by definition
             ii)  -x mod z = (z - x) mod z

  pulse_width_hi = (a - b) mod 256

And finally, the last two instructions add 'b' to pulse_width_hi

  pulse_width_hi = (a - b + b) mod 256
                 = a !!!! (as in excitement not factorial)


Consider these examples

 259 iterations:
   259 = 1*256 + 3
   at DONE, pulse_width_lo = 3 and
            pulse_width_hi = (0 - 255 - 3) mod 256 = -2 mod 256 = 0xfe.

And 0xfe + 3 = 1.

 515, at DONE pulse_width_lo = 3 and _hi would be
 (0 - 255*2 - 3) mod 256 = 0xff. And 0xff + 3 = 2.
 and 515 = 2*256 + 3

 12803, at DONE pulse_width_lo = 3 and _hi would be
(0 - 255*50 - 3) mod 256 = 0x2f. And 0x2f + 3 = 0x32.
 and 12803 = 50*256 + 3 (and 50 base 10 = 0x32).

After a private congratulations to Andy I get this response:

>  Geez, Scott, it's only an itty-bitty loop...

Come on Andy, quit being so MODest.

Scott
--
"The problem with television is not the resolution."
                                 Hugh. F. Frohbach