I would love to have the state event matrix not only returning a ‘next state’ and action to do BUT directly calling ‘actions’ functions. A long time ago , when I was at school, I wrote such ptr function call but can’t reproduce it now.
Basically , in your routine below, I would love to replace the ‘return’ by a call to a function which you would have its pointer in the matrix.
Any idea ?

The simple answer to Jean-Marc’s questions is “Yes” and I’m really sorry that I hadn’t got the time to answer sooner. The basic idea of using function pointers is the right choice to find a solution for this task.

So what are functions pointers basically?

First of all a pointer is a data type whose value is “pointing” to a specific address in memory. “Dereferencing” a pointer returns the value stored at that specific address. Defining a pointer is done with an asterisk before the identifier of the variable. A pointer is assigned via the “adress of”-operator & and dereferencing a pointer is done with an asterisk before the identifiers name again.

    int *a;
    int b=5;

     a = &b; // a is given the adress of b, a = 5
     b = *a + 10; // b = 15
     &b = a; // b is given the adress of a, b = 5

Function pointers point to the adress of a c-function. Dereferencing a function pointer means to envoke the apropriate function. The syntax for letting a variable point to a function differs from the above example. Pointing to a function is done via

void main() {

     void (*fp)();

    fp functionPointer = function_a;

    (*fp)();  //prints "a"

    fp functionPointer = function_b;

    (*fp)();  //prints "b"

}

void function_a(void) {
      fprintf("a \n");
}

void function_b(void) {
     fprintf("b\n");
}

What to do with function pointers?

So these are function pointers, but why do whe need them?

// from: http://www.newty.de/ftp/intro.html#why

float Plus    (float a, float b) { return a+b; }
float Minus   (float a, float b) { return a-b; }
float Multiply(float a, float b) { return a*b; }
float Divide  (float a, float b) { return a/b; }

// Solution with a switch-statement -  specifies which operation to execute
void Switch(float a, float b, char opCode)
{
   float result;

   // execute operation
   switch(opCode)
   {
      case '+' : result = Plus     (a, b); break;
      case '-' : result = Minus    (a, b); break;
      case '*' : result = Multiply (a, b); break;
      case '/' : result = Divide   (a, b); break;
   }

   cout << \"Switch: 2+5=\" << result << endl;         // display result
}

// Solution with a function pointer
// a function which takes two floats and returns a float. The function pointer
// "specifies" which operation shall be executed.
void Switch_With_Function_Pointer(float a, float b, float (*pt2Func)(float, float))
{
   float result = pt2Func(a, b);    // call using function pointer
}

// Execute example code
void Replace_A_Switch()
{
   Switch(2, 5, /* '+' specifies function 'Plus' to be executed */ '+');
   Switch_With_Function_Pointer(2, 5, /* pointer to function 'Minus' */ &Minus);
}

Changing the Type Definitions from the Matrix-Style-Implementation

You should have a look at my old post on how to implement a Matrix-Style-Implementation of Finite State Machines in C, to understand how the general mechanisms on this implementation work. I won’t recapitulate theme here.

First off all, you’ll have to define the generic typedefs for the state-event matrix as mentioned in the older implementation:

/*****************************************************************
 * typedefs
 *****************************************************************/

typedef enum {
  STATE1,
  STATE2,
  STATE3
} state;

typedef enum {
  NILEVENT,
  EVENT1,
  EVENT2
} event;

These are exactly the same data types as the approach without function pointers. We’ll now define a typedef for a function pointer to an action that shall be released in each state, the action-functions and the generic state-machine function:

typedef void (*action)();

// General functions
void stateEval(event e);
void exit(int status);
void getIOValues(void);

//Actions
void action1_1(void);
void action1_2(void);
void action1_3(void);
void action2_1(void);
void action2_2(void);
void action2_3(void);
void action3_1(void);
void action3_2(void);
void action3_3(void);

The action function-pointer and state enumerators are combined in a structure typedef used for the function-pointer based state-event matrix:

typedef struct {
	state nextState;       // Enumerator for the next state
	action actionToDo;     // function-pointer to the action that shall be released in current state
}  stateElement;               // structure for the elements in the state-event matrix

And finally the state-event matrix will be build-up:

stateElement stateMatrix[3][3] = {
   { {STATE1, action1_1}, {STATE2, action1_2}, {STATE3, action1_3} },
   { {STATE2, action2_1}, {STATE2, action2_2}, {STATE3, action2_3} },
   { {STATE3, action3_1}, {STATE3, action3_2}, {STATE3, action3_3} }
};

And this will be the state-machine invocation with function-pointers involved

All these snippets go into the Header-File.

#include
#include "main.h"

state  currentState = STATE1;

int main()
{
	//Initializations
	event  eventOccured = NILEVENT;
	action actionToDo   = action1_1;

	while(1) {
		// event input, NIL-event for non-changing input-alphabet of FSM
		// in real implementation this should be triggered by event registers e.g.
		// evaluation of complex binary expressions could be implemented to release the events

                int e = 0;             

               printf("----------------\n");
               printf("Event to occure: ");
               scanf("%u",&e);
               stateEval( (event) e); // typecast to event enumeration type
               printf("-----------------\n");

	};
	return (0);
}

/********************************************************************************
 * stateEval (event)
 * in Dependancy of an triggered event, the action wich is required by this
 * transition will be returned. The proper action is determined by the current state the
 * automat holds. The current state will then be transitioned to the requestet next
 * state
 ********************************************************************************/

void stateEval(event e)
{
	//determine the State-Matrix-Element in dependany of current state and triggered event
        stateElement stateEvaluation = stateMatrix[currentState][e];

	//do the transition to the next state (set requestet next state to current state)...
	currentState = stateEvaluation.nextState;
	//... and fire the proper action
	(*stateEvaluation.actionToDo)();
}

/**********************************************************************
 * action functions
 **********************************************************************/

void action1_1() {
  printf("action1.1 \n");
}

void action1_2() {
  printf("action1.2 \n");
}

void action1_3() {
  printf("action1.3 \n");
}

void action2_1() {
  printf("action2.1 \n");
}

void action2_2() {
  printf("action2.2 \n");
}

void action2_3() {
  printf("action2.3 \n");
}

void action3_1() {
  printf("action3.1 \n");
}

void action3_2() {
  printf("action3.2 \n");
}

void action3_3() {
  printf("action3.3 \n");
}

Related Posts

• September 8, 2008 -- Finite State Machine Matrix-Style C Implementation
• September 8, 2009 -- Updated Wordpress, Result: New Design and Layout, Loss of Recordings
• October 25, 2008 -- New Design
• July 15, 2008 -- Hello world!
• February 13, 2010 -- Back again
• May 24, 2009 -- Fedora 11 Leonidas, How to Upgrade

Wir haben ein wirklich nettes Vietnam-Reisebegleiter-Buch. Allerdings: Was machen Experten, wie wir? Richtig, wir führen in Hanoi den „Coin-survival-trip“ ein. Dies ist mindestens genau so spannend, wie einfach zu erklären.

Ziel des Spiels ist es, die nächste zusagende Bierbar zu finden. Mithilfe eines Münzwurfes wird an Kreuzungen entschieden, ob nach links oder rechts abgebogen wird. Gibt es die Möglichkeit weiter geradeaus zu wandern entscheidet das Bequemlichkeit-Zufallsprinzip. Tritt dies in Kraft wird keine Münze geworfen, sondern weiter marschiert.

Translation to english:

We’ve got a lovely vietnam guide book, but what would experts, like us, use instead? Yes, we’re going to establish the “coin-survival-trip” in Hanoi. This is certainly as much fun as easy to explain.

Aim of the game is to find the nearest suitable bar. Entering a crossing, a coin toss decides wether you’ll have to turn left or right. If there’s the possibility to walk straight ahead, a random accomodativeness-principle is used. If this principle comes into effect, no coin tossing is used.

If you’re ever on a journey yourself, spread this idea and do a coin-survival-trip; it’s such a lovely idea, it has to go ’round the world!

Related Posts

• March 18, 2009 -- Did you know…
• September 7, 2008 -- LAN-Partys heute und früher
• August 1, 2008 -- Interesting Statistics or Why Art Thou There

I’d like to present an Implementation of a FSM, i’ve found during my student research project that is a mealy machine and does not require a reprogramming of the underlying structure.

I realized this implementation in an event-driven structure in LabVIEW (g) (file a comment if you’re interested in that implementation). However i recently needed a state machine implementation in C, and tested some implementations and remebered my old implementation of that matrix-style implementation.

State Transition Table

The basic idea of this implementation is that every state machine can be directly represented as a state transition table. I’ll be using a two-dimensional transition table (matrix), depending of current active state and possible events (see Table 1).

e.g. the current state would be ‘State 2′ and the second event has been triggered, the machine will initiate ‘Action 1′ and stay in ‘State 2′.

This compact representation can easily be derived from any state diagramm. Suchlike tabular structures can be transferred into programming languages without difficulty. This is the main benefit of this representation.

C Code

States, events and actions are represented by enumerator typedefinitions. All the rest will be build upon them.

/*******************************
 * typedefs
 *******************************/

typedef enum {
       STATE_0,
       STATE_1,
       STATE_2
} state;

typedef enum {
      NILACTION,
      ACTION_1,
      ACTION_2,
      ACTION_3,
      ACTION_4
} action;

typedef enum {
      NILEVENT,
      EVENT_1,
      EVENT_2
} event;

typedef struct {
      state nextState;
      action actionToDo;
}  stateElement;

Based on these type definitions the state transition table can be developed as a 2D-Array of stateElement structs.

stateElement stateMatrix[3][3] = {
       { {STATE_0,NILACTION}, {STATE_1,ACTION_1}, {STATE_1,ACTION_4} },
       { {STATE_1,NILACTION}, {STATE_2,ACTION_3}, {STATE_2,ACTION_2} },
       { {STATE_2,NILACTION}, {STATE_0,ACTION_2}, {STATE_1,ACTION_3} }
}

these definitions and constants can be stored in the header file. Getting the machine running is realized via a basic function.

/***************************************
 * prototypes
 ***************************************/
action stateEval(event e);

This function determines what action will be occasioned depending on the triggered event and sets the new state of the machine. The mechanism behind this function is lightweight.

action stateEval(event e)
{
	//determine the State-Matrix-Element in dependany of current state and triggered event
       stateElement stateEvaluation = stateMatrix[currentState][e];

	//do the transition to the next state (set requestet next state to current state)...
	currentState = stateEvaluation.nextState;
	//... and fire the proper action
	return stateEvaluation.actionToDo;
}

All that is done is indexing the stateMatrix-Array depending on current state (row) and occured event (column). All things additional needed will be a global constant currentState to store the machines state. This could be done in the main()-loop. Control of the state machine can be achieved via simple mechanism over the stateEval()-function.

        // this single line is the whole FSM-Call, easy as that!
        actionToDo = stateEval(eventOccured);

This could be put in an event-triggered interrupt-routine, a while-loop, a for-loop over each triggered event, or whatever is reasonable. The eventOccured has to be computed by a special algorithm, for example an combination of more or less complex expressions. In the easiest imaginable way this would be an if-structure:

if ( T > T_MAX ) {
   eventOccured = overTemperatureEvent;
}

All these little parts combined lead to a quite simple approach for a state machine implementation in programming languages.

The most convincing part is the state transition table, wich is the only thing –beneath the states und events type definition– that has to be changed, to change the whole state machine behaviour. It has a direct connection to state machine theory and the common state diagram representation. Thus making this approach tremendously customizable and understandable.

Related Posts

• March 18, 2009 -- Finite State Machine Matrix-Style-C-Implementation (Function Pointers Addon)
• September 8, 2009 -- Updated Wordpress, Result: New Design and Layout, Loss of Recordings
• May 24, 2009 -- Fedora 11 Leonidas, How to Upgrade
• October 25, 2008 -- New Design
• July 15, 2008 -- Hello world!