Posted on July 18, 2016 at 19:19I tried it out a bit for the F0.
Played the basics with LEDs and buttons and then tried to adapt a portion of code I made for a I2C IMU (yes starting with I2C in a STM32...). The tiny API is made so there is a driver part you must fill in, then just use the''methods'' (well it's not a class) which call the low level driver functions.
Well after trying out what the package has, both HAL and LL I must say I liked a lot the LL because it's very similar to a API I use for another ARM. It was much easier to adapt how I wanted it.
Now let's try again with HAL. Confusion settles. As of now my conclusion (probably not the right word but let's roll with it) is that:
1st case: you want to use the MX generator to keep changing peripheral configs.
You have a problem with the HAL_I2C_MspInit (or other equivalent functions for other peripherals). Like, your API can't handle the I2C config at all if you don't use the MX to set up the I2C - if you customize the HAL_I2C_MspInit yourself then next time you use MX again your custom code is gone (or is it? Can you add macros to keep it?).
Anyhow you are adding your config to a file from the library not the files of your API
2nd case: Use MX to just generate the initial project. I like this one actually. Like the emptiest project, just config the workspace for me (well then why not just use a template?)
3rd case: Use the LL or register level programming. Apparently you lose portability? So... what's the point of this? Is the LL much more optimized than it's better than the SPL (so far I liked it more in terms of how you use it but that's arguing one of the least important points)
