| State Machine Running Environment
The design of real-time or embedded applications usually involves decomposing the application software into objects, some of which may implement finite state machines for process or system control. Examples of these control objects might be the call control classes within a telephone switching system, or the treatment control classes within a medical instrument. Finite state machines are reactive, event-driven control structures whose behavior is determined by a received event and the history of events that preceded it. Other non-reactive classes provide computational or data retrieval services not requiring maintenance of a machine state or a history of stimuli to complete their functions.
In the StateWizard environment, these active classes implement state machines and can process input events. The StateWizard State Machine Engine manages these classes and acts as an event dispatcher.
State machine objects can work in active state or inactive state. The State Machine Engine only dispatches events to active state machine objects only. Inactive state machine objects do not handle events.
The architecture of the StateWizard run-time environment is depicted in the following diagram, showing the application objects and threads running above the StateMachineEngine. The RTOS virtual layer provides a generic interface for the common RTOS services such as semaphores, mutexes, and thread control. The service provider layer is the interface layer to lower level modules and hardware interfaces. A simulation or destination environment layer provides the interface to the target environment or to a simulation of that target environment. Simulation is often employed during software development when the real target hardware is not yet available or when extensive debugging facilities are needed but are not available on the target.
Figure: StateWizard Runtime Architecture
State Machine Threads
Several active state machine objects may run under a single thread context. A thread context identifies an independent execution thread and contains a thread identifier, a group of objects, an internal event pool, and several event hook functions.
State Machine Application Framework
The StateWizard provides two application frameworks for state machine objects.
- Standard Embedded C
- Standard C++
For standard C++ application framework, a state machine object is constructed by a C++ class.
State Machine Object Activation
To activate a state machine object identifies itself to the State Machine Engine by calling the SmeActivateObj () function.
The following sample creates a Player state machine object named Player1. Player1 runs under a separate thread whose entry function is AppThreadProc. The thread context is g_AppThreadContext.
void* AppThreadProc(void *Param)
{
// The second parameter (NULL) is the state machine Player1's parent.
SmeActivateObj(&Player1,NULL);
SmeRun();
}
SME_OBJ_DEF(Player1,Player)
SME_THREAD_CONTEXT_T g_AppThreadContext;
XTHREADHANDLE ThreadHandle = 0;
// Install thread local storage data functions.
XTlsAlloc();
SmeSetTlsProc(XSetThreadContext, XGetThreadContext);
// Initialize the engine
SmeInitEngine(&g_AppThreadContext);
// Install external event handler functions. They act as a plug-in of the state machine engine.
SmeSetExtEventOprProc(XGetExtEvent, XDelExtEvent, XPostThreadExtIntEvent, XPostThreadExtPtrEvent, XInitMsgBuf, XFreeMsgBuf);
int ret = XCreateThread(AppThreadProc, NULL, &AppThreadHandle); // The second parameter is the parameter for the thread entry function.
The Player control panel may post external events to the event queue of the running thread. The engine will dispatch them to the active application Player1.
XPostThreadExtIntEvent(&g_AppThreadContext, EXT_EVENT_ID_POWER, 0, 0,NULL,0,SME_EVENT_CAT_OTHER);
State Machine Object Deactivation
To de-activate a state machine object is done by calling the SmeDeactivateObj() function. The following statement de-activates Player1 state machine object.
SmeDeactivateObj(&Player1);
Service Providers
Sate machine applications may operate with lower layer software modules or hardware interfaces, which are called service providers. A service is formally specified by a set of primitives (operations) available to service users (applications). These primitives tell the service to perform some action or report on an action taken by a peer component/entity. The service primitives are classified into four categories:
- Request
- Indication
- Response
- Confirm
[Computer Networks, Andrew S.Tanenbaum]. The request and confirm primitives can be implemented in form of service calls. The indication and response primitives can be implemented in form of external event posting.
Active state machine objects can communicate with service providers using one of the following mechanisms for exchanging information:
(a) Synchronous service calls. These synchronous service calls may block, retuning control to the application when when the operation completes. Since most real-time systems must respond to external events in a predetermined amount of time, synchronous service calls are not used.
(b) Asynchronous service calls. Aynchronous functions do not block, continuing execution and returning before the operation is completed.
(c) Pro-active event indications. These events are posted from a service component to a client component without any request. An example might be an event posted by a hardware interrupt service routine.
Platform-Independent Embedded System Development
There are many different Real Time Operation Systems (RTOS) in the embedded system market. Each different RTOS provices a different API to access a set of common system services. The StateWizard RTOS Virtual Layer provides a platform independent adapter layer allowing state machine portability between different operating systems. We can move the application from one RTOS to another without changing the application code. The external event receiver in the RTOS Virtual Layer acts as a plug-in to the state machine engine.
Simulators
Simulators should be considered when:
- Hardware is unavailable or expensive.
- Extensive debugging capabilities are needed.
Simulators are one of several important categories of testing tools. They emulate the environment in which the software will eventually perform and often incorporate useful debugging features. They also enable testers to more effectively control the test environment and may save critical development resources when scarce target hardware must be shared between engineers.
Simulation allows commencement of software testing before a hardware prototype is available. It also scales with the size and complexity of the system, helping to identify and solve problems early in the development cycle when correction is still inexpensive.
In a simulation environment, developers can simulate service providers running on desktop platforms, for example Windows or Linux. These simulated services have identical interfaces with the target service provider interfaces. When moving to the destination environment, it should take little effort to integrate state machine applications with the real environment after they have been tested in the simulation. Active applications can make service calls presented by the service providers and can receive external events triggered by service providers through RTOS functions.
Copyright 2007 IntelliWizard Inc. All Rights Reserved.
|
