Raghunathan:
It is my suggestion that if you are doing a program that involves some polynomial calculations that you should definately setup and use C code. This is particularly valuable if the "formulas" and "transfer functions" need to go through some cycle of development and refinement.

I have, in the past, done complex chained calculations in assembler language and, let me tell you, it is a pain setting up and keeping track of all the intermeiate results. And then when one comes back to change things it is so often that you forget some little detail or some trick you put in the code. The change ends up not working correctly and you spend many valuable hours (or maybe even days) debugging these details.

It is for this reason that whenever a project is going to involve any amount of numerical calculation stuff I will change over to using C as opposed to assembler language. BUT that also means that I have to re-evaluate performance of the processor. In C one is often tempted to use floating point format as opposed to working out a scaled integer approach. Also in C if an integer format is applicable one often falls right into the 32-bit long / unsigned long format for computations where a 24 bit or 20 bit approach from assembler language prespective may have been adequate. These "automatic upgrades" to your code cost something in execution time and as such may be an issue to a specific application. Thus it is nice to have a chance to select a processor that is fast enough to carry out your arithmetic as fast as you need. (8052s are particularly nice becasue of the huge, multi-vendor selection of parts available. Wow from /12 clocked parts @12 MHz all the way to 100 MHz /1 clocked parts).

There is another issue where using C code in an embedded application can be valuable in the ease that formulas, lookup tables, and calibration constants usage can be integrated into the final code. I will very often work with a client or some scientist that needs to have an easy way to work at modeling the formulas, transfer functions, and look up table values on their PC. For these I use either an EXCEL spreadsheet or a MATHCAD worksheet. With these one can setup the initial model of the calculations and check the results with measured or expected results. Then the client, who usually knows little about programming (and often does not care to) can mess around with the models using their experience with the process or system. After the models are tweeked just right it is really nice to literally copy the formulas out and paste them into your C code in the target application. (The real benefit of this is appreciated down the road when it becomes necessary to tweak again becasue now the customer wants to use a different sensor or they find a need to change/add a calibration constant). That original modeling file comes immediately into play even before you go breakout the release CDs and un-zip the source code.

I have also devised a system that I think is totally cool as well. There are many applications where a lookup table can be an invaluable way increase performance in an embedded real time application. The values stored in the lookup table may be derived from some computed formula. Quite often this formula is derived using a curve fit technique from 2 or 3 or 4 empirical data points. I have built models in EXCEL for example where I actually organize the spreadsheet to compute and tabulatize the lookup table data in the exact textual syntax of the target product source code.
Then using a marked block copy from EXCEL I can paste this "source code" right into the application code and recompile. Thus if some of the empirical data points get changed I just change the spreadsheet, do a new cut and paste to the project source code and re-compile.

Thanks for letting me share those comments.
Michael Karas

PS Just for grins if anybody wants to see one of these "spreadsheet that makes lookup table" modeling projects just drop me a note via email and I would be happy to send it to you.
MJK
mkaras@CarouselDesign.com