Kenneth MacCallum

4 Tips for using floating point computations in firmware

Digital Health: Floating Away

 The Z3 included floating-point arithmetic: Nachbau der Zuse Z3 im Deutschen Museum in München

Nachbau der Zuse Z3 im Deutschen Museum in München
Attribution: Venusianer at the German language Wikipedia

Until very recently I would never have dreamed of using floating point computations in firmware. It required too heavy a penalty in code space and computation time. Suddenly the game changed considerably.  Now there are a number of relatively inexpensive microcontrollers which have single-precision floating point capabilities implemented in hardware.
Here are things I keep in mind while coding and debugging.

1. Check code execution time regularly. It’s pretty easy to accidentally prevent the compiler from even using the floating-point unit (FPU). Plus there’s still plenty of computations that can only be implemented in software. Burning excessive CPU time can crop up for many reasons and not just for teething issues with a new tool chain or getting used to a new compiler. For instance, it’s really easy to forget the “f” at the end of a constant and suddenly a whole line of math gets promoted to double.

Some functions just take a bunch of time, although not always predictably. The mod operator is a good example. If the dividend is considerably bigger than the divisor then it often blows up into way more instruction cycles than you’d ever expect. I surround chunks of code with port twiddles and scope them. If the measured time is way off from what I estimate or what I require then I dig down to see what’s going on and what can be done. Android vs Apple

2. Regularly check the assembly (or disassembly as it’s often called in the development environment). This makes it quite plain if the compiler has decided to use soft math. On an ARM processor, I look for lots of instructions with F32 in them; if I don’t see them then something’s wrong. It’s also instructive to see some of the decisions the compiler makes. Sometimes compilers can be incredibly smart, other times not.

3. Remember that floating point is still limited. Single precision floating point only has a 24 bit mantissa. It may seem stupidly obvious, but this is actually 8 bits less than 32 bit fixed point! When I add two numbers that are significantly different in magnitude, the smaller one is going lose a bunch of precision. This can often be quite severe.  I still go through the same sort of analysis I used with fixed point: I make sure I understand the worst case precision loss as my calculations propagate. This is a bit of a chore but it’s better than discovering after some in-the-field troubleshooting that my signal is noticeably stair-stepping or my integral control term is looking suspiciously binary.

4. Many implementations of floating point – like IEEE 754 – include special values that can cause a whole bunch of trouble. We’re all familiar with divide by zero exceptions when we’re programming PCs.  In firmware the FPU still flags these events and goes one step further. If you divide a number by zero or add, multiply or divide a number until it overflows, you will get either plus or minus infinity (+INF, -INF). If you divide zero by zero, or try to square root a negative number you get not-a-number (NaN). These three values can cause a ton of trouble for any math that has state. For instance they will instantly knock an IIR filter dead. Dead for good. These numbers don’t go away in the math chain; every subsequent calculation gets contaminated.

The only way I’ve come up with to deal with NaNs and INFs is to plan for them. Testing for them is easy, either test results or query the FPU state. The tricky part is deciding what to do when I find one. I might think that getting a NaN is ridiculously unlikely but just imagine what the result is: my math flat lines forever.

So I ask myself a number of questions. Does it make sense to zero the value? What would that do to the output of my control loop? Is it even possible to sensibly cope with the situation or would it be best to stop everything and wait for operator input. Sometimes the strategy to fix everything can be quite complicated if it’s important that the system does not go off line. Whatever I decide, I have to be careful that all state variables – anything that retains a value for use in future computations – are repaired.

Having an FPU often does not necessarily make life easier. Much of the same good practice in fixed point math still applies. Nevertheless, it’s pretty amazing what modern microcontrollers can do. I’d be interested to hear any strategies that readers use when using floating point math.

Kenneth MacCallum, PEng, is a Principal Engineering Physicist at Starfish Medical. He works on Medical Device Development and uses floating point calculations in Digital Health and  ultrasound applications.

One response to “4 Tips for using floating point computations in firmware”

  1. Large-scare program of plastic extruders can reduce creation fees.
    a ceramic heater the current is automatically minimized.
    This heated plastic is also kept moving rapidly to prevent any premature hardening or deformities on the finished product.

Leave a Reply

Your email address will not be published. Required fields are marked *

Join over 6000 medical device professionals who receive our engineering, regulatory and commercialization insights and tips every month.