Overview and structure of the target

Target Engee — this is the support package that binds the model Engee with a specific target platform. The platform can be a microcontroller, a debugging board, an industrial device, a remote Linux computer, or a local application.

Target performs all the necessary steps — from the model Engee before launching on the target platform:

Gets a description of the model and startup settings.
Uses the C code, generated from the model Engee.
Generates a project for the target platform.
Builds a project with a suitable toolchain.[A toolchain is a set of console tools (compiler, linker, and utilities) that assemble firmware for a microcontroller from the source files of a project.].
Loads or launches the assembled artifact.
If necessary, it organizes data exchange with the model during execution.

User Target added to Engee.Integration and syncs with Engee and after that it can be used in scripts and blocks.

Target structure

The minimum target template is placed in the directory targets. It is convenient to create a separate folder for one platform.:

my_extension/
└── targets/
    └── MyTarget/
        ├── __init__.py
        └── MyTarget.py

The custom embedded System Support Package (target) should be located in targets/<target_folder>/.

As a rule, targeting also requires templates, drivers, build files, a library of blocks, and demo models, for example:

my_extension/
└── targets/
    └── MyTarget/
        ├── __init__.py
        ├── MyTarget.py
        ├── README.md
        ├── blocks_library/
        │   └── engee_my_target.nglib
        ├── demos/
        │   └── example_my_target.engee
        ├── drivers/
        │   ├── platform_driver.c
        │   └── platform_driver.h
        ├── templates/
        │   ├── main.c
        │   └── CMakeLists.txt
        ├── FirmwareBuilder.py
        └── FirmwareLoader.py

The above scheme is generalized. For Arduino-compatible platforms instead of main.c a file with the extension can be generated .ino. For bare-metal, RTOS, or Linux platforms, it is more convenient to generate main.c and the build file.

Assignment of standard parts:

MyTarget.py — main target class and the block parameter model EDM-Target;
init.py — import the main class so that the support package download mechanism can find it;
templates — Jinja-entry point templates, planner/runtime code and build files;
drivers — platform- based drivers C/C++ and C-API called from blocks C Function;
FirmwareBuilder.py — wrapper over the compiler and build system;
FirmwareLoader.py — download the firmware;
blocks_library — library of blocks Engee for the user;
demos — models that allow you to quickly get started with the device.

Operating modes

Supported two modes of model execution: independent and interactive.

Independent mode

Independent mode means that after the build and upload, the model is executed on the target platform independently. Engee It starts the chain of generation, assembly and loading, but does not maintain a constant channel of communication with runtime during the execution of the model.

A typical independent execution scenario contains the following steps:

Engee generates the C-code of the model.
Target creates a project for the target platform.
The tulchain builds the firmware, binary or executable file.
The target uploads the artifact to the device or launches the application.
The model runs offline until completion, reboot, power off, or other platform event.

From the point of view of developing a new target, this mode is preferable at the initial stage: it requires less runtime infrastructure and allows you to first check the correctness of generation, assembly, timer, and calling step functions.

Interactive mode

Interactive mode means that the model runs on the target platform, and Engee during execution, it connects to it, receives the values of the selected signals, and can change the configurable parameters without reassembling and uploading.

Running the C code alone is not enough for this mode. We need a communication channel between Engee and a model. In the examples above, this channel is based on the XCP (Universal Measurement and Calibration) protocol^[1].

A typical interactive execution scenario contains the following steps:

Engee generates the C-code of the model.
Target creates a project with an interactive runtime.
XCP slave and platform transport, such as UART or TCP, are added to the project.
The toolchain collects an artifact and an ELF file with model symbols.
The target loads or launches the model.
Engee connects to the runtime, starts the data stream and sends commands to change the parameters.

Targeting with interactive mode support is more difficult to implement than targeting with independent mode only, since in addition to building and launching, it must provide the correct transport, addressing of memory, the presence of characters in ELF file and regular maintenance of data exchange in scheduler of the model.

What to choose first

If the platform is new, then it’s worth starting with an independent mode.:

it’s easier to check the base path from the model to the executable artifact.;
fewer runtime and tulchain requirements;
model assembly, loading, and planning errors are easier to separate from data exchange errors.

The interactive mode should be added after the independent mode script works stably on a simple model.

1. XCP (Universal Measurement and Calibration) is an ASAM MCD—1 XCP standard for accessing internal application data during its operation.