RKH
 All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
  1. Declaring the state machine's objects
rkh_bunner.jpg


Prev: Declaring the pseudostates
Next: Declaring the actions

The "my.h" file contains the definitions of objet structures (state machine, states, and pseudostates) and other facilities shared among the components of the application. See the "my.h" file. The following listing shows the "my.h" header file, which illuminates some important aspects of implementing state machines with RKH.

In my.h: active object specification file.

...
/* --------------------------- Include files --------------------------- */
(1) #include "rkh.h"
...
/* .............................. Signals .............................. */
typedef enum Signals Signals;
(2) enum Signals
{
ZERO, /* press the key '0' on the keyboard */
ONE, /* press the key '1' on the keyboard */
TWO, /* press the key '2' on the keyboard */
THREE, /* press the key '3' on the keyboard */
FOUR, /* press the key '4' on the keyboard */
FIVE, /* press the key '5' on the keyboard */
SIX, /* press the key '6' on the keyboard */
TERM /* press the key escape on the keyboard */
};
typedef struct
{
(3) RKH_EVT_T event; /* base structure */
(4) rkhuint16 ts; /* parameter 'ts'. Private member */
} MyEvt; /* derived from RKH_EVT_T structure */
...
/* ...................... Declares active object ....................... */
(5) RKH_SMA_DCLR(my);

In my.c: active object implementation file.

...
/* ........................... Active object ........................... */
(6) struct MySm
{
RKH_SMA_T sma; /* base structure */
rui8_t x; /* private member */
rui8_t y; /* private member */
}; /* SMA derived from RKH_SMA_T structure */
...
/* ...................... States and pseudostates ...................... */
(7) RKH_DCLR_COMP_STATE S1,S3,S11;
RKH_DCLR_BASIC_STATE S2,S31,S32,S111,S112,S12;
#endif
  • (1) RKH interfaces.
  • (2) The events in the my state machine have been identified in the state diagram in fig1 Figure 1. Note that events consist really of two parts. The part of the event called the signal conveys the type of the occurrence (what happened). For example, the ONE signal conveys the arrival of a press key '1'. An event can also contain additional quantitative information about the occurrence in form of event parameters. In my state machine, all signals are accompanied by the parameter (ts) that contain the quantitative information as to timestamp. In RKH, events are represented as instances of the RKH_EVT_T structure provided by the framework. Specifically, the RKH_EVT_T structure contains the member e, to represent the signal of that event. Event parameters are added in the process of inheritance. Because events are explicitly shared among most of the application components, it is convenient to declare them in the separate header file "my.h".
  • (3-4) The MYEVT_T structure declares an event with the parameter "ts". Such nesting of structures always aligns the data member RKH_EVT_T at the beginning of every instance of the derived structure. In particular, this alignment lets treat a pointer to the derived MYEVT_T structure as a pointer to the RKH_EVT_T base structure. Consequently, can always safely pass a pointer to MYEVT_T to any C function that expects a pointer to RKH_EVT_T.
  • (5) Declares a opaque pointer to my SMA to be used as a global object.
  • (6) The MySm defines the SMA object structure my. On the other hand, almost every SMA must also store other "extended-state" information. You supply this additional information by means of data members enlisted after the base structure member sm. Please note that the RKH_SMA_T member sm is defined as the FIRST member of the derived struct. RKH_SMA_T is not intended to be instantiated directly, but rather serves as the base structure for derivation of state machines in the application code.


Prev: Declaring the pseudostates
Next: Declaring the actions