Premise

Embedded Engineer comes with a UML profile for your model which enables quick access to the most commonly used elements for code generation.

Basic Ideas

The Embedded Engineer is target agnostic and will therefore not limit the user to one specific hardware, framework or compiler. We also opted for a generic language implementation to allow the user to use any language feature and compiler. All new and old language features can be added to the code/model using the Embedded Engineer UML Profile.

Basic structural features such as classes, structs, enums, attributes operations,... will be generated as modelled, into the corresponding implementation and declaration files.

All Activities will be represented in the code as functions containing the modelled behavior.

All StateMachines will result in a struct and two functions, one to initialize the StateMachine and one to run it. Since we do not rely external frameworks or hardware (hence target agnostic), we do not provide a specific way to run a StateMachine. To do this you simply need to call the init function and then, periodically, call the run function. If this is implemented via a loop, thread, interrupt,... or any means, is up to the developer and his/her target specifications.

Details

Embedded Engineer is designed to produce small and efficient C/C++ code from behavioral models. It can generate code for the following elements:

• Structural Elements
  • Packages
  • Classes
• Behaviors
  • Activities
  • State Machines

Model Requirements

Since the generated code from the UML elements will need to be stored into files/classes, Embedded Engineer uses the following "model structure" to generate the code.

Packages

A Package is the starting point of every code generation and can also store ModelSettings. To generate code from a Package set its Stereotype to LL Embedded. This will add the SrcGenDir and GenerationLanguage Tagged Values to set the output directory and the language to be generated for all its sub elements/packages.

Sub Packages can be used to provide a better overview, structure and even set custom settings, but can also be used to generate sub directories in the output folder.

Classes, Interfaces,...

Any Class, Interface, Struct,... element stored inside a LL Embedded Stereotyped Package (or its sub Packages) will be used to generate code files (implemenation and declaration). These code files will contain the Class, Interface, Struct,... their contained attributes, operations and the behavior as modelled in the repository.

Behavior

Any Activity and/or State Machine needs to be stored inside a Class to generate the implementation and declaration in to the appropriate code files.

Model Struture Overview

The Embedded Engineer Code Generator generates code for the selected package, all its Structural Elements and Behaviors (and its sub packages).

This Image shows the main structure needed in your model to successfully generate code.

The starting point is always a package containing Classes, Interfaces,... which in turn contains the Activites, State Machines and Operations defining the behavior of their owners.

Opaque behaviors allow you to incorporate and even sync User Code between model and code files.

Generated Files

When you generate code for classes with Embedded Engineer, you'll get at most two (depending on the language) files for each class, as well as one file for the signals.

In the case of C-Code generation, you'll typically get one source file and one header file per class, and one header file per interface. These will be written to the directory you've specified at code generation, and they will be named after the class or the interface they are generated from.

The files also contain all the neccessary code from the behaviors and operations of the class or interface, as well as any dependencies you've specified in your class diagram.

If specified in the Model Settings Generate Directories for Packages each sub package will result in a sub directory in the generation directory.

The generation directory will also contain an UmlDebuggerInfo file (.udi) whith the same name as the package where generation was started.

This UmlDebuggerInfo file contains the mapping from model element to generated code and all other information needed for the UmlDebugger.