¿Se aplica la regla general "Evitar el uso de coma flotante" a un microcontrolador con una unidad de coma flotante (FPU)?

Question

Como regla general, intento evitar el uso de coma flotante en el código de mis sistemas embebidos.

Las variables de coma flotante son:

• Computación intensiva
• No atómico (puede causar problemas en una aplicación RTOS o con interrupciones)
• Su precisión puede provocar comportamientos no evidentes (problema de comparación de flotadores).

Pero ¿qué pasa con un microcontrolador con un unidad de coma flotante (como el STM32F4)?

¿Siguen siendo válidas esas preocupaciones? ¿Seguiría desaconsejando el uso de coma flotante?

Answer 1

Básicamente no es necesario evitarlo si tienes una FPU, y tu RTOS también soporta el cambio de contexto de la FPU. El problema de la precisión sigue existiendo tanto si tienes una FPU como si no. Puedes utilizar libremente el punto flotante sin FPU también si tienes el rendimiento para hacerlo - la escritura ocasional de depuración de la variable flotante está bien en un Cortex-M3 sin FPU. Pero, obviamente, en un MCU limitado de 8 bits con poca memoria, la sobrecarga de utilizar incluso una sola operación flotante puede traer muchos cientos de bytes de código de biblioteca flotante suave, por lo que a veces el uso de flotantes no tiene sentido.

Answer 2

Cuándo no utilizar la coma flotante

Lo primero que hay que tener en cuenta es que el punto flotante no no significa "necesito decimales". Aquí es donde fallan el 95% de los programadores de sistemas embebidos que hacen un mal uso de la coma flotante.

La cura para esa incredulidad es darse cuenta de que internamente, el programa debe utilizar una unidad que tenga sentido para la MCU de usar, no una que tenga sentido para los humanos.

Por ejemplo, si se mide la corriente en mA con un ADC de 10 bits integrado en el chip, la unidad que conviene utilizar en el software es "valores ADC brutos de punto fijo de 0 a 1024". En programación C eso significa un uint16_t u opcionalmente un uint_fast16_t . No es un int y ciertamente no un float .

Utilizar la unidad mA dentro de los cálculos del firmware sólo es conveniente para el cerebro del programador humano, en caso de que no pueda manejar unidades abstractas. Pero es inconveniente para el programa, ya que significa que usted necesita para volver a escalar todas las lecturas y, potencialmente, añadir inexactitud redondeo mientras lo hace. Además, el código de escala es sólo una sobrecarga. Y es probable que incluya la división, que puede ser doloroso para muchos MCUs.

Sí, estás leyendo la corriente en mA. Pero a menos que realmente necesites imprimir esa corriente en una pantalla o algo para un usuario humano, esa unidad no es realmente útil. Haz la re-escala de mA en lápiz y papel mientras diseñas el algoritmo, en lugar de arrastrarlo a tu firmware.

---

Cuándo utilizar la coma flotante

• Si tu MCU tiene una FPU y realmente necesitas hacer matemáticas avanzadas entonces debe utilizar coma flotante. En caso contrario, no.

"Matemáticas avanzadas" no significa necesariamente avanzadas desde la perspectiva del programador, sino del software. "Avanzadas" incluye cosas como raíces cuadradas, geometría o trigonometría, el uso de math.h en general, números complejos, matemáticas de IA, etc. Cosas que sería doloroso implementar en punto fijo.

Answer 3

• Yo excluiría las operaciones no atómicas de la lista de razones, ya que sus formas de manejar otras estructuras complejas también pueden aplicarse a las operaciones con flotadores.

• También excluiría de la lista de razones la potencia de cálculo necesaria, ya que es algo muy específico de la aplicación y del procesador.

Centrémonos en los problemas "no evidentes" causados por la variación de la precisión del flotador

• La más fundamental es que la aritmética FP no es asociativa, (a+b)+c no es igual a a+(b+c). Imagina a=1,b=-1,c=1e-20. Suena inofensivo, pero imagina que tu aplicación está utilizando un filtro de impulsos finitos y ejecutas un caso de prueba que se supone que es exactamente cero

• para mí la segunda razón es el hecho de que las operaciones con enteros y coma fija tienen un desbordamiento en el rango que yo espero (vale, no está activado por defecto en C). por ejemplo, en coma flotante un integrador puede escaparse fácilmente a valores muy grandes sin que nadie se dé cuenta...

Answer 4

Como muchas otras cosas, depende de su caso de uso.

Un algoritmo entero hecho a medida puede ser más eficiente (por ejemplo, para una multiplicación) si se conoce el rango permitido de valores de entrada. A medida que esos valores se amplían, lo que hayas codificado va a degenerar en una multiplicación en coma flotante sin el beneficio del hardware.

En un sistema integrado, los cálculos lentos con tiempos difíciles de determinar pueden ejecutarse en un bucle en segundo plano o incluso con procesadores distintos para, por ejemplo, el control y el cálculo.