search

modelica-3rdparty / Modelica_DeviceDrivers

Free library for interfacing hardware drivers to Modelica models. There is support for joysticks, keyboards, UDP, TCP/IP, LCM, MQTT, shared memory, AD/DA converters, serial port and other devices.
BSD 3-Clause "New" or "Revised" License
77 stars 31 forks source link

Update library to MSL 4.0 #315

Closed bernhard-thiele closed 4 years ago

bernhard-thiele commented 4 years ago

MSL 4.0.0 is soon to be released.

Updating MDD to run smoothly with MSL 4.0.0 (e.g., using Modelica.Clocked instead of Modelica_Synchronous) will loose backwards compatibility to MSL 3.x. Hence. we will need to increase the version number to MDD v2.0.0 according to semantic versioning conventions.

A quick test with MDD showed that the automatic conversion scripts from MSL 3.x to 4.0 work, so updating MDD to use MSL 4.0 seems easy. My Dymola Version 2021 Beta 3 generates following conversion script for updating the MDD master to MSL 4.0.0. 

// Generated by conversion of Modelica_DeviceDrivers
convertElement("Modelica_DeviceDrivers.Blocks.Examples.TestHardwareIOComedi","sine.freqHz","sine.f");
convertElement("Modelica_DeviceDrivers.Blocks.Examples.TestHardwareIOComedi","sine1.freqHz","sine1.f");
convertElement("Modelica_DeviceDrivers.ClockedBlocks.Examples.TestHardwareIOComedi","sine.freqHz","sine.f");
convertElement("Modelica_DeviceDrivers.ClockedBlocks.Examples.TestHardwareIOComedi","sine1.freqHz","sine1.f");
convertElement("Modelica_DeviceDrivers.Incubate.Bustesting.TestTheBus","comp1_1.sine.freqHz","comp1_1.sine.f");
convertElement("Modelica_DeviceDrivers.Incubate.Bustesting.Comp1","sine.freqHz","sine.f");

The conversions are only in the MDD examples, not in the components. Hence, we probably don't need to deliver a conversion script.

Since we loose backwards compatibility to previous MSL 3.x versions anyway, we can also change some code to use newer blocks, e.g. the Modelica.Icons.FunctionsPackage icon which we have avoided so far.

Mentioning @tbeu so that you are aware of this issue.

tbeu commented 4 years ago

I will also update paho.mqtt.c soon again. Will there be different branches for MSL 3 and MSL 4 dependency?

bernhard-thiele commented 4 years ago

I think we should fully move to MSL 4 for new features, because otherwise maintenance efforts increase a lot. Maybe if there is bad bug which plagues people who need MSL 3 we can do another MSL 3 based bugfix release, but otherweise v1.8.2 would be the last MSL 3 release.

However, maybe it's a good idea to create an MSL 3 branch before merging #317. What name should it have? Maybe maint/msl3. What are your thoughts?

tbeu commented 4 years ago

Having a maint/1.8.x branch branching off from 61247667adad45a1b769bfa0cd5011e33eafa513 (= v1.8.2) would be my first preference. If you however plan to have a v1.8.3 release anyway, we can branch off from current HEAD. But I agree, maintenance effort should be kept minimal.

bernhard-thiele commented 4 years ago

Okay, that sounds good. I created the maint/1.8.x branch and will merge #317 next.