Prev: Cross-platform examples
The goal of "Blinky" demo application is to explain how to represent a "flat" state machine, how to use the timer services, and trace facility from RKH framework. To do that is proposed a very simple demo that use one state machine and one timer, which is shown and itself explained in the Blink a LED state diagram. This is the 'hello world' of RKH programming.
The platform-independent Blinky source code (in C) is located in the
<rkh>\demo\cross\blinky\ directory, where
<rkh> stands for the installation directory chosed to install the accompanying software and
main.c are the platform-independent files. Thus, the code is actually identical in all Blinky versions, such as the Windows version, Linux version, arm-cortex version, and so on.
The following figure shows the state machine associated with Blinky active object, which clearly shows the life cycle consisting of states
blinky_init()function defines the topmost initial transition in the blinky state machine. The function prototype is defined as RKH_INIT_ACT_T. This argument is (optional), thus it could be declared as NULL.
LED_OFF_TIMEmilliseconds, turn off the LED, and increments the counter.
The blinky.c file implements the state machine of Blinky active object, which illustrates some aspects of implementing state machines with RKH framework. Please correlate this implementation with the state diagram shown above. On the other hand, the header file blinky.h contains the definitions of object structures related to the state machine.
"blinky.c" - State machine representation
The related actions (entry, exit, guard, and state transition) to be executed by the state machine are implemented and declared in the blinky.c. Note that the
rkhcfg.h file defines the prototypes of them.
"blinky.c" - Actions
In RKH, signals are typically enumerated constants and events with parameters are structures derived from the RKH_EVT_T base structure. The next listing shows signals and events used in the Blinky application (blinky.h).
"blinky.h" - Signals, events, and active objects
Most of the system initialization and application startup can be written in a platform-independent way.
"main.c" - main() function
As said before, the only platform-dependent file is the board support package (BSP) definition. Each of supported platforms defines its own
bsp.h files, which are contained in the proper directory, for example, the BSP for the Blinky application on Windows 32 (Visual Studio 2008) with a simple cooperative scheduler is located in
|CPU Architecture||Manufacturer||MCU||Evaluation Board||Toolchain||Comments|
|ARM - Cortex||NXP||LPC1769||LPCXpresso||Codered||Native cooperative scheduler|
|Freescale||Kinetis K60||TWR-K60D100M||Codewarrior v10.x||Native cooperative scheduler|
|IAR v7.2||Native cooperative scheduler|
|Freescale||Kinetis KL2||FRDM-KL25Z||Codewarrior v10.x||Native cooperative scheduler|
|Freescale||Kinetis K40||KWIKSTIK-K40||Codewarrior v10.x||Native cooperative scheduler|
|Freescale||Kinetis K64||FRDM-K64F||KDS||Native cooperative scheduler|
|Freescale||Coldfire V1||MCF51QE128||DEMOQE128||Codewarrior v6.x||Native cooperative scheduler|
|Freescale||S08||S08QE128||DEMOQE128||Codewarrior v6.x||Native cooperative scheduler|
|80x86||—||—||—||Visual Studio C++ 2010||Win32 cooperative scheduler simulation|
|—||—||—||GNU||Linux cooperative scheduler simulation|
Prev: Cross-platform examples