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?
"Professionals are no longer the key-player of MCU market now."
Don't bet on it. Professionals might not be the key players when companies markets their software. But it's professionals who consumes billions and billions of processors, since each professional is involved in devices that are mass-produced.
There is a reason why the chip manufacturers regularly sends their application engineers and sails forces knocking on the door to try convince us professionals to use - or to continue to use - their specific processors.
"As far as mbed goes... I haven't seen anything that says professional ..." ARM seem to be planning to rejuvenate mbed in the next few months - re-badging it as their contribution to the "Internet Of Things".
https://mbed.org/
"users don't need to know anything about HW/SW" ... I think they do. The problem with HAL and similar half-baked "operating systems" is that engineers have to both learn the hardware and software and inspect / unravel / understand whatever can of worms the third-party software contains.
This is principally an argument about peripheral drivers and getting them to play nicely together. That's a function of how efficiently the design engineer can allocate the micro-controller's resources with appropriate use of counters / timers, interupts, DMA, memory and priorities. It's difficult to do that well when the starting point is someone else's smoke and mirrors. It's unreasonable to expect that there can always be a "general purpose" solution to all designs.
Abstraction comes at a cost. Ultimately, the digital hardware must operate coherently to perform required functions. The further away you get from the minimal set of instructions needed to do that the more power, time and memory you consume. In the extreme, this can lead to projects that outgrow their target processor.
Then Arduino comes, so that many hobbyists use/buy micro-controllers too. The demand increases.
Do you actually believe that Arduino has created a reasonable increase in sold MCU units? You would be surprised.
We are (one of) the local distributor of Arduino. Many buyers are hobbyists, don't know much about HW/SW. So I assume they have created a reasonable increase in sold MCU units. (Do you have any data about this?)
I have some experience in using NXP's new libraries, I discovered that: 1. I don't know how to use the libraries. 2. Oh it works now, but it is so unnecessarily difficult. 3. I don't want to use this kind of libraries. 4. I assume the goal of the libraries are mitigating engineers' workload, but actually it doesn't.
I might be wrong, but a million genuine Arduino units per year is probably too much. The overall MCU market is around 19 000 million shipped units a year.
"There is a reason why the chip manufacturers regularly sends their application engineers and sails forces knocking on the door to try convince us professionals to use - or to continue to use - their specific processors." Interesting spelling error there, trying to write "sales" :)