c++ - machine - Diseño de máquina de estado C
machine state in c (24)
Estoy elaborando un pequeño proyecto en C y C mixtos. Estoy construyendo una pequeña máquina estatal en el corazón de uno de mis hilos de trabajo.
Me preguntaba si los gurús de SO compartirían sus técnicas de diseño de máquina de estado.
NOTA: estoy principalmente después de las técnicas de implementación probadas y comprobadas.
ACTUALIZADO: Basado en toda la gran información recopilada en SO, me he decidido por esta arquitectura:
Asegúrese de revisar el trabajo de Miro Samek (blog State Space , sitio web State Machines & Tools ), cuyos artículos en C / C ++ Users Journal fueron geniales.
El sitio web contiene una implementación completa (C / C ++) tanto de código abierto como comercial de un marco de máquina de estado (QP Framework) , un controlador de eventos (QEP) , una herramienta de modelado básico (QM) y una herramienta de seguimiento (QSpy) que permite dibujar máquinas de estado, crear código y depurarlas.
El libro contiene una explicación extensa sobre el qué / por qué de la implementación y cómo usarlo y también es un gran material para comprender los fundamentos de las máquinas de estado jerárquico y finito.
El sitio web también contiene enlaces a varios paquetes de soporte de la placa para el uso del software con plataformas integradas.
Extremadamente no probado, pero divertido de codificar, ahora en una versión más refinada que mi respuesta original; las versiones actualizadas se pueden encontrar en mercurial.intuxication.org :
sm.h
#ifndef SM_ARGS
#error "SM_ARGS undefined: " /
"use ''#define SM_ARGS (void)'' to get an empty argument list"
#endif
#ifndef SM_STATES
#error "SM_STATES undefined: " /
"you must provide a list of comma-separated states"
#endif
typedef void (*sm_state) SM_ARGS;
static const sm_state SM_STATES;
#define sm_transit(STATE) ((sm_state (*) SM_ARGS)STATE)
#define sm_def(NAME) /
static sm_state NAME ## _fn SM_ARGS; /
static const sm_state NAME = (sm_state)NAME ## _fn; /
static sm_state NAME ## _fn SM_ARGS
ejemplo.c
#include <stdio.h>
#define SM_ARGS (int i)
#define SM_STATES EVEN, ODD
#include "sm.h"
sm_def(EVEN)
{
printf("even %i/n", i);
return ODD;
}
sm_def(ODD)
{
printf("odd %i/n", i);
return EVEN;
}
int main(void)
{
int i = 0;
sm_state state = EVEN;
for(; i < 10; ++i)
state = sm_transit(state)(i);
return 0;
}
He hecho algo similar a lo que describe paxdiablo, solo que en lugar de una matriz de transiciones de estado / evento, configuré una matriz bidimensional de punteros de funciones, con el valor de evento como el índice de un eje y el valor de estado actual como el otro. Entonces simplemente llamo a state = state_table[event][state](params) y sucede lo correcto. Las células que representan combinaciones de estado / evento no válidas obtienen un puntero a una función que lo dice, por supuesto.
Obviamente, esto solo funciona si los valores de estado y evento son rangos contiguos y comienzan en 0 o lo suficientemente cerca.
La técnica que me gusta para las máquinas de estado (al menos para el control de programa) es usar punteros de función. Cada estado está representado por una función diferente. La función toma un símbolo de entrada y devuelve el puntero de función para el siguiente estado. Los monitores de ciclo de envío central toman la siguiente entrada, la alimentan al estado actual y procesan el resultado.
El tipeo se vuelve un poco extraño, ya que C no tiene forma de indicar los tipos de punteros de función que se devuelven, por lo que las funciones de estado devuelven void* . Pero puedes hacer algo como esto:
typedef void* (*state_handler)(input_symbol_t);
void dispatch_fsm()
{
state_handler current = initial_handler;
/* Let''s assume returning null indicates end-of-machine */
while (current) {
current = current(get_input);
}
}
Luego, sus funciones de estado individuales pueden activar su entrada para procesar y devolver el valor apropiado.
Las otras respuestas son buenas, pero una implementación muy "ligera" que he usado cuando la máquina de estado es muy simple se ve así:
enum state { ST_NEW, ST_OPEN, ST_SHIFT, ST_END };
enum state current_state = ST_NEW;
while (current_state != ST_END)
{
input = get_input();
switch (current_state)
{
case ST_NEW:
/* Do something with input and set current_state */
break;
case ST_OPEN:
/* Do something different and set current_state */
break;
/* ... etc ... */
}
}
Utilizaría esto cuando la máquina de estado es lo suficientemente simple como para que el puntero de la función y el enfoque de tabla de transición de estado sean excesivos. Esto a menudo es útil para el análisis de carácter por carácter o palabra por palabra.
Perdónenme por romper todas las reglas en ciencias de la computación, pero una máquina de estado es uno de los pocos lugares (solo puedo contar dos) donde una declaración goto no solo es más eficiente, sino que también hace que su código sea más limpio y fácil de leer. Debido a que las declaraciones goto se basan en etiquetas, puede nombrar sus estados en lugar de tener que realizar un seguimiento de un desorden de números o utilizar una enumeración. También hace que el código sea mucho más limpio, ya que no necesita todo el resto de punteros de función o grandes instrucciones de conmutación y ciclos while. ¿Mencioné que es más eficiente también?
Esto es lo que podría parecer una máquina de estados:
void state_machine() {
first_state:
// Do some stuff here
switch(some_var) {
case 0:
goto first_state;
case 1:
goto second_state;
default:
return;
}
second_state:
// Do some stuff here
switch(some_var) {
case 0:
goto first_state;
case 1:
goto second_state;
default:
return;
}
}
Usted obtiene la idea general. El punto es que puede implementar la máquina de estado de una manera eficiente y que es relativamente fácil de leer y le grita al lector que está mirando una máquina de estado. Tenga en cuenta que si está utilizando instrucciones goto , debe tener cuidado ya que es muy fácil dispararse en el pie mientras lo hace.
Puede considerar el compilador de máquinas del estado http://smc.sourceforge.net/
Esta espléndida utilidad de código abierto acepta una descripción de una máquina de estado en un lenguaje simple y la compila en una docena de idiomas, incluidos C y C ++. La utilidad en sí está escrita en Java y se puede incluir como parte de una compilación.
La razón para hacer esto, en lugar de la codificación manual usando el patrón de estado GoF o cualquier otro enfoque, es que una vez que su máquina de estado se expresa como código, la estructura subyacente tiende a desaparecer bajo el peso del modelo que debe generarse para soportarlo. Usar este enfoque le brinda una excelente separación de preocupaciones y mantiene la estructura de su máquina de estado ''visible''. El código generado automáticamente se inserta en módulos que no necesita tocar, de modo que puede retroceder y manipular la estructura de la máquina de estados sin afectar el código de soporte que ha escrito.
Lo siento, estoy siendo demasiado entusiasta y, sin duda, decepciono a todos. Pero es una utilidad de primer nivel, y también bien documentada.
Stefan Heinzmann, en su article "armazón" de máquina de estados C ++ basado en plantillas muy agradable.
Como no hay ningún enlace para descargar un código completo en el artículo, me he tomado la libertad de pegar el código en un proyecto y verificarlo. El material que se incluye a continuación se prueba e incluye las pocas piezas faltantes menores pero bastante obvias.
La principal innovación aquí es que el compilador genera código muy eficiente. Las acciones de entrada / salida vacías no tienen costo. Las acciones de entrada / salida no vacías están en línea. El compilador también verifica la integridad de la tabla de estado. Las acciones faltantes generan errores de enlace. Lo único que no se detecta es la falta de Top::init .
Esta es una muy buena alternativa a la implementación de Miro Samek, si puede vivir sin lo que falta, esto está lejos de ser una implementación completa de UML Statechart, aunque implementa correctamente la semántica de UML, mientras que el código de Samek por diseño no maneja salida / transición / acciones de entrada en el orden correcto.
Si este código funciona para lo que necesita hacer, y tiene un compilador C ++ decente para su sistema, probablemente tendrá un mejor rendimiento que la implementación C / C ++ de Miro. El compilador genera una implementación de máquina de estado de transición O (1) aplanada para usted. Si la auditoría del resultado del ensamblaje confirma que las optimizaciones funcionan como se desea, se acerca al rendimiento teórico. La mejor parte: es un código relativamente pequeño y fácil de entender.
#ifndef HSM_HPP
#define HSM_HPP
// This code is from:
// Yet Another Hierarchical State Machine
// by Stefan Heinzmann
// Overload issue 64 december 2004
// http://accu.org/index.php/journals/252
/* This is a basic implementation of UML Statecharts.
* The key observation is that the machine can only
* be in a leaf state at any given time. The composite
* states are only traversed, never final.
* Only the leaf states are ever instantiated. The composite
* states are only mechanisms used to generate code. They are
* never instantiated.
*/
// Helpers
// A gadget from Herb Sutter''s GotW #71 -- depends on SFINAE
template<class D, class B>
class IsDerivedFrom {
class Yes { char a[1]; };
class No { char a[10]; };
static Yes Test(B*); // undefined
static No Test(...); // undefined
public:
enum { Res = sizeof(Test(static_cast<D*>(0))) == sizeof(Yes) ? 1 : 0 };
};
template<bool> class Bool {};
// Top State, Composite State and Leaf State
template <typename H>
struct TopState {
typedef H Host;
typedef void Base;
virtual void handler(Host&) const = 0;
virtual unsigned getId() const = 0;
};
template <typename H, unsigned id, typename B>
struct CompState;
template <typename H, unsigned id, typename B = CompState<H, 0, TopState<H> > >
struct CompState : B {
typedef B Base;
typedef CompState<H, id, Base> This;
template <typename X> void handle(H& h, const X& x) const { Base::handle(h, x); }
static void init(H&); // no implementation
static void entry(H&) {}
static void exit(H&) {}
};
template <typename H>
struct CompState<H, 0, TopState<H> > : TopState<H> {
typedef TopState<H> Base;
typedef CompState<H, 0, Base> This;
template <typename X> void handle(H&, const X&) const {}
static void init(H&); // no implementation
static void entry(H&) {}
static void exit(H&) {}
};
template <typename H, unsigned id, typename B = CompState<H, 0, TopState<H> > >
struct LeafState : B {
typedef H Host;
typedef B Base;
typedef LeafState<H, id, Base> This;
template <typename X> void handle(H& h, const X& x) const { Base::handle(h, x); }
virtual void handler(H& h) const { handle(h, *this); }
virtual unsigned getId() const { return id; }
static void init(H& h) { h.next(obj); } // don''t specialize this
static void entry(H&) {}
static void exit(H&) {}
static const LeafState obj; // only the leaf states have instances
};
template <typename H, unsigned id, typename B>
const LeafState<H, id, B> LeafState<H, id, B>::obj;
// Transition Object
template <typename C, typename S, typename T>
// Current, Source, Target
struct Tran {
typedef typename C::Host Host;
typedef typename C::Base CurrentBase;
typedef typename S::Base SourceBase;
typedef typename T::Base TargetBase;
enum { // work out when to terminate template recursion
eTB_CB = IsDerivedFrom<TargetBase, CurrentBase>::Res,
eS_CB = IsDerivedFrom<S, CurrentBase>::Res,
eS_C = IsDerivedFrom<S, C>::Res,
eC_S = IsDerivedFrom<C, S>::Res,
exitStop = eTB_CB && eS_C,
entryStop = eS_C || eS_CB && !eC_S
};
// We use overloading to stop recursion.
// The more natural template specialization
// method would require to specialize the inner
// template without specializing the outer one,
// which is forbidden.
static void exitActions(Host&, Bool<true>) {}
static void exitActions(Host&h, Bool<false>) {
C::exit(h);
Tran<CurrentBase, S, T>::exitActions(h, Bool<exitStop>());
}
static void entryActions(Host&, Bool<true>) {}
static void entryActions(Host& h, Bool<false>) {
Tran<CurrentBase, S, T>::entryActions(h, Bool<entryStop>());
C::entry(h);
}
Tran(Host & h) : host_(h) {
exitActions(host_, Bool<false>());
}
~Tran() {
Tran<T, S, T>::entryActions(host_, Bool<false>());
T::init(host_);
}
Host& host_;
};
// Initializer for Compound States
template <typename T>
struct Init {
typedef typename T::Host Host;
Init(Host& h) : host_(h) {}
~Init() {
T::entry(host_);
T::init(host_);
}
Host& host_;
};
#endif // HSM_HPP
El código de prueba sigue.
#include <cstdio>
#include "hsm.hpp"
#include "hsmtest.hpp"
/* Implements the following state machine from Miro Samek''s
* Practical Statecharts in C/C++
*
* |-init-----------------------------------------------------|
* | s0 |
* |----------------------------------------------------------|
* | |
* | |-init-----------| |-------------------------| |
* | | s1 |---c--->| s2 | |
* | |----------------|<--c----|-------------------------| |
* | | | | | |
* |<-d-| |-init-------| | | |-init----------------| | |
* | | | s11 |<----f----| | s21 | | |
* | /--| |------------| | | |---------------------| | |
* | a | | | | | | | | |
* | /->| | |------g--------->|-init------| | | |
* | | |____________| | | |-b->| s211 |---g--->|
* | |----b---^ |------f------->| | | | |
* | |________________| | |<-d-|___________|<--e----|
* | | |_____________________| | |
* | |_________________________| |
* |__________________________________________________________|
*/
class TestHSM;
typedef CompState<TestHSM,0> Top;
typedef CompState<TestHSM,1,Top> S0;
typedef CompState<TestHSM,2,S0> S1;
typedef LeafState<TestHSM,3,S1> S11;
typedef CompState<TestHSM,4,S0> S2;
typedef CompState<TestHSM,5,S2> S21;
typedef LeafState<TestHSM,6,S21> S211;
enum Signal { A_SIG, B_SIG, C_SIG, D_SIG, E_SIG, F_SIG, G_SIG, H_SIG };
class TestHSM {
public:
TestHSM() { Top::init(*this); }
~TestHSM() {}
void next(const TopState<TestHSM>& state) {
state_ = &state;
}
Signal getSig() const { return sig_; }
void dispatch(Signal sig) {
sig_ = sig;
state_->handler(*this);
}
void foo(int i) {
foo_ = i;
}
int foo() const {
return foo_;
}
private:
const TopState<TestHSM>* state_;
Signal sig_;
int foo_;
};
bool testDispatch(char c) {
static TestHSM test;
if (c<''a'' || ''h''<c) {
return false;
}
printf("Signal<-%c", c);
test.dispatch((Signal)(c-''a''));
printf("/n");
return true;
}
int main(int, char**) {
testDispatch(''a'');
testDispatch(''e'');
testDispatch(''e'');
testDispatch(''a'');
testDispatch(''h'');
testDispatch(''h'');
return 0;
}
#define HSMHANDLER(State) /
template<> template<typename X> inline void State::handle(TestHSM& h, const X& x) const
HSMHANDLER(S0) {
switch (h.getSig()) {
case E_SIG: { Tran<X, This, S211> t(h);
printf("s0-E;");
return; }
default:
break;
}
return Base::handle(h, x);
}
HSMHANDLER(S1) {
switch (h.getSig()) {
case A_SIG: { Tran<X, This, S1> t(h);
printf("s1-A;"); return; }
case B_SIG: { Tran<X, This, S11> t(h);
printf("s1-B;"); return; }
case C_SIG: { Tran<X, This, S2> t(h);
printf("s1-C;"); return; }
case D_SIG: { Tran<X, This, S0> t(h);
printf("s1-D;"); return; }
case F_SIG: { Tran<X, This, S211> t(h);
printf("s1-F;"); return; }
default: break;
}
return Base::handle(h, x);
}
HSMHANDLER(S11) {
switch (h.getSig()) {
case G_SIG: { Tran<X, This, S211> t(h);
printf("s11-G;"); return; }
case H_SIG: if (h.foo()) {
printf("s11-H");
h.foo(0); return;
} break;
default: break;
}
return Base::handle(h, x);
}
HSMHANDLER(S2) {
switch (h.getSig()) {
case C_SIG: { Tran<X, This, S1> t(h);
printf("s2-C"); return; }
case F_SIG: { Tran<X, This, S11> t(h);
printf("s2-F"); return; }
default: break;
}
return Base::handle(h, x);
}
HSMHANDLER(S21) {
switch (h.getSig()) {
case B_SIG: { Tran<X, This, S211> t(h);
printf("s21-B;"); return; }
case H_SIG: if (!h.foo()) {
Tran<X, This, S21> t(h);
printf("s21-H;"); h.foo(1);
return;
} break;
default: break;
}
return Base::handle(h, x);
}
HSMHANDLER(S211) {
switch (h.getSig()) {
case D_SIG: { Tran<X, This, S21> t(h);
printf("s211-D;"); return; }
case G_SIG: { Tran<X, This, S0> t(h);
printf("s211-G;"); return; }
}
return Base::handle(h, x);
}
#define HSMENTRY(State) /
template<> inline void State::entry(TestHSM&) { /
printf(#State "-ENTRY;"); /
}
HSMENTRY(S0)
HSMENTRY(S1)
HSMENTRY(S11)
HSMENTRY(S2)
HSMENTRY(S21)
HSMENTRY(S211)
#define HSMEXIT(State) /
template<> inline void State::exit(TestHSM&) { /
printf(#State "-EXIT;"); /
}
HSMEXIT(S0)
HSMEXIT(S1)
HSMEXIT(S11)
HSMEXIT(S2)
HSMEXIT(S21)
HSMEXIT(S211)
#define HSMINIT(State, InitState) /
template<> inline void State::init(TestHSM& h) { /
Init<InitState> i(h); /
printf(#State "-INIT;"); /
}
HSMINIT(Top, S0)
HSMINIT(S0, S1)
HSMINIT(S1, S11)
HSMINIT(S2, S21)
HSMINIT(S21, S211)
Caso más simple
enum event_type { ET_THIS, ET_THAT };
union event_parm { uint8_t this; uint16_t that; }
static void handle_event(enum event_type event, union event_parm parm)
{
static enum { THIS, THAT } state;
switch (state)
{
case THIS:
switch (event)
{
case ET_THIS:
// Handle event.
break;
default:
// Unhandled events in this state.
break;
}
break;
case THAT:
// Handle state.
break;
}
}
Puntos: el estado es privado, no solo para la unidad de compilación, sino también para event_handler. Los casos especiales se pueden manejar por separado desde el interruptor principal usando cualquier construcción que se considere necesaria.
Caso más complejo
Cuando el interruptor se hace más grande que un par de pantallas, divídalo en funciones que manejen cada estado, usando una tabla de estado para buscar la función directamente. El estado sigue siendo privado para el controlador de eventos. Las funciones del controlador de estado devuelven el siguiente estado. Si es necesario, algunos eventos aún pueden recibir un tratamiento especial en el controlador del evento principal. Me gusta incluir pseudo eventos para ingresar y salir del estado y quizás indicar el inicio de la máquina:
enum state_type { THIS, THAT, FOO, NA };
enum event_type { ET_START, ET_ENTER, ET_EXIT, ET_THIS, ET_THAT, ET_WHATEVER, ET_TIMEOUT };
union event_parm { uint8_t this; uint16_t that; };
static void handle_event(enum event_type event, union event_parm parm)
{
static enum state_type state;
static void (* const state_handler[])(enum event_type event, union event_parm parm) = { handle_this, handle_that };
enum state_type next_state = state_handler[state](event, parm);
if (NA != next_state && state != next_state)
{
(void)state_handler[state](ET_EXIT, 0);
state = next_state;
(void)state_handler[state](ET_ENTER, 0);
}
}
No estoy seguro si encontré la sintaxis, especialmente con respecto al conjunto de indicadores de función. No he ejecutado nada de esto a través de un compilador. Tras la revisión, noté que olvidé descartar explícitamente el siguiente estado al manejar los pseudo eventos (el paréntesis (vacío) antes de la llamada a state_handler ()). Esto es algo que me gusta hacer, incluso si los compiladores aceptan la omisión en silencio. Le dice a los lectores del código que "sí, realmente quise llamar a la función sin usar el valor de retorno", y puede evitar que las herramientas de análisis estático adviertan al respecto. Puede ser idiosincrásico porque no recuerdo haber visto a alguien más haciendo esto.
Puntos: al agregar un poco de complejidad (verificando si el siguiente estado es diferente del actual), se puede evitar el código duplicado en otro lugar, porque las funciones del manejador de estado pueden disfrutar los pseudo eventos que ocurren cuando se ingresa y se abandona un estado. Recuerde que el estado no puede cambiar cuando se manejan los pseudo eventos, porque el resultado del manejador de estado se descarta después de estos eventos. Por supuesto, puede elegir modificar el comportamiento.
Un manejador de estado se vería así:
static enum state_type handle_this(enum event_type event, union event_parm parm)
{
enum state_type next_state = NA;
switch (event)
{
case ET_ENTER:
// Start a timer to do whatever.
// Do other stuff necessary when entering this state.
break;
case ET_WHATEVER:
// Switch state.
next_state = THAT;
break;
case ET_TIMEOUT:
// Switch state.
next_state = FOO;
break;
case ET_EXIT:
// Stop the timer.
// Generally clean up this state.
break;
}
return next_state;
}
Más complejidad
Cuando la unidad de compilación se vuelve demasiado grande (lo que sea que sienta que es, debería decir alrededor de 1000 líneas), coloque cada manejador de estado en un archivo separado. Cuando cada controlador de estado se vuelve más largo que un par de pantallas, divida cada evento en una función separada, similar a la forma en que se dividió el interruptor de estado. Puede hacer esto de varias maneras, por separado del estado o mediante el uso de una tabla común, o combinando varios esquemas. Algunos de ellos han sido cubiertos aquí por otros. Ordena tus tablas y utiliza la búsqueda binaria si la velocidad es un requisito.
Programación genérica
Me gustaría que el preprocesador se ocupe de cuestiones como ordenar tablas o incluso generar máquinas de estado a partir de las descripciones, lo que le permite "escribir programas sobre programas". Creo que esto es para lo que las personas de Boost están explotando las plantillas de C ++, pero la sintaxis me resulta críptica.
Tablas bidimensionales
He usado tablas de estado / evento en el pasado, pero debo decir que para los casos más simples no los considero necesarios y prefiero la claridad y la legibilidad de la declaración de cambio incluso si se extiende más allá de una pantalla. Para casos más complejos, las tablas se salen de control rápidamente, como otros han notado. Los modismos que presento aquí le permiten agregar una gran cantidad de eventos y estados cuando lo desee, sin tener que mantener una tabla que consuma memoria (incluso si puede ser memoria de programa).
Renuncia
Las necesidades especiales pueden hacer que estos modismos sean menos útiles, pero los he encontrado muy claros y fáciles de mantener.
Alrght, I think mine''s just a little different from everybody else''s. A little more separation of code and data than I see in the other answers. I really read up on the theory to write this, which implements a full Regular-language (without regular expressions, sadly). Ullman, Minsky, Chomsky. Can''t say I understood it all, but I''ve drawn from the old masters as directly as possible: through their words.
I use a function pointer to a predicate that determines the transition to a ''yes'' state or a ''no'' state. This facilitates the creation of a finite state acceptor for a regular language that you program in a more assembly-language-like manner. Please don''t be put-off by my silly name choices. ''czek'' == ''check''. ''grok'' == [go look it up in the Hacker Dictionary].
So for each iteration, czek calls a predicate function with the current character as argument. If the predicate returns true, the character is consumed (the pointer advanced) and we follow the ''y'' transition to select the next state. If the predicate returns false, the character is NOT consumed and we follow the ''n'' transition. So every instruction is a two-way branch! I must have been reading The Story of Mel at the time.
This code comes straight from my postscript interpreter , and evolved into its current form with much guidance from the fellows on comp.lang.c. Since postscript basically has no syntax (only requiring balanced brackets), a Regular Language Accepter like this functions as the parser as well.
/* currentstr is set to the start of string by czek
and used by setrad (called by israd) to set currentrad
which is used by israddig to determine if the character
in question is valid for the specified radix
--
a little semantic checking in the syntax!
*/
char *currentstr;
int currentrad;
void setrad(void) {
char *end;
currentrad = strtol(currentstr, &end, 10);
if (*end != ''#'' /* just a sanity check,
the automaton should already have determined this */
|| currentrad > 36
|| currentrad < 2)
fatal("bad radix"); /* should probably be a simple syntaxerror */
}
/*
character classes
used as tests by automatons under control of czek
*/
char *alpha = "0123456789" "ABCDE" "FGHIJ" "KLMNO" "PQRST" "UVWXYZ";
#define EQ(a,b) a==b
#define WITHIN(a,b) strchr(a,b)!=NULL
int israd (int c) {
if (EQ(''#'',c)) { setrad(); return true; }
return false;
}
int israddig(int c) {
return strchrnul(alpha,toupper(c))-alpha <= currentrad;
}
int isdot (int c) {return EQ(''.'',c);}
int ise (int c) {return WITHIN("eE",c);}
int issign (int c) {return WITHIN("+-",c);}
int isdel (int c) {return WITHIN("()<>[]{}/%",c);}
int isreg (int c) {return c!=EOF && !isspace(c) && !isdel(c);}
#undef WITHIN
#undef EQ
/*
the automaton type
*/
typedef struct { int (*pred)(int); int y, n; } test;
/*
automaton to match a simple decimal number
*/
/* /^[+-]?[0-9]+$/ */
test fsm_dec[] = {
/* 0*/ { issign, 1, 1 },
/* 1*/ { isdigit, 2, -1 },
/* 2*/ { isdigit, 2, -1 },
};
int acc_dec(int i) { return i==2; }
/*
automaton to match a radix number
*/
/* /^[0-9]+[#][a-Z0-9]+$/ */
test fsm_rad[] = {
/* 0*/ { isdigit, 1, -1 },
/* 1*/ { isdigit, 1, 2 },
/* 2*/ { israd, 3, -1 },
/* 3*/ { israddig, 4, -1 },
/* 4*/ { israddig, 4, -1 },
};
int acc_rad(int i) { return i==4; }
/*
automaton to match a real number
*/
/* /^[+-]?(d+(.d*)?)|(d*.d+)([eE][+-]?d+)?$/ */
/* represents the merge of these (simpler) expressions
[+-]?[0-9]+/.[0-9]*([eE][+-]?[0-9]+)?
[+-]?[0-9]*/.[0-9]+([eE][+-]?[0-9]+)?
The complexity comes from ensuring at least one
digit in the integer or the fraction with optional
sign and optional optionally-signed exponent.
So passing isdot in state 3 means at least one integer digit has been found
but passing isdot in state 4 means we must find at least one fraction digit
via state 5 or the whole thing is a bust.
*/
test fsm_real[] = {
/* 0*/ { issign, 1, 1 },
/* 1*/ { isdigit, 2, 4 },
/* 2*/ { isdigit, 2, 3 },
/* 3*/ { isdot, 6, 7 },
/* 4*/ { isdot, 5, -1 },
/* 5*/ { isdigit, 6, -1 },
/* 6*/ { isdigit, 6, 7 },
/* 7*/ { ise, 8, -1 },
/* 8*/ { issign, 9, 9 },
/* 9*/ { isdigit, 10, -1 },
/*10*/ { isdigit, 10, -1 },
};
int acc_real(int i) {
switch(i) {
case 2: /* integer */
case 6: /* real */
case 10: /* real with exponent */
return true;
}
return false;
}
/*
Helper function for grok.
Execute automaton against the buffer,
applying test to each character:
on success, consume character and follow ''y'' transition.
on failure, do not consume but follow ''n'' transition.
Call yes function to determine if the ending state
is considered an acceptable final state.
A transition to -1 represents rejection by the automaton
*/
int czek (char *s, test *fsm, int (*yes)(int)) {
int sta = 0;
currentstr = s;
while (sta!=-1 && *s) {
if (fsm[sta].pred((int)*s)) {
sta=fsm[sta].y;
s++;
} else {
sta=fsm[sta].n;
}
}
return yes(sta);
}
/*
Helper function for toke.
Interpret the contents of the buffer,
trying automatons to match number formats;
and falling through to a switch for special characters.
Any token consisting of all regular characters
that cannot be interpreted as a number is an executable name
*/
object grok (state *st, char *s, int ns,
object *src,
int (*next)(state *,object *),
void (*back)(state *,int, object *)) {
if (czek(s, fsm_dec, acc_dec)) {
long num;
num = strtol(s,NULL,10);
if ((num==LONG_MAX || num==LONG_MIN) && errno==ERANGE) {
error(st,limitcheck);
/* } else if (num > INT_MAX || num < INT_MIN) { */
/* error(limitcheck, OP_token); */
} else {
return consint(num);
}
}
else if (czek(s, fsm_rad, acc_rad)) {
long ra,num;
ra = (int)strtol(s,NULL,10);
if (ra > 36 || ra < 2) {
error(st,limitcheck);
}
num = strtol(strchr(s,''#'')+1, NULL, (int)ra);
if ((num==LONG_MAX || num==LONG_MIN) && errno==ERANGE) {
error(st,limitcheck);
/* } else if (num > INT_MAX || num < INT_MAX) { */
/* error(limitcheck, OP_token); */
} else {
return consint(num);
}
}
else if (czek(s, fsm_real, acc_real)) {
double num;
num = strtod(s,NULL);
if ((num==HUGE_VAL || num==-HUGE_VAL) && errno==ERANGE) {
error(st,limitcheck);
} else {
return consreal(num);
}
}
else switch(*s) {
case ''('': {
int c, defer=1;
char *sp = s;
while (defer && (c=next(st,src)) != EOF ) {
switch(c) {
case ''('': defer++; break;
case '')'': defer--;
if (!defer) goto endstring;
break;
case ''//': c=next(st,src);
switch(c) {
case ''/n'': continue;
case ''a'': c = ''/a''; break;
case ''b'': c = ''/b''; break;
case ''f'': c = ''/f''; break;
case ''n'': c = ''/n''; break;
case ''r'': c = ''/r''; break;
case ''t'': c = ''/t''; break;
case ''v'': c = ''/v''; break;
case ''/''': case ''/"'':
case ''('': case '')'':
default: break;
}
}
if (sp-s>ns) error(st,limitcheck);
else *sp++ = c;
}
endstring: *sp=0;
return cvlit(consstring(st,s,sp-s));
}
case ''<'': {
int c;
char d, *x = "0123456789abcdef", *sp = s;
while (c=next(st,src), c!=''>'' && c!=EOF) {
if (isspace(c)) continue;
if (isxdigit(c)) c = strchr(x,tolower(c)) - x;
else error(st,syntaxerror);
d = (char)c << 4;
while (isspace(c=next(st,src))) /*loop*/;
if (isxdigit(c)) c = strchr(x,tolower(c)) - x;
else error(st,syntaxerror);
d |= (char)c;
if (sp-s>ns) error(st,limitcheck);
*sp++ = d;
}
*sp = 0;
return cvlit(consstring(st,s,sp-s));
}
case ''{'': {
object *a;
size_t na = 100;
size_t i;
object proc;
object fin;
fin = consname(st,"}");
(a = malloc(na * sizeof(object))) || (fatal("failure to malloc"),0);
for (i=0 ; objcmp(st,a[i]=toke(st,src,next,back),fin) != 0; i++) {
if (i == na-1)
(a = realloc(a, (na+=100) * sizeof(object))) || (fatal("failure to malloc"),0);
}
proc = consarray(st,i);
{ size_t j;
for (j=0; j<i; j++) {
a_put(st, proc, j, a[j]);
}
}
free(a);
return proc;
}
case ''/'': {
s[1] = (char)next(st,src);
puff(st, s+2, ns-2, src, next, back);
if (s[1] == ''/'') {
push(consname(st,s+2));
opexec(st, op_cuts.load);
return pop();
}
return cvlit(consname(st,s+1));
}
default: return consname(st,s);
}
return null; /* should be unreachable */
}
/*
Helper function for toke.
Read into buffer any regular characters.
If we read one too many characters, put it back
unless it''s whitespace.
*/
int puff (state *st, char *buf, int nbuf,
object *src,
int (*next)(state *,object *),
void (*back)(state *,int, object *)) {
int c;
char *s = buf;
while (isreg(c=next(st,src))) {
if (s-buf >= nbuf-1) return false;
*s++ = c;
}
*s = 0;
if (!isspace(c) && c != EOF) back(st,c,src); /* eat interstice */
return true;
}
/*
Helper function for Stoken Ftoken.
Read a token from src using next and back.
Loop until having read a bona-fide non-whitespace non-comment character.
Call puff to read into buffer up to next delimiter or space.
Call grok to figure out what it is.
*/
#define NBUF MAXLINE
object toke (state *st, object *src,
int (*next)(state *, object *),
void (*back)(state *, int, object *)) {
char buf[NBUF] = "", *s=buf;
int c,sta = 1;
object o;
do {
c=next(st,src);
//if (c==EOF) return null;
if (c==''%'') {
if (DUMPCOMMENTS) fputc(c, stdout);
do {
c=next(st,src);
if (DUMPCOMMENTS) fputc(c, stdout);
} while (c!=''/n'' && c!=''/f'' && c!=EOF);
}
} while (c!=EOF && isspace(c));
if (c==EOF) return null;
*s++ = c;
*s = 0;
if (!isdel(c)) sta=puff(st, s,NBUF-1,src,next,back);
if (sta) {
o=grok(st,buf,NBUF-1,src,next,back);
return o;
} else {
return null;
}
}
Another interesting open source tool is Yakindu Statechart Tools on statecharts.org . It makes use of Harel statecharts and thus provides hierarchical and parallel states and generates C and C++ (as well as Java) code. It does not make use of libraries but follows a ''plain code'' approach. The code basically applies switch-case structures. The code generators can also be customized. Additionally the tool provides many other features.
Coming to this late (as usual) but scanning the answers to date I thinks something important is missing;
I have found in my own projects that it can be very helpful to not have a function for every valid state/event combination. I do like the idea of effectively having a 2D table of states/events. But I like the table elements to be more than a simple function pointer. Instead I try to organize my design so at it''s heart it comprises a bunch of simple atomic elements or actions. That way I can list those simple atomic elements at each intersection of my state/event table. The idea is that you don''t have to define a mass of N squared (typically very simple) functions. Why have something so error-prone, time consuming, hard to write, hard to read, you name it ?
I also include an optional new state, and an optional function pointer for each cell in the table. The function pointer is there for those exceptional cases where you don''t want to just fire off a list of atomic actions.
You know you are doing it right when you can express a lot of different functionality, just by editing your table, with no new code to write.
Given that you imply you can use C++ and hence OO code, I would suggest evaluating the ''GoF''state pattern (GoF = Gang of Four, the guys who wrote the design patterns book which brought design patterns into the limelight).
It is not particularly complex and it is widely used and discussed so it is easy to see examples and explanations on line.
It will also quite likely be recognizable by anyone else maintaining your code at a later date.
If efficiency is the worry, it would be worth actually benchmarking to make sure that a non OO approach is more efficient as lots of factors affect performance and it is not always simply OO bad, functional code good. Similarly, if memory usage is a constraint for you it is again worth doing some tests or calculations to see if this will actually be an issue for your particular application if you use the state pattern.
The following are some links to the ''Gof'' state pattern, as Craig suggests:
I have used http://smc.sourceforge.net/ in Java and Python projects to with success.
I personally use self referencing structs in combination with pointer arrays. I uploaded a tutorial on github a while back, link:
https://github.com/mmelchger/polling_state_machine_c
Note: I do realise that this thread is quite old, but I hope to get input and thoughts on the design of the state-machine as well as being able to provide an example for a possible state-machine design in C.
I really liked paxdiable''s answer and decided to implement all the missing features for my application like guard variables and state machine specific data.
I uploaded my implementation to this site to share with the community. It has been tested using IAR Embedded Workbench for ARM.
Las máquinas de estado que he diseñado antes (C, no C ++) se han reducido a una matriz de struct y un ciclo. La estructura básicamente consiste en un estado y evento (para búsqueda) y una función que devuelve el nuevo estado, algo así como:
typedef struct {
int st;
int ev;
int (*fn)(void);
} tTransition;
Luego define sus estados y eventos con definiciones simples ( ANY son marcadores especiales, ver a continuación):
#define ST_ANY -1
#define ST_INIT 0
#define ST_ERROR 1
#define ST_TERM 2
: :
#define EV_ANY -1
#define EV_KEYPRESS 5000
#define EV_MOUSEMOVE 5001
Luego, define todas las funciones llamadas por las transiciones:
static int GotKey (void) { ... };
static int FsmError (void) { ... };
Todas estas funciones están escritas para no tomar variables y devolver el nuevo estado para la máquina de estado. En este ejemplo, las variables globales se usan para pasar cualquier información a las funciones de estado cuando sea necesario.
El uso de globales no es tan malo como suena, ya que el FSM generalmente está bloqueado dentro de una única unidad de compilación y todas las variables son estáticas para esa unidad (por eso utilicé comillas alrededor de "global" arriba; están más compartidas dentro del FSM, que verdaderamente global). Como con todos los globales, requiere cuidado.
La matriz de transiciones luego define todas las transiciones posibles y las funciones que reciben llamadas para esas transiciones (incluida la última combinación):
tTransition trans[] = {
{ ST_INIT, EV_KEYPRESS, &GotKey},
: :
{ ST_ANY, EV_ANY, &FsmError}
};
#define TRANS_COUNT (sizeof(trans)/sizeof(*trans))
Lo que eso significa es: si se encuentra en el estado ST_INIT y recibe el evento EV_KEYPRESS , realice una llamada a GotKey .
El funcionamiento del FSM se convierte en un ciclo relativamente simple:
state = ST_INIT;
while (state != ST_TERM) {
event = GetNextEvent();
for (i = 0; i < TRANS_COUNT; i++) {
if ((state == trans[i].st) || (ST_ANY == trans[i].st)) {
if ((event == trans[i].ev) || (EV_ANY == trans[i].ev)) {
state = (trans[i].fn)();
break;
}
}
}
}
Como se ST_ANY anteriormente, observe el uso de ST_ANY como comodines, permitiendo que un evento llame a una función sin importar el estado actual. EV_ANY también funciona de manera similar, permitiendo que cualquier evento en un estado específico llame a una función.
También puede garantizar que, si llega al final de la matriz de transiciones, ST_ANY/EV_ANY un error que indica que su FSM no se ha creado correctamente (utilizando la combinación ST_ANY/EV_ANY .
Utilicé un código similar para esto en una gran cantidad de proyectos de comunicaciones, como una implementación temprana de pilas de comunicaciones y protocolos para sistemas integrados. La gran ventaja fue su simplicidad y relativa facilidad para cambiar la matriz de transiciones.
No tengo dudas de que habrá abstracciones de mayor nivel que pueden ser más adecuadas hoy en día, pero sospecho que todas se reducirán a este mismo tipo de estructura.
Y, como dice ldog en un comentario, puede evitar los globales al pasar un puntero de estructura a todas las funciones (y usar eso en el ciclo de evento). Esto permitirá que varias máquinas de estado funcionen una al lado de la otra sin interferencias.
Simplemente cree un tipo de estructura que contenga los datos específicos de la máquina (estado al mínimo) y utilícelos en lugar de los globales.
La razón por la que raramente lo he hecho es simplemente porque la mayoría de las máquinas de estado que he escrito han sido de tipo singleton (inicio único, inicio del proceso, lectura del archivo de configuración, por ejemplo), sin necesidad de ejecutar más de una instancia . Pero tiene valor si necesita ejecutar más de uno.
Saw this somewhere
#define FSM
#define STATE(x) s_##x :
#define NEXTSTATE(x) goto s_##x
FSM {
STATE(x) {
...
NEXTSTATE(y);
}
STATE(y) {
...
if (x == 0)
NEXTSTATE(y);
else
NEXTSTATE(x);
}
}
This series of Ars OpenForum posts about a somewhat complicated bit of control logic includes a very easy-to-follow implementation as a state machine in C.
This is an old post with lots of answers, but I thought I''d add my own approach to the finite state machine in C. I made a Python script to produce the skeleton C code for any number of states. That script is documented on GituHub at FsmTemplateC
This example is based on other approaches I''ve read about. It doesn''t use goto or switch statements but instead has transition functions in a pointer matrix (look-up table). The code relies on a big multi-line initializer macro and C99 features (designated initializers and compound literals) so if you don''t like these things, you might not like this approach.
Here is a Python script of a turnstile example which generates skeleton C-code using FsmTemplateC :
# dict parameter for generating FSM
fsm_param = {
# main FSM struct type string
''type'': ''FsmTurnstile'',
# struct type and name for passing data to state machine functions
# by pointer (these custom names are optional)
''fopts'': {
''type'': ''FsmTurnstileFopts'',
''name'': ''fopts''
},
# list of states
''states'': [''locked'', ''unlocked''],
# list of inputs (can be any length > 0)
''inputs'': [''coin'', ''push''],
# map inputs to commands (next desired state) using a transition table
# index of array corresponds to ''inputs'' array
# for this example, index 0 is ''coin'', index 1 is ''push''
''transitiontable'': {
# current state | ''coin'' | ''push'' |
''locked'': [''unlocked'', ''''],
''unlocked'': [ '''', ''locked'']
}
}
# folder to contain generated code
folder = ''turnstile_example''
# function prefix
prefix = ''fsm_turnstile''
# generate FSM code
code = fsm.Fsm(fsm_param).genccode(folder, prefix)
The generated output header contains the typedefs:
/* function options (EDIT) */
typedef struct FsmTurnstileFopts {
/* define your options struct here */
} FsmTurnstileFopts;
/* transition check */
typedef enum eFsmTurnstileCheck {
EFSM_TURNSTILE_TR_RETREAT,
EFSM_TURNSTILE_TR_ADVANCE,
EFSM_TURNSTILE_TR_CONTINUE,
EFSM_TURNSTILE_TR_BADINPUT
} eFsmTurnstileCheck;
/* states (enum) */
typedef enum eFsmTurnstileState {
EFSM_TURNSTILE_ST_LOCKED,
EFSM_TURNSTILE_ST_UNLOCKED,
EFSM_TURNSTILE_NUM_STATES
} eFsmTurnstileState;
/* inputs (enum) */
typedef enum eFsmTurnstileInput {
EFSM_TURNSTILE_IN_COIN,
EFSM_TURNSTILE_IN_PUSH,
EFSM_TURNSTILE_NUM_INPUTS,
EFSM_TURNSTILE_NOINPUT
} eFsmTurnstileInput;
/* finite state machine struct */
typedef struct FsmTurnstile {
eFsmTurnstileInput input;
eFsmTurnstileCheck check;
eFsmTurnstileState cur;
eFsmTurnstileState cmd;
eFsmTurnstileState **transition_table;
void (***state_transitions)(struct FsmTurnstile *, FsmTurnstileFopts *);
void (*run)(struct FsmTurnstile *, FsmTurnstileFopts *, const eFsmTurnstileInput);
} FsmTurnstile;
/* transition functions */
typedef void (*pFsmTurnstileStateTransitions)(struct FsmTurnstile *, FsmTurnstileFopts *);
- enum
eFsmTurnstileCheckis used to determine whether a transition was blocked withEFSM_TURNSTILE_TR_RETREAT, allowed to progress withEFSM_TURNSTILE_TR_ADVANCE, or the function call was not preceded by a transition withEFSM_TURNSTILE_TR_CONTINUE. - enum
eFsmTurnstileStateis simply the list of states. - enum
eFsmTurnstileInputis simply the list of inputs. - The
FsmTurnstilestruct is the heart of the state machine with the transition check, function lookup table, current state, commanded state, and an alias to the primary function that runs the machine. - Every function pointer (alias) in
FsmTurnstileshould only be called from the struct and has to have its first input as a pointer to itself so as to maintain a persistent state, object-oriented style.
Now for the function declarations in the header:
/* fsm declarations */
void fsm_turnstile_locked_locked (FsmTurnstile *fsm, FsmTurnstileFopts *fopts);
void fsm_turnstile_locked_unlocked (FsmTurnstile *fsm, FsmTurnstileFopts *fopts);
void fsm_turnstile_unlocked_locked (FsmTurnstile *fsm, FsmTurnstileFopts *fopts);
void fsm_turnstile_unlocked_unlocked (FsmTurnstile *fsm, FsmTurnstileFopts *fopts);
void fsm_turnstile_run (FsmTurnstile *fsm, FsmTurnstileFopts *fopts, const eFsmTurnstileInput input);
Function names are in the format {prefix}_{from}_{to} , where {from} is the previous (current) state and {to} is the next state. Note that if the transition table does not allow for certain transitions, a NULL pointer instead of a function pointer will be set. Finally, the magic happens with a macro. Here we build the transition table (matrix of state enums) and the state transition functions look up table (a matrix of function pointers):
/* creation macro */
#define FSM_TURNSTILE_CREATE() /
{ /
.input = EFSM_TURNSTILE_NOINPUT, /
.check = EFSM_TURNSTILE_TR_CONTINUE, /
.cur = EFSM_TURNSTILE_ST_LOCKED, /
.cmd = EFSM_TURNSTILE_ST_LOCKED, /
.transition_table = (eFsmTurnstileState * [EFSM_TURNSTILE_NUM_STATES]) { /
(eFsmTurnstileState [EFSM_TURNSTILE_NUM_INPUTS]) { /
EFSM_TURNSTILE_ST_UNLOCKED, /
EFSM_TURNSTILE_ST_LOCKED /
}, /
(eFsmTurnstileState [EFSM_TURNSTILE_NUM_INPUTS]) { /
EFSM_TURNSTILE_ST_UNLOCKED, /
EFSM_TURNSTILE_ST_LOCKED /
} /
}, /
.state_transitions = (pFsmTurnstileStateTransitions * [EFSM_TURNSTILE_NUM_STATES]) { /
(pFsmTurnstileStateTransitions [EFSM_TURNSTILE_NUM_STATES]) { /
fsm_turnstile_locked_locked, /
fsm_turnstile_locked_unlocked /
}, /
(pFsmTurnstileStateTransitions [EFSM_TURNSTILE_NUM_STATES]) { /
fsm_turnstile_unlocked_locked, /
fsm_turnstile_unlocked_unlocked /
} /
}, /
.run = fsm_turnstile_run /
}
When creating the FSM, the macro FSM_EXAMPLE_CREATE() has to be used.
Now, in the source code every state transition function declared above should be populated. The FsmTurnstileFopts struct can be used to pass data to/from the state machine. Every transition must set fsm->check to be equal to either EFSM_EXAMPLE_TR_RETREAT to block it from transitioning or EFSM_EXAMPLE_TR_ADVANCE to allow it to transition to the commanded state. A working example can be found at (FsmTemplateC)[ https://github.com/ChisholmKyle/FsmTemplateC] .
Here is the very simple actual usage in your code:
/* create fsm */
FsmTurnstile fsm = FSM_TURNSTILE_CREATE();
/* create fopts */
FsmTurnstileFopts fopts = {
.msg = ""
};
/* initialize input */
eFsmTurnstileInput input = EFSM_TURNSTILE_NOINPUT;
/* main loop */
for (;;) {
/* wait for timer signal, inputs, interrupts, whatever */
/* optionally set the input (my_input = EFSM_TURNSTILE_IN_PUSH for example) */
/* run state machine */
my_fsm.run(&my_fsm, &my_fopts, my_input);
}
All that header business and all those functions just to have a simple and fast interface is worth it in my mind.
You could use the open source library OpenFST .
OpenFst is a library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs). Weighted finite-state transducers are automata where each transition has an input label, an output label, and a weight. The more familiar finite-state acceptor is represented as a transducer with each transition''s input and output label equal. Finite-state acceptors are used to represent sets of strings (specifically, regular or rational sets); finite-state transducers are used to represent binary relations between pairs of strings (specifically, rational transductions). The weights can be used to represent the cost of taking a particular transition.
Your question is quite generic,
Here are two reference articles that might be useful,
Embedded State Machine Implementation
This article describes a simple approach to implementing a state machine for an embedded system. For purposes of this article, a state machine is defined as an algorithm that can be in one of a small number of states. A state is a condition that causes a prescribed relationship of inputs to outputs, and of inputs to next states.
A savvy reader will quickly note that the state machines described in this article are Mealy machines. A Mealy machine is a state machine where the outputs are a function of both present state and input, as opposed to a Moore machine, in which the outputs are a function only of state.- Coding State Machines in C and C++
My preoccupation in this article is with state-machine fundamentals and some straightforward programming guidelines for coding state machines in C or C++. I hope that these simple techniques can become more common, so that you (and others) can readily see the state-machine structure right from the source code.
- Coding State Machines in C and C++
boost.org comes with 2 different state chart implementations:
As always, boost will beam you into template hell.
The first library is for more performance-critical state machines. The second library gives you a direct transition path from a UML Statechart to code.
Here''s the SO question asking for a comparison between the two where both of the authors respond.
void (* StateController)(void);
void state1(void);
void state2(void);
void main()
{
StateController=&state1;
while(1)
{
(* StateController)();
}
}
void state1(void)
{
//do something in state1
StateController=&state2;
}
void state2(void)
{
//do something in state2
//Keep changing function direction based on state transition
StateController=&state1;
}