> On Fri, 21 Jan 2000, Jeffrey Siegel wrote:
>
> > Does anyone know of a software library (source code) that I could port to
> > the PIC for real-time filtering?  I'm grabbing A/D data and want to do some
> > basic artifact removal in software (real-time hopefully, before sending it
> > to another processor) but I need a starting place of some working code.  Any
> > language would be fine...

I accidently deleted you're other response... dammit.

Let me ask the question more specifically. In the low-pass filter case,
for example, do you want to implement an FIR or an IIR? What kind of
signal bandwidth are you seeking. How much passband ripple are you willing
to tolerate? Are you just trying to remove some sampling clock artifact?
What's the application?

If you're looking for general purpose signal processing, then you probably
don't want to waste your time with pics - at least not the 12 and 14 bit
cores. Digital signal processing (as taught at your college) relies
heavily on multiply and accumulate operations. The low end pics don't have
a multiplier, the high end ones do, but can't do a single cycle MAC. Butt,
there's always a trick. Unfortunately, the tricks are seldom generic. For
example, the 'twist' routine I posted the other day, can be used as
low-pass, one-tap, IIR filter. It implements this 'transfer function':

f = (m*x + n*y)/N

Subject to the conditions:

log2(N) is an integer (N is a power of 2, e.g. 16, 32, 64...)

m + n = N

x and y are the inputs and f is the output.

Now if you make f = y, which is to say that for the next iteration through
the filter, you use the results of the previous iteration for y, you'll
have a low pass recursive (IIR) filter. The pole can be adjusted by
varying the coefficients. I haven't performed any kind of frequency
analysis on this, but if you take the z transform:

f = y(i+1) = (m*x(i) + n*y(i))/N
    zY(z)  = (m*X(z) + n*Y(Z))/N
   m*X(z)  = (N*z - n)Y(z)
     Y(z)        m        m/N
    -----  = -------- = --------
     X(z)     N*z - n    z - n/N

The pole, n/N, is always less than one and thus within the 'unit circle'.
Consequently the filter is stable. If you make n small, you get a slower
response. As n approaches N and the pole gets closer to one, the response
is faster.

Now it's possible to cascade these blocks too, and somewhat tailor your
filter's cutoff, ripple, etc...

But theory aside, this simple example ignores many practical issues. The
original code I posted used N=16. This gives you only 4 bits of dynamic
range on your coefficients. You'd be hard pressed getting arbitrary pole
placement with this much dynamic range. Quantization erro will kill you.
But again, it depends on your application.

So, what is it you said you're trying to do?

Scott