Thanks Dave,

Of course you're right, it's an IIR, not a FIR. What was I thinking...

Thanks also for looking into my code about using the temp register and addi=
ng the 255.

When I simulate this code without the temp register, or without the 255, th=
en the average will
never reach 65535, but stay stuck at 65534. I first did try to add 128 (act=
ually just left shifted
temp,7 into the carry) but that didn't result in the 65535 being reached. A=
fter tracking some
values I decided to put in the 255. Not very elegant I admit, but it seems =
to work.=20

-Andries



-----Oorspronkelijk bericht-----
Van: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] Namens Dave T=
weed
Verzonden: 20 June 2012 16:02
Aan: piclist@mit.edu
Onderwerp: [PIC] assembly code for FIR filter

Andries Tip wrote:
> ;---------------------------------------------------------------------
> -------
>=20
> FIR_256_16BIT                   ; average =3D (255*average + setpoint)/25=
6
>=20
>         movf    average0,w      ; average =3D 256*average - average =3D 2=
55*average
>         sublw   d'0'            ; prepare carry
>         movwf   temp            ; save value for rounding later, otherwis=
e we cannot reach 65535
>         movf    average1,w      ;
>         subwfb  average0,f      ;
>         movf    average2,w      ;
>         subwfb  average1,f      ;
>         movlw   d'0'            ;
>         subwfb  average2,f      ;
>=20
>         movlw   d'255'          ; average =3D round((average + setpoint)/=
256)
>         addwf   temp,w          ;
>         movf    setpoint1,w     ;
>         addwfc  average0,f      ;
>         movf    setpoint2,w     ;
>         addwfc  average1,f      ;
>         clrw                    ;
>         addwfc  average2,f      ;
>=20
> ;---------------------------------------------------------------------
> -------

Taking a closer look at your code, I think it has a flaw.

First of all, the comment about "we cannot reach 65535" is simply false. Ev=
en without temp, with a steady input of 65535, the filter will definitely r=
each
65535 at the output; it just takes a very long time (i.e., 256 iterations a=
fter it reaches 65534). This is normal behavior for this type of filter.

You're using temp as an extra byte of fractional precision in your accumula=
tor, but you've made an error in doing that: When you add the new setpoint =
value to the accumulator, the operation to initialize the carry with roundi=
ng should be
128 + temp, not 255 + temp.

But, like I said at the beginning, this whole business with temp is superfl=
uous to begin with, and could simply be deleted.

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



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