This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Options for STM32 GPIO. Keil's version, StdLib, CubeMX/HAL?

So... I'm new to this, go easy on me.

It seems to me I have four options for working with the STM32 inside of Keil.

1. Code all the pin interactions myself. This is probably dumb as it's an unnecessary duplication of work.

2. Use the Run Time Environment selector to chose GPIO or other options. This gives me Keil's code that appears for my device to have last been updated in 2013. Some curious things are missing from GPIO in particular. Mainly the ClockSpeeds are defined in the header but never used in the few C functions. I appears they would like me to use mostly pointer access into each GPIO. Things like UART are tied to the RTX OS, so the only way to use them is to also use RTX. This is not a "bad" necessarily, just something I'm aware of. If I had a project that I wanted a superloop, I could not use this option for defining out the whole chip.

3. Use the STM32 Standard Library. I would for-go selecting components like GPIO or DMA in the Keil new project configuration page. Try and add entire STM32 sources/headers. These seem to have been last updated in 2011 by STM. The last time I tried this with Rowley, I had a lot of assert_param() errors, never really figured out why it didn't like that. I'm slightly concerned about using Keil's startup files and the standard lib. GPIO access uses the structures common to the standard lib.

4. Use STM32 CubeMX. This lets me define names for the pins and parameters, but I'm concerned about integration into RTX, clocks, configuration pages, etc. I've also read just about nothing good regarding this HAL. Most of what I read is from 2011/2012/2013 so I don't know if it's gotten any better. Most people seem to prefer the older standard libs and would rather use CubeMX as just a handy visual aid for laying out pins.

Thoughts?

0