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?
Yikes on the responsiveness here, considering the retail Keil costs and all.
The answer is that if you want to use the Keil RTE packages, RTX, and middleware, you're limited currently.
The F1/F3 chips currently DO NOT support STM32Cube HAL inside of Keil. You could of course build the project in STM32CubeMX app and then import into Keil, but then adding the extras inside the RTE will go poorly most likely. The Standard Peripheral Lib is still supported inside of Keil. As a further note, you currently need to roll back the versions in order to use middleware with the F1 and F3 chips (app note 622 iirc).
The F2/F4 DO support the STM32CubeMX / HAL library which replaces the Standard Peripheral Library. The CubeMX application isn't needed, but can still be used to set up clock or pin layout. The new middleware works with latest packages.
STM and Keil are apparently working this out and maybe it'll be resolved by Q32015. This puts me in a slight bind as I want to start development now, use RTX and the middleware, and also use an F1/F3 chip. So whatever I write now, MAY need to be updated later when the RTE packages are updated to support all of the STM32 parts in the same way. Such is life.
I also have the option of switching to the F2/F4 chips for my projects, but the F1 and F3 are better suited for my particular applications I have in the pipe. Just cheaper and lower pin counts still with great peripherals.
"Yikes on the responsiveness here, considering the retail Keil costs and all."
This is an end user forum. Just because we pay a lot of licensing fees for the Keil software doesn't mean we are then obliged to spend time helping others...
Anyone wanting official Keil support can find support links at the top and bottom of every web page.
Jay, I share your frustration to some extend. Also I would like that the development goes faster. However catching up with all the new HAL and device structure is challenging.
Maybe there is a pragmatic solution as the drivers are not so different across the various devices. What middleware are you trying to use? Which peripheral channel should be used?
Reinhard,
I'll be using immediately I'll be using RTX, USB Device, USB Host, File System. By the end of the year I have plans to implement the full Webserver, and that will be over wifi so likely the TCP/PPP/etc stacks, all of that I have zero experience with. About the only thing I have no plan for is GUI/LCD, but even then I can imagine a scenario where those could pop up in the future.
Part of the reason for choosing Keil Pro was the middleware. Which so far is working well. It's just that I'm at this split between F2/F4 chips being updated but not suiting my intended designs as well as the F1/F3 chips which are still using "last gen" libs and drivers.
What I don't really is why. It seems to me the F2 and F4 being Cortex M3/M4 are so closely related to the F1/F3 which are also Cortex M3/M4. I'm honestly not sure what would be different!
I've already purchased some STM32 third party stacks (CAN and some others) for something else, so I'm locked in to STM32Fx for now. I'll just roll along with the standard peripheral lib and the older middleware for now on my initial projects. Using an RTOS/RTX it doesn't seem like it could be all that bad to update from Std to Hal, just need to keep in mind that I'll be ripping out a lot of the SFR and GPIO calls, all my actual code logic should remain.
I saw an open source attempt to standardize calls across different ARM devices. OpenlibCM3 or so, but I'm uninterested in trying to incorporate into Keil with working middleware that as again, I'll be sticking with STM32 exclusively for now.
I've used both NXP and ST ARM microcontrollers. I found ST's Standard Peripheral Library a useful foundation and was able to integrate it with Keil middleware without much trouble.
Now we have the HAL / CUBE as well as ARM's mbed and the Keil MDK seems to have hitched its wagon to the ST HAL mess (For STM32 at least). Why is that happening when Keil is an ARM company and ARM is planning to release new improved mbed upon an unsuspecting world?
I chose to use ARM Cortex microcontrollers because I was attracted by the processing power and the CMSIS software ... especially the DSP functions.
I don't want to program everything at register level but I also don't want the overhead and obfuscation of the HAL implementation.
An in particular, if I've paid for Keil middleware, I don't want to have it contaminated with calls to HAL.
Rowley CrossWorks seems to be one of the only self-contained software eco-systems left.
It's hard to know what mix of software tools / middleware to choose - none really appeal.
Someone (Reinhard ?) - tell me there's hope for the future ...
Too late for me to change anything, but I appreciate the comments.
"An in particular, if I've paid for Keil middleware, I don't want to have it contaminated with calls to HAL."... Yea. I'm with you there. It would be nice to keep Keil separate from STM if possible.
As far as mbed goes... I haven't seen anything that says professional, I see hobbyist all over it.
The most annoying thing I've found, is that the F1/F3 are still using std peripheral in Keil with 5.xx middleware, and the F2/F4 are using the Cube/HAL at 6.xx middleware. It's just down right dumb to partially support it. This is an instance I'd say all or nothing.
As to why ARM chose to go with STM's HAL... I don't know I'm sure people smarter than myself are making those calls.
They are smart. Originally, only professionals use/buy micro-controllers. Then Arduino comes, so that many hobbyists use/buy micro-controllers too. The demand increases. mbed wants to be another Arduino. Every micro-controller manufacturers (except the Japanese) want to go the Arduino way. So micro-controller manufacturers create HAL libraries for everyone to develop, users don't need to know anything about HW/SW. After professionals and hobbyists, now they want Javascript programmer to use/buy micro-controllers, so the Javascript based micro-controllers interface comes, and IoT concept is so hot. They just want the demand increases.
Professionals are no longer the key-player of MCU market now.
"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" :)