floating point question on MSP430

package(FPP)?

I'll

It is one way to do it.

Fiddles with floating point calculations (two formats provided). RTFM.

Cheers.

-- PabloBleyerKocik /"To the electron -- may it never pbleyer2004 / be of any use to anybody." @embedded.cl / -- JJ Thomson's favorite toast

Certainly not. But doing it that way might avoid having to write any code. If that's the only reason you need to include floating point math it will likely be quite inefficient wrt code size and speed.

If the MSP430 you are using has a hardware multiplier- you can simply flip bits from the MSB down to the LSB, test (by squaring the number), correct and move down to the next bit till you get to the LSB- and it will be pretty fast and compact.

Best regards, Spehro Pefhany

Otherwise google on "Newton's method" or "Newton-Raphson". What could Sir Isaac have achieved with a PC?

Cheers, Alf

All that time he wasted writing _Principia_ could have been better spent getting to the top level of Doom.

Best regards, Spehro Pefhany

There are several methods for calculating sq root. Search the archives here and software-eng. THe one the comes to mind is a sucessive approximation method that (from MSB to LSB) sets a bit in the answer then squares the number then tests is the guess squared is larger input value. I suspect the 430 will have fast multiply.

Floating point will be large code and time wise.

Good Luck George

LOL!

Sir

A very big dent in his head instead of a bump.

Peter

package(FPP)?

I don't believe that the uC that I'm using has a hardware multiplier but I'll check. The calculation that I need to perform will only need to perform 1 square root per event. The period between each event is measured in tens of seconds. Writing a routine that sets a bit and then squares it & tests sounds like it might be the way to go.

thanks for everyones response.

David

I'll

reward"

measured

Fine if you have time to re-invent the wheel again.. if it's only of that period then use fp and get on with your application..!!

it

You make a good point. Reinventing the wheel isn't something that I'm looking to do, it's just that I'm a bit unsure of how to use the floating point tool. A guy at my day job told me that floating point was only understood by the Aseembly Language Gurus. Now, I'm sure that I could eventually figure out how to use it; it's just that right now I'm weighing the amount of time it would take to come up to speed on FP versus writing code without it.

I'm using a MSP430F149 uC. The FP tool seems to be a header file that I add into my code but when I try to compile it, the compiler pukes and says that it doesn't recognize any of the commands in that file. What am I doing wrong?

Thanks

package(FPP)?

Probably yes.

No.

For floating point arithmetics.

If all you need is an integer square root, going for FP is an overkill. There are several simple methods of computing integer (or fixed point) square root.

There's an exact square root procedure that can be used and is in Imagecraft's ICC430 package.

This suggests that you're in trouble anyway, since you don't know what features your target micro has. The F149 you are using has a hardware multiplier, but if I were you I'd use the floating point packet rather than try and write your own routine.

In a later post you state that you are using a compiler. Thus C. Most of the current C compilers have floating point procedures anyway. Probably even a sqr() function if not you need to do more than just include the header file, you must also include the *.lib file or source file that includes the actual functions.

Al

I'll

reward"

measured

it &

Hi Al,

Ok. I can see that I'm stumbling on words now. I said "compiler" but I meant "assembler". Sorry for the mixup. My C code abilities are very limited. I'm trying to do this in Assembly since I'm more familiar with that than C.

I also checked and yes, the F149 does have the hardware multiplier. I'm learning alot about this uC. As many times as I've looked at the datasheet, there are still things that I'm missing. Thanks.

I'll look into the FPP a bit closer and also evaluate some of the other suggestions made here.

Thank you for your help. I may be back . . .

I recall the tagline:

"How do you accelerate a Macintosh? 9.8 meters/second."

"David R. McCoy" writes: [snip]

Have fun with the errors, omissions, and ambiguities of the documentation...

This could be a separate thread, as TI is far from the only manufacturer to have less-than-wonderful documentation. I seriously considered writing some sort of "Programming and Using The..." book on the Zilog Z89371 DSP when I was learning/using/designing it in. I got my ass bit a bunch of times (not just the docummentation, but various features that didn't work, assembler silently and happily generating bad object code from a bad instruction, etc), and it would have been an invaluable, time-saving guide for avoiding gotcha's for anyone who would want to use that chip. For good or bad, it looks like few people wanted to use it. The MSP430 appears to have growing popularity, and it seems a book on it, especially covering gotcha's and not just being a rehash of the TI docs, might actually sell enough copies to make it worthwhile.

We could also get into a "discussion" of some manufacturers' not producing hardcopies of their docs anymore. We each get to produce our own at 10X the cost of the manufacturer doing it.

There is such a book already. I proofread it.

It's a good book.