Andries Tip wrote:
> Thanks also for looking into my code about using the temp register and
> adding the 255.
>=20
> When I simulate this code without the temp register, or without the 255,
> then the average will never reach 65535, but stay stuck at 65534. I first
> did try to add 128 (actually just left shifted temp,7 into the carry) but
> that didn't result in the 65535 being reached. After tracking some values=
 I
> decided to put in the 255. Not very elegant I admit, but it seems to work=
..=20

I was puzzling about this all day, but I think I finally figured out what t=
he
problem is. I even wrote a high-level simulation of the arithmetic (a Perl
script) to help me visualize the details.

When you add an offset of 128 to temp, the 24-bit average eventually settle=
s
at the value 0xFFFE81. When you look at the high-order 16 bits of this to g=
et
your integer result, you can't just ignore the other 8 bits -- you need to
properly round this 24-bit quantity to get the actual 16-bit result by addi=
ng
0x000080 and then truncating, which gives you the true value of 0xFFFF.

So, I guess by using a temp offset of 255 instead of 128 in the body of the
filter, you're essentially adding this output-rounding offset into the inpu=
t
values going into the filter. I guess there's nothing really wrong with doi=
ng
that, as long as you, and users of your code, understand the ramifications =
of
doing it.

-- Dave Tweed
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.