kiishor / uml-state-machine-in-c Goto Github PK

On this code:

  // Call Exit function before leaving the Source state.
    EXECUTE_HANDLER(pSource_State->Exit, triggered_to_self, pState_Machine);
  // Call entry function before entering the target state.
    EXECUTE_HANDLER(pTarget_State->Entry, triggered_to_self, pState_Machine);

    // Now traverse down to the target node & call their entry functions.
    while(index)
    {
      index--;
      EXECUTE_HANDLER(pTarget_Path[index]->Entry, triggered_to_self, pState_Machine);
    }

Does it mean that Target Entry runs first than the path Entries? Is this expected or the other way: first path Entries and at last the target Entry?

This option is not useful and adds complexity to the demo code. we can fix #4 issue.

The current repository comes with code-blocks project files. The cmake will be useful to support multiple IDE and compilers.

I'm really glad to see yet another state machine implementation in C. The only issue is that this work is clearly based on the book "Practical UML Statecharts in C/C++" (either the first or second edition.) For example, the problem description, the terminology, the toaster-oven example, etc. It is all fine to use someone else's work, but if you do, please give credit to the original source.

This will simplify the application to see the remaining time when the process is in an active state.
fix the issue #4 and related to #6.

Please provide sample example for advanced hierarchical state machine. its little difficult to understand without demo usage code. example model like this

Could you please provide a hint on how to build for AVR or STM32? Cmakelists in demo folder have set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -pthread") string. Is it enough to add platform-dependent headers, throw away pthreads and add
if(dispatch_event(State_Machines, 1) == EVENT_UN_HANDLED){...} to firmware infinite loop?

Hi kiishor,

thanks for contributing this interesting library. I tried to understand your implementation and have a question:

Your wrote:

  // Call Exit function before leaving the Source state.
    EXECUTE_HANDLER(pSource_State->Exit, triggered_to_self, pState_Machine);
  // Call entry function before entering the target state.
    EXECUTE_HANDLER(pTarget_State->Entry, triggered_to_self, pState_Machine);

    // Now traverse down to the target node & call their entry functions.
    while(index)
    {
      index--;
      EXECUTE_HANDLER(pTarget_Path[index]->Entry, triggered_to_self, pState_Machine);
    }

Looks like the entry handler of final target is called before the entry handlers of path traversed before. Wouldn't it more logical to do it the other way around:

  // Call Exit function before leaving the Source state.
    EXECUTE_HANDLER(pSource_State->Exit, triggered_to_self, pState_Machine);

    // Now traverse down to the target node & call their entry functions.
    while(index)
    {
      index--;
      EXECUTE_HANDLER(pTarget_Path[index]->Entry, triggered_to_self, pState_Machine);
    }

  // Call entry function before entering the target state.
    EXECUTE_HANDLER(pTarget_State->Entry, triggered_to_self, pState_Machine);

regards

spachner

Hello!
Thanks for this nice project and well documented!
I didn't tried it yet, I'm learning how could I use it.
I am trying to implement the following hierarchical state machine, that I will try explain with ascii code:

A)L0S0->B)L0S1->C)L0S2->...
A)L1S0  B)L1S0  C)L1S0
A)L1S1  B)L1S1  C)L1S1
A)L1S2  B)L1S2  C)L1S2

So I have at L0 State0 that can switch to L0 S1 (or L0 State N-1), ..
but then on each L0 State, I can switch to a new L1 state for each
On L1 I will have L1 S0 ->S1->S2->S0.. and then can return to L0 from any point

From this library, there are Entry and Exit callbacks for each state.
But I would like to implement an Entry/Exit for each Level
So when it enter or exit a Level it will call a function to prepare things for that level

How can I implement an Entry/Exit for a Level?

Consider the pseudo code:

Task Dispatch:
{
    sem_wait(&Semaphore);   // Wait for event
    dispatch_event(State_Machines, 1)
}

Task Generate Events:
{
    Machine.Event = SOME_EVENT;
    sem_post(&Semaphore);
    Sleep(random());
}

Task Generate Other Events:
{
    Machine.Event = OTHER_EVENT;
    sem_post(&Semaphore);
    Sleep(random());
}

Should the set of event be protected from other tasks?

1. Since dispatch_event will clear internally Machine.Event,
2. Since more than one task can generate events,
3. Since there is no queue of events, once an event is created, no other can be created until the previous is cleared.

What is your opinion on this? Could this be improved?

This is a demo for UML state machine framework using simple state machine.

The unit test cases build are failing due to use of anonymous structure in hsm.h
The GCC for c++ throws an error: Declaration does not declare anything