Documentation for sexec

[rishab dhar]

Hi,

I was trying to write the custom code generator for AVR AT90CAN128 microcontroller and needed some documentation on sexec metamodel elements. I wanted to access the variables, events, entry actions, exit actions, states, transitions for the Xpand template that I want to write. If there is no documentation, how can I access these properties?

[Axel Terfloth]

Hi Rishab,

> Hi,
>
> I was trying to write the custom code generator for AVR AT90CAN128 microcontroller and needed some documentation on sexec metamodel elements. I wanted to access the variables, events, entry actions, exit actions, states, transitions for the Xpand template that I want to write.

Yes - there is currently no publicly available documentation. That is an open issue for some time and we will provide documentation on how to build custom code generators. We will do that as soon as we have finished our built in generators. This is currently not the case as we are still working on these topics. As an example we are currently reimplementing the C code generator using Xtend2.

One goal is to make the built in code generators reusable and customizable since implementing a generator from scratch is a big bunch of work. The sexec meta model plays an important role in this context. An sexec model will be created from the original statechart model and captures the execution semantics using an imperative / control flow based paradigm. It is still target language independent and we use it in all our code generators. Each code generator in turn consists of two main parts. First the part that generates the target language or platform specific code and the second that generates the behavioral parts (function implementations). The generators will be build in a way that it is possible to derive a more specific code generator based on our base implementation.

> If there is no documentation, how can I access these properties?

Currently the best approach is to take a look at the sources. Check out the project 'org.yakindu.sct.generator.c' from our subversion. The subversion repository can be found at:

http://svn.codespot.com/a/eclipselabs.org/yakindu/

You will find the plugin project in 'SCT2/trunk/plugins'. See also the checkout instructions at: http://code.google.com/a/eclipselabs.org/p/yakindu/source/checkout .
Within the project take a look at the xpand templates in the package 'org.yakindu.sct.generator.c.templates'. The main templates is in Main.xpt . When you define a plugin dependency to this plugin, then you should be able to reuse Xpand templates and Xtend(1) extension functions.

But please be aware, that this generator will be deprecated as soon as the new version is available.

Best regards,

Axel

[rishab dhar]

Hi,

Could you please point out to me where I need to make changes or which templates need to be modified so that I can include AVR specific variables such as DDRA, PORTA, without actually having to define them in interfaces. I just want to directly access these variables (which are defined in the library of avr) or any other external functions directly in the state machine.

As an example I'll attach the file that shows what I want to be generated with my state machine.

Best,

RIshab

[Axel Terfloth]

Hi,

the information that you provided was very helpful to understand your requirements - and by the way  it seems to be an interesting application context...

You address some points that are well known to us. Integration with external C definitions are a typical question. This is a point on our roadmap and we don't support that at the moment. The current implementation of the SCT editor requires that all elements used in an expression are well defined. Thus you still need to define a scope with all variables and operations that you want to use. It is generally possible to define and integrate a custom declaration and action language, but this is likely to much effort in your case. So a pragmatic approach could be to define an interface scope like this:

interface AVR:

var external PORTA : integer

operation do_x(i : integer) : integer

That is the way i would represent external elements. The current Xpand based C code generator does not support this out of the box, So you would have to adjust:

- Expression.ext : 'String toCCode(VariableDefinition )' creates the access code for variables. You could simply check if the variable is external and defined in the 'AVR' named InterfaceScope and generate a simple variable access in this case.

- Interfaces.xpt : here you have to skip the variable definitions : 

Please be aware that we are working on a new version of the code generator and we will discontinue maintenance of the current. The new code generator will be based on Xtend2 instead of Xpand/Xtend(1) . 

As you have already found out our state machine API does not directly address your state machine invocation semantics. One approach could be to wrap our generated code. counter_tick seems to map dirctly to X_runCycle() and also counter_event_raised() could be implemented by setting the event and then invoking runCycle(). The result should be the same. Of course there will be some differences regarding runtime behavior and your code generation approach seems to be a good example for a customized code generator. I think that you could already reuse major parts of the sexec model even though the control flow for the event-handling functions (counter_event_raised) is not in place as well as the code generator.  To fill the sexec gap customization of the intermediate transformation would make sense.

Best regards,

Axel

<specification_paper.split.zip>

Axel Terfloth

Leiter Forschung & Entwicklung Embedded Systems

Telefon: +49 (0) 231 / 98 60-218

Telefax: +49 (0) 231 / 98 60-211

Mobil: +49 (0) 151 / 10860464

http://www.itemis.de

axel.t...@itemis.de

https://www.xing.com/profile/Axel_Terfloth

itemis AG

Am Brambusch 15-24

44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus