AVR Support

[bernhard-thiele]

Thanks to @sjoelund (#169) we now have initial support for AVR.

Probably there will be some comments and this issue can collect such things.

The first thing that I don't want to loose is the documentation aspect. #169 describes briefly how to use the package with OpenModelica. I will repeat this below, so that it is visible in an open ticket. Finally, it should be documented in the library in some way.

[bernhard-thiele]

To try the Blink example in OpenModelica using the experimental code generator that lacks makefiles...

blink.mos:

loadFile("/home/marsj/dev/Modelica_DeviceDrivers/Modelica_DeviceDrivers/package.mo");getErrorString();
getSourceFile(Modelica_DeviceDrivers);
translateModel(Modelica_DeviceDrivers.EmbeddedTargets.AVR.Examples.Arduino.UNO.Blink, fileNamePrefix="Blink");getErrorString();

omc --simCodeTarget=ExperimentalEmbeddedC blink.mos
avr-gcc -Os -std=c11 -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000UL -Wl,--gc-sections Blink_main.c -o Blink -I ~/dev/Modelica_DeviceDrivers/Modelica_DeviceDrivers/Resources/Include -I ~/OpenModelica/build/include/omc/c
avr-objcopy -O ihex -R .eeprom Blink Blink.hex
avrdude -F -V -c arduino -p ATMEGA328P -P /dev/ttyACM0 -b 115200 -U flash:w:Blink.hex

[tbeu]

SimulationX issues a IncompatibleBaseClass warning if a block extends from a model, see

The Modelica class of Modelica_DeviceDrivers.EmbeddedTargets.AVR.Blocks.Microcontroller (block) and its base class Modelica_DeviceDrivers.Utilities.Icons.GenericIC (model) are not compatible.
Message: Modelica.IncompatibleBaseClass

[tbeu]

SimulationX does not support the multiple definition import of MLS 3.3. :no_mouth:

[tbeu]

SimulationX issues a IncompatibleBaseClass warning if an external object extends from a model, see

The Modelica class of Modelica_DeviceDrivers.EmbeddedTargets.AVR.Functions.Digital.InitRead (model) and its base class BuiltIn.ExternalObject (type) are not compatible.
Message: Modelica.IncompatibleBaseClass

The remedy is to use class like it is done for all other external objects.

[tbeu]

SimulationX has loading problems with using initial() as function argument in SynchronizeRealtime.

[tbeu]

There already is RealTimeSynchronization.mo in OperatingSystem, so SynchronizeRealtime.mo could be renamed for sake of consistency.

[sjoelund]

I did the RealTimeSynchronization.mo / SynchronizeRealtime.mo to be consistent with the rest of M_DD:

• Modelica_DeviceDrivers.Blocks.OperatingSystem.SynchronizeRealtime
• Modelica_DeviceDrivers.OperatingSystem.RealTimeSynchronization

I guess due to the 3.2r1 change to initial() (and not allowing not initial()), the AVR implementation not allowing events, and models unable to access the start-time of a simulation in Modelica, there is no very good solution for modeling the behavior I want. A floating-point comparison to just see if initialization finished is not very nice... Anyone got a better idea? Calling wait() during initialization is a bad idea in general (the AVR code generation does not support initial equations and skips initialization, but that's beside the point).

@bernhard-thiele Should M_DD be conforming to the MLS 3.2 grammar or not? (If it should, I need to remove the impure keyword as well; if impure is allowed, multiple import should be allowed as well...)

The extending from wrong base class should be an easy fix (#171).

[tbeu]

for modeling the behavior I want. ... Anyone got a better idea?

What exactely do you want to model? A one-time function call at initialization time?

[sjoelund]

Not calling during initialization, but at every other point in time.

[sjoelund]

For reference, adding a single-precision floating point comparison is around 10µs (+0.5% of total available RAM to store the start-time), which is a bit much for my taste...

[sjoelund]

I guess I should also add that the preferred way to model it would be using Synchronous Modelica... But my code generator does not support it yet ;)

[tbeu]

Can you pls point me to MLS 3.2r1 where initial() is allowed as function argument? Do we have it in Modelica Compliance suite? Maybe I need to file a tool issue of it.

[sjoelund]

It is not allowed. Only in when-statements (since MLS 3.2r1). OpenModelica supported the more general use of initial() (anywhere except inside function body).

[tbeu]

SimulationX allows if not initial() then in an equation/algorithm section.

[sjoelund]

Hmm... is initial() only restricted in the condition of a when-clause? In that case, my pattern would work (except perhaps the default binding of initial() in the function itself...). Having to add an equation section section to bind a Boolean would just a minor work-around for SimulationX.

[sjoelund]

Modelica compliance even includes the form explicitly forbidden :)

[tbeu]

Yeah, it's a non-standard feature :)

[sjoelund]

So after #171, #172, we have the multiple import issue (easy to fix, if it should be fixed). And the weird naming (which is just to be similar to existing M_DD blocks and functions)...

[sjoelund]

And, of course... Documentation...

[sjoelund]

Also regarding documentation, above is the current method of activating the code generator in OM. But this is subject to change (and possibly the GUI should have some support for this; perhaps with vendor annotations on the examples).

[tbeu]

Would be nice, if the impure functions of MLS 3.3 could be converted to functions complying to MLS 3.2 with annotation(__ModelicaAssociation_Impure=true).

[tbeu]

All functions should extend from Modelica.Icons.Function.

[tbeu]

Would be nice, if the impure functions of MLS 3.3 could be converted to functions complying to MLS 3.2 with annotation(__ModelicaAssociation_Impure=true).

@bernhard-thiele Please be aware that the current master does not succeed to load in tools that do not support the impure keyword of MLS 3.3 yet.