STM32F4 support

[bernhard-thiele]

PR #216 from @it-cosmos provided support for STM32F4 which I merged into an STM32F4-feature branch (ae66aef).

This ticket shall serve as a point for discussing this feature with the aim to finally merge the feature into the master branch (probably also interesting for @sjoelund who provided the AVR support in #170).

[it-cosmos]

Can the makefile for compiling and creationg the binaries in Modelica_DeviceDrivers/EmbeddedTargets/STM32F4/Examples/STM32F4_Discovery/Blink/Makefile remain on this location?
Here also the blink_main.mos is checked in in this directory. Is this in line with the guide lines?
with the Makefile a Debug directory is created with all object code. Should the location be changed?

[bernhard-thiele]

I just looked a bit more into the code. You moved the third party code into Modelica_DeviceDrivers/3rdParty/STM, however the designated folder for third party code is Modelica_DeviceDrivers/Resources/thirdParty/. Please move the STM code below that directory.

If you have a look into the Resources/thirdParty folder, you can see that I listed the third party code in the Readme.txt. It's important to keep track of the licenses used for the thirdParty code so that the library can be used and shipped safely with (commercial) products. Maybe this could be even done a bit more clear than it is now.

Conventionally, all non Modelica files in a Modelica library are kept below the Resources directory.
Hence, also the blink_main.mos and the Makefile should go there. I should play with it myself to get a feeling of what works best, but the mos script should probably go below a folder Resources/Scripts/OpenModelica, e.g., Resources/Scripts/OpenModelica/EmbeddedTargets/STM32F4/Examples/STM32F_Discovery/ so that the location reflects the concerned model. The Makefile could go into the same directory as the mos file.

Notice that you can easily reference files in the resources directory from the documentation by a construct similar to <a href="modelica://Modelica_DeviceDrivers/Resources/Scripts/MyFile.xxx">MyFile</a>. This could be useful to reference from the documentation to the needed scripts or makefiles.

I maybe would rather create a directory named build instead of Debug. However, since the Makefile actually creates debug object files the name debug fits, too. I have no strong opinion on that.

[it-cosmos]

• I will move STM from 3rdParty to Resources/thirdParty.
• The better place for mos and makefileI for the Blink Example I suggest Resources/Scripts/OpenModelica/EmbeddedTargets/STM32F4/Examples/STM32F_Discovery/Blink, since other examples in future will have different make- and mos files

[bernhard-thiele]

Yes, sounds good.

[it-cosmos]

Shall we add the STMCube32F4 HAL interface into the thirdparty directory? I see no conflict in the license:
http://www.st.com/content/ccc/resource/legal/legal_agreement/license_agreement/de/fc/f7/32/a0/8b/4f/db/ultimate-liberty-v2.txt/files/ultimate-liberty-v2.txt/jcr:content/translations/en.ultimate-liberty-v2.txt
The size is quite big, so it could be provided as zip file.

[bernhard-thiele]

Well, the license seems okay. However, the zip file has almost 400MB and having a link to it in the documentation (as you currently have) seems to be a good way to handle it. It should not go into the thirdparty directory.

[it-cosmos]

Ok, then only work left is to update the "README" file in the thirdParty folder.

Onother question:
I have a look onto the GPIO_EXTI example provided in the STM32F4Cube HAL. I would like to provide this in modelica. In this example the user interrupt is used triggered by the blue user button on the board. On the falling edge of the user button the user LED's are toggled in a callback function. In modelica, is see the only chance to provide the callback function as c-code, which the modelica user has to complete in c-code. As far as I know there is no export facility from modelica to c-function. Any suggestions are welcome.

[bernhard-thiele]

What would be nice, is having a block in which one can configure the external interrupt to use and use that interrupt to activate certain parts of the model. However, there is no direct mapping from Modelica elements to this behaviour, yet. It would be an interesting extension and I would like to see it prototyped in OMC.

For now, I see no nice way how to handle this. It might be possible to sort of use the generated "fmi2DoStep" as a callback function for the ISR, but that would entail some manual C code modifications by the user.

[bernhard-thiele]

Some comments to the build process.

I tried to build the example on my Ubuntu 14.04.5 LTS. It turned out that the cross-compiler packages for that release are not working correctly. This is related to https://stackoverflow.com/questions/26931979/gnu-arm-nano-specs-not-found in which I followed the last suggestion of installing the package gcc-arm-embedded which can be added by an PPA as described at http://yottadocs.mbed.com/#linux-cross-compile. After doing that, I could build the blink project. Today, I ordered the STM32F4 discovery board and I'm looking forward to testing things once the board is delivered.

It would be good to note the Ubuntu version which is the basis for the documentation in the documentation.

[it-cosmos]

Sorry, I'm developing on debian jessy. It was a bit fast to assume ubuntu working in the same way. I will update the documentation for my part. Here I didn't got the problems mentioned. So I can only document developed and tested on debian jessy and problems/solutions/workarounds with ubuntu could be added by ubuntu tester. But for now I can add already mention the problems mentioned.

[it-cosmos]

Regarding Interrupt handling I thought for now to provide a c-template, implementing empty void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin), which is used in the HAL interface, if the corresponding interrupt line is enabled. But before doing so, I would implement simple Digital GPIO read/write and provide an Blink example for that.

[bernhard-thiele]

Anyway, many times Ubuntu and Debian packages work similarly and it is only some small things that differ. I can test from the Ubuntu side and can complement the documentation where needed.