RKH
|
Prev: Cross-platform examples
This application deals with the shared resource problem in active object systems. Showing one of the biggest benefit of using active objects: resource encapsulation. The encapsulation naturally designates the owner of the resource as the ultimate arbiter in resolving any contention and potential conflicts for the resource. The shared application is relatively simple and can be tested only with a couple of LEDs on your target board. Still, Shared contains five (5) concurrent active objects that exchange events via direct event posting mechanism. The application uses four timers, as well as dynamic and static events. On the other hand, this application could be used in either preemptive or cooperative enviroment. Aditionally, the Shared could be used to verify a new RKH port.
The platform-independent Shared source code (in C) is located in the <rkh>/demo/cross/shared/
directory, where <rkh>
stands for the installation directory chosed to install the accompanying software and client.h
, server.h
, shared.h
, client.c
, main.c
and server.c
are the platform-independent files. Thus, the code is actually identical in all Shared versions, such as the Windows version, S08 version, and so on.
The sequence diagram in Figure 1 shows the most representative event exchanges among three Clients (cli0, cli1, cli2) and the Server (svr) active objects.
The server shares their resource with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with the server which await incoming requests. The server selectively shares its resource; and a client initiates contact with the server in order to make use of the resource. Clients and server exchange messages in a request-response messaging pattern: The client sends a request, and the server returns a response.
As an additional feature, the Clients can be paused for an arbitrary period of time. During this paused period, the Clients don't get permissions to request. After the pause period, the Clients should resume normal operation.
Figure 2(a) shows the state machine associated with Client active object, which clearly shows the life cycle consisting of states "cli_idle"
, "svr_paused"
, "svr_waiting"
, and "cli_using"
. See Client state-machine implementation section.
Figure 2(b) shows the state machine associated with the Server active object, with "svr_idle"
, "svr_paused"
, and "svr_busy"
states. See Server state-machine implementation section.
The client.c file implements the state machine of Client 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 client.h contains the definitions of object structures related to the state machine. See the following sections:
"client.c" - Client active object implementation
Prev: Client state-machine implementation
"client.h" - Client active object specification
Prev: Client state-machine implementation
The server.c file implements the state machine of Server 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 svr.h contains the definitions of object structures related to the state machine. See following sections:
Prev: Server state-machine implementation
"server.h" - Server active object specification
Prev: Server state-machine implementation
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 Shared application (shared.h).
"shared.h" - Signals and events
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.c
and bsp.h
files, which are contained in the proper directory, for example, the BSP for the Shared application on Windows 32 (Visual Studio 2008) with a simple cooperative scheduler is located in <rkh>/demo/cross/shared/build/80x86/win32_st/vc/
CPU Architecture | Manufacturer | MCU | Evaluation Board | Toolchain | Comments | Notes |
---|---|---|---|---|---|---|
S08 | Freescale | S08QE128 | DEMOQE128 | Codewarrior v10.x | Native cooperative scheduler | |
ARM-Cortex | Freescale | Kinetis K64 | FRDM-K64F | KDS | uC/OS-III on KSDK | |
Native cooperative scheduler | ||||||
Kinetis K60 | TWR-K60N512 | IAR v7.2 | uC/OS-III | Deprecated | ||
Native cooperative scheduler | Deprecated | |||||
80x86 | — | — | — | Visual Studio C++ 2010 | Win32 cooperative scheduler simulation | |
— | — | — | Visual Studio C++ 2010 | Win32 multithread |
Prev: Cross-platform examples