Re: Basic info needed regarding filters (FIR)

On Nov 24, 2:25 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 24 Nov 2007 13:33:56 -0800 (PST), m...@xxxxxxxxx wrote:
On Nov 24, 10:39 am, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 24 Nov 2007 11:41:08 -0600, Vladimir Vassilevsky

<antispam_bo...@xxxxxxxxxxx> wrote:

John Larkin wrote:

On Fri, 23 Nov 2007 12:43:10 -0600, Vladimir Vassilevsky
<antispam_bo...@xxxxxxxxxxx> wrote:

Here is the basic realpole filter which is simpler and appears to have
almost identical response:

const u8 order = 4;

s32 LPF(s32 x)
{
static s32 z[order];

for(u8 i = 0; i < order; i++) x = z[i]+= (x - z[i])>>6;

return x;
}

Making digital filter as the simulation of an analog filter is rarely a
good idea.

I've sold over 3000 of the temperature controllers that use this
filter.

McDonalds serves somewhat 10 billion meals per year. But this fact doesn't
make those meals taste any better or worse :)

Selling things for high prices to high-end customers, in volume, for
years, bug-free, means we're doing exactly what we want to do. Any
other criterion for engineering quality is, literally, academic.

Why whining about the Evil Empire of Bill Gates then?

Because it's slow, bloated, and bug-ridden, from a company run by
sociopaths who crush competition out of sheer ruthlessness.

I am sorry if you didn't understand 3 lines of trivial C code without
comments. It would be a good idea to do some learning before suggesting the
advanced digital filter topologies...

I've made a solemn vow to never code in C.

Yes. C++ is lot better.

Funny! I write apps that run in, typically, 4-6 kilobytes of eprom and
2K of ram, manage a few FPGAs and a VME or serial/ethernet interface,
run thousands of interrupts per second, and have guaranteed response
times in the 100 usec sort of range, 100% of the time. And never
crash.

But comments don't explain
code, comments explain what code is for and what it does. Your filter
is just a heap of code. I have no idea what it's response is like, and
would have to analyze or simulate it to determine that.
So, what is its frequency response?

Here:

1/64
H(Z) = (---------------) ^ 4
63
1 - --- Z^-1
64

So, what is its frequency response?

John

I suppose you could use the bilnear transform to map it into the S
domain, then do a spread*** to see the response.

Learning basic C isn't that difficult. The object oriented flavor is
another story.

What I'm doing works.

I have the UART interrupt service routine, which builds a string from
edited input characters. When the command string is done, it sets a
flag to let the main loop know that a command string is ready, and the
main loop in turn calls the command parser, which executes the string.
The box I'm doing now has exactly 100 distinct serial commands. Some
user commands can call certain canned sequences, stored as strings,
which the parser executes re-entrantly. So far so good.

But some command strings can take a long time, perhaps minutes, to
execute. So I've assigned one serial character as an abort. When the
ISR sees this, it just resets the stack and jumps to the top of the
main opside loop, totally dumping whatever was going on and starting
fresh. I've asked a couple of my C guys how they would do this in C,
and the answers were sort of mumbles.

Another thing I like to do is copy a chunk of code, like the FPGA
loader, from eprom into a block of cpu ram, and execute it from there.
That speeds things up by 2:1 or so... no byte-wide bus fetches. Then I
can use that block of ram for normal system variables. All that sort
of thing is easy in assembly.

All my embedded programs are monolithic, absolute assemblies of a
single source file. I can usually archive a project *including all the
tools* on a single floppy. The program listings are heavily commented,
neatly paged, and start with an automatically generated table of
contents, which makes it really easy to see the structure and find
whatever you may be looking for. I can revisit a years-old project and
find what I want in seconds.

The methodology is ancient, like making bread in wood-fired ovens. But
it works.

John

Even if you prefer assembler, you would benefit from learning C. I had
a project where we weren't sure exactly how the word width effected
performance, so the hardware was emulated in C. Once we understood the
rounding issues, we knew how to build the hardware for real. OK, we
made it one bit wider just in case...

In your application, you might experiment with the DSP filter in C,
get a handle on the number of taps required, then program it in
assembler. I didn't look carefully at your particular app, but IIR
filters have settling issues in DSP. You get more bang (filtering) for
the buck (cycles), but FIR is free from limit cycle issues.

To sum it up, C may not be your in final product, but it can be a
usefull development tool.

BTW, isn't a CDROM cheaper than a floppy?
.