Jack Poulson wrote: > Unluckily, state-space calculations are usually chalk-full of all those > guys. > > Thankfully, C is my language of choice, and I'd be more than happy with > any references at all. > > On 7/14/07, M. Edward (Ed) Borasky <[EMAIL PROTECTED]> wrote: >> >> Jack Poulson wrote: >> > There flight tests proved the current system inefficient for all of the >> > planned computation and communication with the groundserver. They >> > claimed to be using a 416 Mhz xscale, which seems fairly beefy to me, >> > and I was under the impression that ramming floating point instructions >> > through a fixed-point register was grossly inefficient. >> > >> > However, I am very new to embedded systems, and your question >> > makes me think that the control algorithm itself is the culprit. >> >> In all likelihood you are emulating IEEE floating point in software, >> most likely because fixed point algorithms aren't all that well known >> outside of old fogeys like myself and people with a lust for squeezing >> the ultimate out of embedded hardware. >> >> If you're lucky, it's only 32-bit arithmetic. If you're *real* lucky, >> there are no logs, exponentials or trig functions in the code. If you're >> really really lucky, there aren't even any divides or square roots. :) >> >> By the way, it's been so long since I did any of this stuff that I don't >> know where one can find *current* references on the subject. But if >> you're willing to get your hands dirty in C and/or Forth code, there are >> some rewards waiting for you. You'd be amazed how much interesting stuff >> you can do with table lookup. >> -- >> [EMAIL PROTECTED] mailing list >> >> > The general rule is, "if the hardware ALU can't do it, use table lookup." :)
Another general rule is "16-bit arithmetic is your friend" But just getting rid of floating point emulation might be all you need at 416 MHz. -- [EMAIL PROTECTED] mailing list
