Basic info needed regarding filters (FIR)

Suppose you code a digital lowpass filter that has some 3 dB point, some gain, and a notch at some frequency, and the coefficients have been converted from the textbook values into shifts, but that produces a 5% time-domain tail with some decay tau. How do you convey all that without comments?

Answer: you don't.

Comments aren't there to mainly to explain code execution, they are primarily to explain context and behavior. And hazards.

John

On a sunny day (Sat, 24 Nov 2007 14:25:05 -0800) it happened John Larkin wrote in :

I can usually archive a project *including all the

Whotsa floppy? ;-)

Not to feed the millions.

We formally release everything - pcb's, parts lists, firmware, fpga designs, test set designs and test procedures, eco's - to the company library, and manufacturing works from released stuff only. Release involves physical custody transfer, on a floppy for small stuff or a cd for bigger things. It gets copied to the library server and logged, and I put the original media in a baggie and stash it in the cave under my garage.

My wife received a magazine that had an ad inside for Yellow Tail wines. It was a thick full-page insert, with pictures of a bunch of insects of some sort and a caption [press here]. When you press it, the bug tails flash yellow for a while. Inside is a controller pcb, a bazillion wires, and a separate pcb for each led. I should post a pic.

Do you think that was programmed in C++?

John

We appear to be talking about different things.

Certainly, documentation is often necessary. The documentation may be embedded in the source file as comments; nowadays, it's common for such comments to use a distinct syntax so that they can be automatically extracted from the code for inclusion in the manual, e.g. Doxygen. But that information should be provided whether the code is supplied as source code or a pre-compiled library. If you're not supplying source code, having that information in comments alone won't help.

OTOH, "normal" comments such as those which appear at the RHS of most lines in your assembler code are seldom necessary in a high-level language. At least, not for code, although it may be useful to comment declarations of variables and structure fields if their meaning cannot be adequately conveyed by their name alone.

Also, regarding the use of shifts: if you multiply or divide an integer by a constant which is a power of two, modern compilers will automatically generate a shift instruction. They'll also convert multiplication by arbitrary constants into a sequence of shift and addition/subtract instructions if it will be faster than a multiplication instruction (unless you tell them to optimise for smaller code size over faster execution).

doesn't

the

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?

There is a facility called setjmp/longjmp which can be used for this sort of thing. However ISRs are outside the official C language, so I think whether it works would be dependent on the implementation on your system. So use assembler just for that bit (the stack reset and jump).

A C based application will generally have a small amount of assembler to support it. This is usually confined to startup code and wrappers for interrupt handlers. It is also used for code which manipulates the stack, like task-switching and like your example.

This is commonly done in C systems too, where on-chip ram is faster than flash. It is quite easy to do, since C has do do this already, for initialized data. You tell the linker to put the code in the same segment as initialised data, and the C startup code automatically does the copying for you.

doesn't

the

Oh, I do a lot of numerical and system simulation, but I do it in PowerBasic. There are lots of situations, like doing a weird pll, or a Hilbert in an FPGA, where nothing but simulation will tell you what the quantization issues will be.

The filter that I posted was for cleaning up thermocouple samples. All the math was 32 bits, and the bata was noisy to start, so any limit cycles in this case would be way down in the mud. I used two versions of the filter, one for the control loop and a *really* slow one for the user display! Everybody wanted to see the 0.1 degree digit hold steady, even though turbulence downstream of the heater was flailing the t/c temperature around almost 1 degree RMS.

I guess, but loading a floppy is quicker... drag and drop. Ten or 20 cents doesn't matter when the data cost $50K to create.

We run a bunch of DOS machines in test racks and stuff, and flops are handy for them, too.

John

have

rarely a

doesn't

suggesting the

I have given up on CD-R or CD_RW now too. Only DVD or memory stick or SDcards. Not that I use it, but with UDF and packet writing, you can drag and drop to DVD or CD too, already in win 98 actually.

But SDcards are way cool, perhaps even keep data longer then DVD. It makes sense to use both.