As a rule of thumb, I try to avoid using floating-point in my embedded system codebase.
Floating-point variables are:
But what about a microcontroller with a floating point unit (like the STM32F4)?
Do those concerns still apply? Would you still advise against using floating-point?
If you buy a processor with a hardware FPU, you don't have the same concerns about precision*, reentrant behaviour etc. Go ahead and use them!
Couple of thoughts though:
You might consider that the processor can power down the (large) FPU when it's not used, so check that running your FP routines saves you power (if you care about that) over doing it in software.
Depending on the implementation, the FPU might also have different registers to the core - sometimes compilers can make clever use of these.
Don't use the FPU as a crutch for bad firmware design. For example, could you do the same thing with fixed point, and use the normal core instead?
(* The FPU should conform to a given standard implementation, so be aware of any limitations arising from that.)
You should remember that the FPUs on these microcontrollers are often just single-precision FPUs. Single precision floating-point has only a 24 bit mantissa (with the hidden MSB) so you may get better precision from 32 bit integers in some cases.
I have done work with using fixed-point arithmetic, and for situations where the data has a limited dynamic range you can achieve the same precision as single-precision floating point using 32-bit fixed point with about an order of magnitude improvement in execution time. I have also seen that the compiler drags in a fair amount of library overhead for the FPU.
Some of the concerns still apply.
Especially the latter one can cause very nasty problems, and force you to write non-intuitive code, e.g. always comparing against a range, never testing equality against a fixed value.
And remember that a single-precision float only has 23 bits resolution, so you might need to replace a 32-bit integer with a double-precision float.
Calculations are often fine if you have the FPU, and the trade-offs are easy to understand.
But watch for the output. If you've got anything like the C library, you'd be amazed at the complexity inherent in printf("%0.6g", x); I've seen libraries which used malloc() inside printf(), and that's not the kind of thing you'd like in a microcontroller.
double type that must be at least 48 bits wide even on platforms which just have a 32-bit floating-point hardware.
\$\endgroup\$
printf is likely to be an absolute disaster in a severely constrained environment. Fortunately, you aren't going to be using that in production. If you use it at all, it'll be for debugging, where performance isn't critical. When you care about performance, you'll need to be very aware of what your C compiler is generating or write the asm yourself. Usually you care less than you think, though.
\$\endgroup\$
Commented
Apr 18, 2020 at 10:03
Honestly this is a type of micro-optimization you should be making only after you have a fully working codebase. Some MCU's have issues with division as well, even with integers. So doing something like "multiply fp by 100, do some manipulation, divide by 100" may take much more time than just manipulating the float.
This is where profiling comes in, you need to pick your battles, there is no one answer. After you have a working code-base, you can identify bottlenecks and optimize selectively. Avoiding something as a blanket statement leads to micro optimizations that take more time to code than they actually save. Optimizing out floats from a low-priority routine that runs once an hour is useless, whereas optimizing out floats for a heavy task is useful.
Basically no need to avoid if you have a FPU, and your RTOS supports context switching of the FPU too. The precision issue still exists if you have a FPU or not. You can freely use floating point without FPU too if you have the performance to do it - occasional debug write of float variable is just fine on a FPU-less Cortex-M3. But obviously on a limited 8-bit MCU with small memory, the overhead of using even a single float operation can bring many hundred bytes of soft float library code in, so sometimes using floats makes no sense.
When to not use floating point
The first thing one needs to realize is that floating point does not mean "I need decimals". This is where some 95% of all would-be embedded programmers misusing floating point fail.
The cure for that disbelief is to realize that internally, the program should use a unit that makes sense for the MCU to use, not one that makes sense to humans.
For example if you measure current in mA with an on-chip 10 bit ADC, the convenient unit to use in software is "fixed point raw ADC values from 0 to 1024". In C programming that means a uint16_t or optionally a uint_fast16_t. Not an int and certainly not a float.
Using the unit mA inside firmware calculations is only convenient for the human programmer's brain, in case it can't handle abstract units. But it is inconvenient for the program, because it means you need to re-scale all readings to and potentially add rounding inaccuracy while doing so. Plus the scaling code is just overhead bloat. And it will likely include division, which can be painful for many MCUs.
Yeah you are reading the current in mA. But unless you actually need to print that current on a display or something to a human user, that unit is actually not helpful. Do the mA re-scaling on pen and paper while designing the algorithm, instead of dragging it into your firmware.
When to use floating point
"Advanced math" doesn't necessarily mean advanced from the programmer's perspective, but from the software's perspective. "Advanced" includes things like square roots, geometry or trigonometry, the use of math.h in general, complex numbers, AI math etc. Things that would be painful to implement in fixed point.
And if you don't have an FPU but need floating point, you picked the wrong MCU for your project.
I would exclude the non-atomic operations from the list of reasons since your ways of handling other complex structures also can be applied to float operations.
I would also exclude the computational power needed from the list of reasons since that is highly application and processor specific.
Lets focus on the "non-obvious" problems caused by the varying of the float precision
The most fundamental one is that FP arithmetic is non-associative, (a+b)+c is not equal to a+(b+c). Imagine a=1,b=-1,c=1e-20. Sounds harmless, but imagine you application is using a finite impulse filter and you run a test case which is suppose to be exactly zero
for me the second reason is the fact that integer and fixed comma operations have an overflow at the range which I expect (ok, not enabled by default in C). e.g. In floating point an integrator can easily run away to very large values without anybody noticing...
Like many things, it depends on your use case.
A bespoke integer algorithm can be more efficient (e.g. for a multiply) if you know the allowed range of input values. As those values widen, whatever you've coded is going to degenerate into a floating point multiply without benefit of hardware.
It's possible to deal with slow calculations having hard to determine timings on an embedded system by running them in a background loop, or even having different processors for e.g. control and calculation.
_Atomic floatworks similarly to_Atomic int32_tas far as atomicity and ordering, and is lock-free on normal ARM CPUs. If you think plainintis safe to use in C in general, think again. e.g. MCU programming - C++ O2 optimization breaks while loop. Re: atomic floating point - compiler/language support is basically the same as in C++: Atomic double floating point or SSE/AVX vector load/store on x86_64 / C++20 std::atomic- std::atomic.specializations \$\endgroup\$