> Two cascaded single pole filters each with a filter fraction of 1/256
> A divide by 256 is a shift right of 8 bits, which is just moving bytes =
around
>   new filt val =3D <old filt val> - <old filt val>/256 + <input =
val>/256

This looks so simple but something goes terrible wrong for me ...=20

If the sample (input value) is 0:255 the routine counts down !
I have tried to calc the new value by doing small parts like sample/256
and then add/subrtact them up as shown below. This fails in the=20
subtraction where the routine calcs down instead of up, as it should=20
with sample-input val of 0:255. Right ? Sample is always in the range of =
0-255
I have simulated this in Excel, works fine there. (not tried as fixed =
point math tho)

Must this be done with floating point math ???


     ; // calc: 'input/256' //
  movfw sampleA
  movwf tempL  ; move high-byte to low-byte makes /256
  clrf tempH  ; set high byte to 0
     ; Now 'input/256' is in tempH:tempL

     ; // calc: 'old/256' //
  movfw FilterAH ; get old value.=20
  movwf temp1L  ; move high-byte to low-byte makes /256
  clrf temp1H  ; set high byte to 0
     ; Now 'old/256' is in temp1H:temp1L

 =20
     ; // calc: 'old/256' + 'input/256'
  movf tempL, W
  addwf temp1L, F ; W eller F ?

  movf tempH, W
  btfsc STATUS, C
  incfsz tempH, W
  addwf temp1H, F ; W eller F ?
     ; Now 'old/256' + 'input/256' is in temp1H:temp1L

     ; // calc: 'old' - ('old/256' + 'input/256') //
  movf temp1L, W
  subwf FilterAL, F
  movf temp1H, W
  btfss STATUS,C
  incfsz temp1H, W
  subwf FilterAH, F
     ; Now FINAL RESULT should be in FilterAH:FilterAL !

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.