larshei / lovelyfsm Goto Github PK

For now, all unit tests use just a single instance.

Make sure that on creating mutliple instances, the instances are

• different
• have their own lookup tables
• are indepent
• can be deinitialized and reinitialized

Some functions are prefixed with lfsm_, others with fsm_.

Provide an readme to let people know

• what this does
• what the strengths are
• what the weaknesses are
• how well/bad its tested
• how its used

One of the strenghts of this state machine is, in theory, that you could

• define one set of states/transitions tables
• create mutliple instances based on the same tables
• that way, you can easily create systems that use the same function multiple times, e.g. handling multiple incoming connections or multiple interfaces of the same type.

On creating a second instance, a user may pass the same transition and function table as previously passed to the first instance.
However, for the second instance the lookup tables will be newly created. Therefore a second lookup table set will be generated that should be identical to the already existing lookup tables from the first instance.

Add an init function that inherits most of the data from an already existing state machine instance.
(basically everything but the user data?)
Make sure to count how many contexts a table is currently being used in.
Free lookup tables once not needed anymore.

Events and states are treated as uint8_t throughout the program logic.

But in

typedef struct lfsm_transitions_t {
    int current_state;
    int event;
    int (*condition)( lfsm_t );
    int next_state;
} lfsm_transitions_t;

typedef struct lfsm_state_functions_t {
    int state;
    lfsm_return_t (*on_entry) ( lfsm_t );
    lfsm_return_t (*on_run  ) ( lfsm_t );
    lfsm_return_t (*on_exit ) ( lfsm_t );
} lfsm_state_functions_t;

they are treated as int.