¿Cuál es la importancia de las máquinas de estados finitos (FSM) con respecto a la implementación de sistemas integrados?

Estaba estudiando un proyecto que involucra la implementación de un convertidor de corrección del factor de potencia sin puente (BL PFC) controlado digitalmente. Utiliza PWM para impulsar el controlador de compuerta del interruptor MOSFET y un ADC para detectar V e I para el bucle de control y voltaje del sistema de control.

Referencia general

También descubrí que han implementado una máquina de estados finitos para todo el sistema (en el archivo CCS .c).

¿Por qué se implementó un FSM? ¿Es una práctica estándar en la industria implementar un FSM para un proyecto? ¿Puede dar un ejemplo de implementación de FSM en una aplicación de sistema integrado simple?

¿De qué otra manera lo harías?
¿Por qué no comenzaron directamente con la programación convencional (es decir, la programación para diferentes periféricos) una vez que conocieron el requisito de la topología BL PFC?
Cuando se utilizan FSM, los estados se pueden codificar como datos. Cambiar el comportamiento de la FSM es tan simple como cambiar los datos.
Puede que esté ciego, pero ¿dónde está la máquina de estado? No puedo encontrarlo. CCS es el entorno de desarrollo, que maneja los archivos .c y .asm. Los diagramas de bloques no son FSM-s, son una ilustración del diseño del programa a menos que lo lea incorrectamente.

Respuestas (4)

Una FSM es un método estructurado para construir una máquina secuencial. La máquina sólo puede existir en un número fijo de estados discretos, es decir, 'estado finito'.

Se puede probar formalmente la exactitud de las FSM. Otros beneficios son que son fáciles de construir en código y depurar. Pasar de un diagrama de estado a escribir código es un proceso sencillo.

Los semáforos son una aplicación común utilizada para demostrar las FSM. Hay millones de ejemplos en la web. Un microprocesador es otro ejemplo de FSM, aunque algo más complejo.

Al usar un microcontrolador para implementar un mecanismo de control como el que usted describe, la mayoría de los programadores construirían/programarían intuitivamente una especie de máquina de estado de todos modos.

Haces una cosa específica a la vez (estado) y cambias (transición) a un comportamiento diferente (siguiente estado) dependiendo de la información externa.

Existen marcos de código que pueden ayudar a implementar máquinas de estado de manera limpia. Eso puede ser útil si tiene una gran cantidad de estados con mucha información estatal y transiciones complejas.
Pero para máquinas de estado muy simples, a menudo es suficiente tener una caja de interruptores que refleje los estados y algunas funciones auxiliares para administrar las transiciones.

No pude encontrar el código: ¿Pero cuál es la alternativa?

Cuando tiene pasos (estados) para ejecutar, aunque un FSM es la mejor y más obvia solución. Es fácil dibujar diagramas para. Un tipo de enumeración para los estados es una lista rápida y obvia de estados posibles. Generalmente da como resultado un código fácil de leer y mantener (solo una declaración de cambio de caso). También tiene pocos requisitos de memoria y tiempo de ejecución (solo una variable para el estado y una instrucción de salto).

La otra opción sería una colección suelta de bits/variables de estado y declaraciones if. A veces, a medida que crece el código, comienzas a introducir dichos bits de estado. Este es un buen momento para hacer una pausa y evaluar si un FSM no sería una forma mejor y más limpia de implementar su código.

Soy ingeniero de diseño digital, los FSM son nuestro pan y mantequilla. Al menos para el código RTL, las herramientas de linting y cobertura de código generalmente "entienden" las FSM y pueden proporcionar información útil (por ejemplo, transiciones de estado que no están cubiertas).

Así es como lo veo.
Si la salida de un sistema está determinada por sus entradas actuales, puede formar una tabla de verdad y esa tabla de verdad puede hacerse mediante un árbol lógico (if..if..else....)
Si hay alguna historia involucrada, el El sistema tiene que tener memoria. Y luego, la salida depende de las entradas actuales y los valores en la memoria.
Si no hay solo una salida, sino que tienen que suceder varias cosas según las entradas y las condiciones históricas, ahora necesita una forma de nombrar cada condición resultante según los rastros que pueden conducir a esa condición. Debe poder nombrarlos para que pueda razonar sobre lo que debería suceder en otras entradas en tales condiciones.
Para hacer posible que varias personas hablen sobre tales sistemas, se necesita un paradigma. Una forma de ver un sistema como un conjunto de estas condiciones de las que hablamos y los eventos que causan el movimiento entre estas condiciones, junto con cualquier otra acción que suceda junto con el movimiento.
Ese paradigma es una máquina de estado. Las máquinas de estado pueden tener diferentes estados (condiciones en el párrafo anterior), eventos/señales (entradas) y transiciones entre estados, junto con posibles acciones a la salida de un estado, entrada de un estado, transición, etc. Luego tenemos UML con
estado gráficos, herramientas para generar código a partir de gráficos de estado visuales, verificar estados sin salida, estados imposibles, etc.
Esencialmente, los FSM brindan un nuevo lenguaje para el pensamiento sobre los sistemas y para la expresión de dicho pensamiento. Algo más que el código puede hacer.

¡Traté de darle una justificación de que los FSM son un resultado natural!