Difference between revisions of "Understand the code generation strategy"

From TASTE
Jump to: navigation, search
(Created page with " == Introduction == In this chapter we explain the structure and organization of the code generated by TASTE using the Kazoo tool. We will go step by step through the creat...")
 
Line 19: Line 19:
  
 
:[[File:ClipCapIt-200220-105857.PNG]]
 
:[[File:ClipCapIt-200220-105857.PNG]]
 +
 +
The next step is to generate the '''code skeletons'''. You can do that from the tool menu:
 +
 +
:[[File:ClipCapIt-200220-110129.PNG]]
 +
 +
 +
== Code skeletons structure ==
 +
 +
A folder named "work" has been created to hold the code skeletons of the project.
 +
 +
 +
Let's explore this folder:
 +
 +
:[[File:ClipCapIt-200220-110407.PNG]]
 +
 +
 +
For each of the function that appear in the interface view, a subfolder with the same name has been created.
 +
 +
Because it is possible to provide several implementations of the same component but in different languages, a subfolder per language has also been created (C, Ada, SDL, GUI).
 +
 +
Finally, the "src" directory contains the source code of the function, which can be edited by the user. Lets look at them, starting with the watchdog, implemented in C:
 +
 +
:[[File:ClipCapIt-200220-110835.PNG]]
 +
 +
As you can see this is straightforward. The .h lists the available required interfaces that this component can call:
 +
 +
 +
:[[File:ClipCapIt-200220-111010.PNG]]
 +
 +
And the .c is the file that implemented the provided interfaces. User has to provide the content of these functions:
 +
 +
:[[File:ClipCapIt-200220-111055.PNG]]
 +
 +
If you make modifications to the model, the .c file will not be overwritten. If you add interfaces, you will need to add them manually in the .c file. This can be done easily because the .h will be re-generated and provide the new function signature.
 +
 +
 +
It is similar for the other functions, in Ada:
 +
 +
:[[File:ClipCapIt-200220-111238.PNG]]
 +
 +
 +
..and in SDL:
 +
 +
:[[File:ClipCapIt-200220-111306.PNG]]
 +
 +
 +
You may notice the presence of a Makefile in each of these directories. It contains a helper rule to edit the source code or in some cases invoke a code generator:
 +
 +
:[[File:ClipCapIt-200220-111501.PNG]]
 +
 +
 +
 +
== Code for the GUI component ==
 +
 +
When you set the implementation language to GUI, you instruct TASTE to generate a stub function. It consists of a piece of C code that can interact at runtime with the user through a graphical user interface generated in Python, via a message queue.
 +
The code is generated in the src folder. It is not different from a standard C function, except that the code is pre-filled:
 +
 +
:[[File:ClipCapIt-200220-111940.PNG]]
 +
 +
 +
== The Data view ==
 +
 +
All the functions exchange data that is specified in the ASN.1 language. During the code skeleton generation, the ASN.1 models and translated to code too by the ASN1SCC compiler. You can see this code in the Dataview folder:
 +
 +
 +
:[[File:ClipCapIt-200220-112234.PNG]]
 +
 +
 +
There is one folder for Ada (needed by the stm32_board component) and one for C. The SDL function can work directly with the native ASN.1 models so no extra code is needed.
 +
 +
You can see that more files are generated in the C folder, because the compiler was also requested to generated '''binary encoders and decoders''' for each data types. This is needed to create the binary packets that will be sent over the serial link. To understand this, take this enumerated definition that exists to specify the color of the traffic light:
 +
 +
:[[File:ClipCapIt-200220-112628.PNG]]
 +
 +
In the C language this is translated to a standard enum type:
 +
 +
:[[File:ClipCapIt-200220-112802.PNG]]
 +
 +
 +
However in C, depending on the target (intel/x86 or STM32)

Revision as of 10:28, 20 February 2020

Introduction

In this chapter we explain the structure and organization of the code generated by TASTE using the Kazoo tool.

We will go step by step through the creation of a small project and describe what code is generated at which step, for which purpose, and then how the overall build to create a binary is done.


Create a toy example

We are going to model a traffic light controller that has two nodes - one running on a STM32 microcontroller, and one running on a PC. The nodes will be connected via a serial link.

To create the project, run taste:

   $ taste

We will put a few functions and connect them together. We mix implementation languages on purpose to illustrate how code will look like:

ClipCapIt-200220-105857.PNG

The next step is to generate the code skeletons. You can do that from the tool menu:

ClipCapIt-200220-110129.PNG


Code skeletons structure

A folder named "work" has been created to hold the code skeletons of the project.


Let's explore this folder:

ClipCapIt-200220-110407.PNG


For each of the function that appear in the interface view, a subfolder with the same name has been created.

Because it is possible to provide several implementations of the same component but in different languages, a subfolder per language has also been created (C, Ada, SDL, GUI).

Finally, the "src" directory contains the source code of the function, which can be edited by the user. Lets look at them, starting with the watchdog, implemented in C:

ClipCapIt-200220-110835.PNG

As you can see this is straightforward. The .h lists the available required interfaces that this component can call:


ClipCapIt-200220-111010.PNG

And the .c is the file that implemented the provided interfaces. User has to provide the content of these functions:

ClipCapIt-200220-111055.PNG

If you make modifications to the model, the .c file will not be overwritten. If you add interfaces, you will need to add them manually in the .c file. This can be done easily because the .h will be re-generated and provide the new function signature.


It is similar for the other functions, in Ada:

ClipCapIt-200220-111238.PNG


..and in SDL:

ClipCapIt-200220-111306.PNG


You may notice the presence of a Makefile in each of these directories. It contains a helper rule to edit the source code or in some cases invoke a code generator:

ClipCapIt-200220-111501.PNG


Code for the GUI component

When you set the implementation language to GUI, you instruct TASTE to generate a stub function. It consists of a piece of C code that can interact at runtime with the user through a graphical user interface generated in Python, via a message queue. The code is generated in the src folder. It is not different from a standard C function, except that the code is pre-filled:

ClipCapIt-200220-111940.PNG


The Data view

All the functions exchange data that is specified in the ASN.1 language. During the code skeleton generation, the ASN.1 models and translated to code too by the ASN1SCC compiler. You can see this code in the Dataview folder:


ClipCapIt-200220-112234.PNG


There is one folder for Ada (needed by the stm32_board component) and one for C. The SDL function can work directly with the native ASN.1 models so no extra code is needed.

You can see that more files are generated in the C folder, because the compiler was also requested to generated binary encoders and decoders for each data types. This is needed to create the binary packets that will be sent over the serial link. To understand this, take this enumerated definition that exists to specify the color of the traffic light:

ClipCapIt-200220-112628.PNG

In the C language this is translated to a standard enum type:

ClipCapIt-200220-112802.PNG


However in C, depending on the target (intel/x86 or STM32)