| 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
Interaction with 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:
1) Synchronous service calls. These synchronous service calls may block, retuning control to the application 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.
2) Asynchronous service calls. Asynchronous functions do not block, continuing execution and returning before the operation is completed.
3) 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 provides 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.
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);
Event Management Porting for Linux/Windows/QT
There are 2 kinds of events in the StateWizard
1) Internal Events:
which are triggered from state machine applications, for exchange among multiple state machines, or for the purpose of state transition in a state machine.
APIs: SmeCreateIntEvent(), SmeCreatePtrEvent(), SmePostEvent()
2) External Events:
which are triggered from hardware, working environment, or external modules, for example a keypad event. Usually, programmers need to customize external event management according to specific hardware, working environment.
APIs: XGetExtEvent(), XDelExtEvent(), XPostThreadExtIntEvent(), XPostThreadExtPtrEvent()
Event transform for Windows and Linux:
There is a cross-platform XWaitForEvent() and XGetExtEvent()
int XWaitForEvent(XEVENT *pEvent, XMUTEX *pMutex, XIS_CODITION_OK_T pIsConditionOK, void *pCondParam,
XTHREAD_SAFE_ACTION_T pAction, void *pActionParam)
BOOL XGetExtEvent(SME_EVENT_T* pEvent)
XWaitForEvent() function waits for an event signaled and then take thread-safe actions. XGetExtEvent() function call XWaitForEvent() to get an event and transform Windows/Linux events to StateWizard events.
In Windows platform, XWaitForEvent() function is implemented via GetMessage() and DispatchMessage() APIs. In Linux platform, XWaitForEvent() function is implemented via pthread and mutex.
Event transform for QT:
There is an event loop when QApplication::exec() is called. The behaviors are like:
while ( !app_exit_loop )
{
while( !postedEvents ) { processPostedEvents() }
while( !qwsEvnts ){ qwsProcessEvents(); }
while( !postedEvents ) { processPostedEvents() }
}
More commonly, an object needs to look at another's events. Qt supports this using QObject::installEventFilter() (and the corresponding remove). For example, dialogs commonly want to filter key presses for some widgets:
MainWidget::MainWidget()
{
CodeEditor * ce = new CodeEditor( this, a€?code editora€ );
ce->installEventFilter( this );
}
bool MainWidget::eventFilter( QOject * target , QEvent * event )
{
if( target == ce )
{
if( event->type() == QEvent::KeyPress )
{
QKeyEvent *ke = (QKeyEvent *) event;
// Transform QT events to StateWizard events.
}
}
return false;
}
It's also possible to filter all events for the entire application, by installing an event filter on QApplication.
Copyright 2007 IntelliWizard Inc. All Rights Reserved.
|
