Login | Register
My pages Projects Community openCollabNet

[ framework ] [ architecture ] [ screenshots ] [ contribution ] [ resources ] [ new Wheel ]

The Astade runtime framework

The framework in Astade is made to synchronize processing and to distribute messages inside one process. Actually the UML state machines need that framework. The design guidelines for the framework, or the use cases, if you like, are the following:

The design criteria for the first step:

  1. There can be multiple state machines running independent, even if there is no multithreading.
  2. If there is multithreading, there are groups of machines running in one thread and other groups running in other threads. Messages can be passed between these groups.
  3. A "message" is any object, which inherits from the Astade message base class.
  4. There is a mechanism to trigger messages from hardware events like interrupts and signals.
  5. There is a timer mechanism for timeouts in the different states. The timer unit is milliseconds.
  6. State charts can be inherited, even partially.
  7. For performance reasons, it is possible, to send messages, which are static declared somewhere. This saves time in allocating and freeing memory.
  8. For convenience it is also possible to send messages, which are allocated at the heap. The framework takes care, that they are properly freed again.
  9. There are save mechanisms to create and destroy objects, which contain state charts. Messages will not arrive at destroyed objects (which would crash the program, actually).
  10. The addressing mechanism, between the Objects, are pointers (for performance reasons). 

The framework is designed in a way, that the following things can be added later. They will not be implemented in the first step:

Keep in mind, for further extension:

  1. States can contain sub states. There can be concurrent states.
  2. The addressing with "logical" object names instead of pointers.
  3. Message passing between components or even nodes.

Coding example:

To understand, what the automatic coder of Astade can do for you, here a (very) simple example. Imagine, you want to implement an automatic staircase light. If someone presses the button, light switches on. After a while (30 seconds), it switches off again automatically. If somebody presses again, while light is on, the timeout is extended.

Here is the state chart for that:

If a class would have such a state chart, Astade would code the following additional operations into that class:

bool AdeState_On(AdeEvent& theEvent)
{
    if (typeid(theEvent)==typeid(EvPressButton))
    {
        //do nothing
        SetState(AdeState_On);
        SetTimer(30000);
    }
    else
    if (typeid(theEvent)==typeid(EvAdeTimer))
    {
        DoLightOff(theEvent);
        SetState(AdeState_Off);
        SetTimer(0);
    }
    else
    {
        return false;
    }
    return true;
}

bool AdeState_Off(AdeEvent& theEvent)
{
    if (typeid(theEvent)==typeid(EvPressButton))
    {
        //do nothing
        SetState(AdeState_On);
        SetTimer(30000);
    }
    else
    {
        return false;
    }
    return true;
}

This actually is the implementation of the state chart! Astade has to code one operation for every state and one "if" statement for every transition, which leaves the state. Of course, the class should implement the operations "DoLightOn" and "DoLightOff" in some way. This still must be "hand coded" And it must inherit from the Astade state machine base class to get the message passing functionality.

The functions "SetTimer" and "SetState" are implemented in AdeStateMachine (the base class for all state machines). The return value is used to decide weather the Event has to be passed to concurrent states or sub states.

The Framework:

To get everything up and running, Astade has to do some message queuing and timer management. This is done in 5 Framework classes, which you can free add to your code:

  • AdeMachineEnvironment: manages everything. takes care, that the messages are handled correct and the state functions of the state machines are called with the messages. Normally you will need one of these classes in every thread. Inside one AdeMachineEnvironment can run any number of state machines at a time.
  • AdeOsAbstraction: contains all operating system dependent functionality of the framework. If you have to adapt the framework to whatever strange operating system, you have to adapt here (and only here!).
  • AdeEventQueue: a queuing container for AdeEvents. Implemented in a dynamic growing way, with a minimum of " malloc" and "free" operations.
  • AdeStateMachine: is a abstract class for all your individual state machines. Inside this class lives the (hand coded) event handlers and the auto coded "state" operations.
  • AdeEvent: is the abstract base class for all events. Whatever inherits from "AdeEvent" can be send through the event queue to another state machine.

[ Project overview ]