Programación integrada de máquinas de estado

8

Estoy buscando implementar una máquina de estado finito no trivial (especificada como un diagrama de estado jerárquico UML) en una MCU de 32 bits con gcc.

¿Existen reglas generales que funcionen mejor y que funcionen menos? Mi instinto dice que una implementación basada en conmutadores (o incluso computada) debería ser ligeramente más eficiente, mientras que una tabla de transición basada en punteros de función generalmente tiene la reputación de ser más fácil de mantener.

Además: ¿alguien ha evaluado Boost MSM para aplicaciones integradas? Sé que Boost MSM generalmente se elogia por ser muy eficiente, pero para las aplicaciones integradas, la eficiencia puede medirse de manera diferente que en el mundo de la programación de PC.

¿Alguien sabe cómo se ve el motor de máquina de estado compilado de MSM? ¿Más como una tabla de salto de interruptor o más como una tabla de transición de puntero de función? ¿Utiliza asignación de memoria dinámica o puede usarse estáticamente?

embedded programming state-machines ARF
fuente
Me mantendría alejado de Boost MSM (y las plantillas de C ++ en general) ya que explotan el tamaño del código muy rápido.
jms
Hay algunas otras trampas en C ++ a tener en cuenta ...
Matt Young
@jms Eso es como decir que un leñador debe mantenerse alejado de las herramientas afiladas y usar un martillo en su lugar porque con herramientas afiladas podría cortarse. Las plantillas son una herramienta afilada que, cuando se usa de la manera correcta, puede aumentar la velocidad y reducir el tamaño de su código, especialmente para microcontroladores pequeños. Cuando se usa de manera incorrecta, bueno, ¡ cualquier herramienta se puede usar de manera incorrecta!
Wouter van Ooijen

Respuestas:

8

Me sorprendería si hay una gran diferencia en un MCU de 32 bits. Evitar las ramas condicionales podría ahorrarle algunos ciclos, pero ¿realmente va a tener éxito o fracasar en función de unos pocos ciclos? El número de estados de espera en su RAM y ROM es probablemente al menos igual de importante. Así es el conjunto de instrucciones de la CPU.

La optimización prematura es la fuente de todos los males. Comience con lo que es más fácil de implementar y mantener, y solo optimice cuando sea necesario en función de la creación de perfiles.

Adam Haun
fuente
Esperaría que la influencia en el rendimiento de un marco de máquina de estado (ya sea bricolaje o de alguna biblioteca), en oposición a las acciones, sea muy pequeña. Entonces, como dice Adam: primero el código de legibilidad. Un segundo. Y tercero. (A en la décima posición: perfil. La optimización local está muy por debajo de eso.)
Wouter van Ooijen
3

Para una implementación UML en embebido, eche un vistazo a QP framework -> http://www.state-machine.com . Ambas variantes C y C ++ están disponibles. La GUI acompañante (QM) incluso permite codificar usando notación UML. El marco es lo suficientemente pequeño como para ejecutarse en Arduino; 32-bitters son fáciles.

Oleg Mazurov
fuente