Makefile structure for stmhal

[marfis]

On the wiki page http://libopencm3.org/wiki/Licensing they say:

While esden and others have indicated that they consider linking with libopencm3 to _not_ require the linked application to become lgpl, the lack of an explicit linking exception bothers a few people.

So as far as I understand, that's a grey area and an explicit linking exception is preferred. As it looks on that page, most developers of the library agree with an exception but they did not yet change the licensing. Oh well..

Such a shame they haven't released it under MIT...

[Damien]

What do people think about STM's HAL code quality?
...
What are peoples opinion about that issue?

Yes ST Cube HAL is a bit bloated, but I think it's quite consistent across peripherals and not too hard to use. There is a bit of mucking about to get some things going, but I think that's because the MCU is powerful and has lots of options that need configuring, not because the HAL is badly designed.

If you personally go down the path of using something other than Cube then you will find a lot more work than just changing the mp_hal_xxx functions. You also need to revisit all the peripheral drivers (uart, spi, i2c, etc) and make them work with the new HAL. I'd say it's easier for you to just use stmhal and spend the time working with Cube. Then you'll benefit immediately from all changes made to stmhal by other devs (and you can contribute easily too!).

The benefit of using Cube is that it's pretty easy to support another MCU series (eg L0, F7) because ST has done all the hard work of writing the HAL. @dyhalnds now has the F7 working with USB serial and MSD and there was not much to it in the end (ie not much code change). libopencm3 is yet to support the F7.

[marfis]

Then you'll benefit immediately from all changes made to stmhal by other devs (and you can contribute easily too!).

Yes I see that point.

@dhylands now has the F7 working with USB serial and MSD and there was not much to it in the end (ie not much code change). libopencm3 is yet to support the F7.

Yes thanks for that, I looked trough it and it seems to solve some of the problems I've encountered. For example the file name of the include statement for the main hal file that is dependent on the MCU type. Oh well cube

The commit does introduce "M7" compiler switches... Lets hope that adding other MCU series will not significantly flood the code with more #ifdefs, especially if more of the peripheral functions are supported.