All the runtime modules are actually a set of compiled libraries. The libraries can be reused for other projects as they are supplied in source code form. The runtime modules actually comprise an interface between the generated behavioral logic and the underlying operating system.
Porting the generated behavioral components to a particular environment primarily means to tailor the runtime library to use the specific services provided by the operating system/real-time kernel, or in cases where none of them exist, to provide an alternative functionality.
The following diagram shows the layers of software components in the embedded application. The final executable image is built from some permanent modules, in addition to the generated modules that are dependent on the application.
●
|
The scheduler component is optional - It is needed only if the user specifies that basic activities should be implemented as tasks or desires to link a graphic panel into the executable.
|
●
|
Callback handler - Is used only if the user selects to attach callback routines to behavioral logic components.
|
●
|
Memory management - The runtime modules timer, double-buffering and callback handlers utilize dynamic memory allocations. Under certain assumptions it is possible to tailor them to use only static allocation, if a memory management package is not available or memory resources are limited.
|
●
|
Multi-threading (tasking) support - This support provides a mechanism for creating task threads and switching between them. This service is needed only if the user wishes to implement environment tasks or basic activities as tasks. This issue is discussed in greater detail in this document.
|