STM32 and their HAL library - Page 1
Forum section: electronics / general

author: pyrohaz
author_rank: Regular Contributor
timestamp: December 17, 2014, 09:12:24 pm
content: Hi All,I've used CoIDE with the STM32F0 variety of chips for the past year or two now and they've recently released their new beta version of the software. I've decided to give it a download and have a look. Apart from it being slow and clunky - as I'd expect from a beta version, they've moved from the ST standard peripheral library to the ST HAL peripheral library.Now I've spend the past year or so getting acquainted with the standard peripheral library and I've grown to like it. For them to now throw a completely new HAL library in there, I'm a little annoyed though I'm not sure who at, either myself at not wanting to learn the new library or at ST for not doing this from the beginning.Should I take it on the chin and just learn the HAL version or could I just carry on as I am sat in the happy works of the standard peripheral library?

author: dannyf
author_rank: Super Contributor
timestamp: December 17, 2014, 10:05:17 pm
content: It has not been a problem for me, mostly because I have no need to upgrade.I did try out and found it to be a minor issue for me: all my code relies on a middle layer, through which I call routines in the st library. I have duplicated the GPIO / NVIC / Timer routines to HAL so I think if I have to migrate my code base, it is not going to be a big deal for me.

author: pyrohaz
author_rank: Regular Contributor
timestamp: December 17, 2014, 11:07:33 pm
content: Quote from: dannyf on December 17, 2014, 10:05:17 pmSo do you use the HAL or the std periph library?

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: December 17, 2014, 11:21:07 pm
content: I have started a project using the HAL, it but so far have only integrated the core stuff + watchdog, adc, pwm. It was a bit of a pain getting the clocks sorted out as the sample code was either for different families or for the old libraries.Also clive1 the guru on st forums didn't seem to like the HAL and pointed out that people didn't seem to be using it in at least one post.I would go with HAL because as a general principle I try to keep up to date with changes in libraries and other technology.

author: dannyf
author_rank: Super Contributor
timestamp: December 17, 2014, 11:33:36 pm
content: QuoteI have used both: primarily std periph library and try-out on HAL.

author: pyrohaz
author_rank: Regular Contributor
timestamp: December 17, 2014, 11:59:11 pm
content: Quote from: dannyf on December 17, 2014, 11:33:36 pmHow did you find the changeover? Am I just doing it completely wrong? Is there any material that you used to get more acquainted with the HAL because I agree with HackedFridgeMagnet that realistically, to stay ontop of the software, I should learn soon rather than later

author: dannyf
author_rank: Super Contributor
timestamp: December 18, 2014, 12:05:43 am
content: I am not in favor of it - due probably to my tendency to be a technology laggard - I don't use anything new unless I have to. And for chips I use, there is no need to go to the latest and the greatest.

author: westfw
author_rank: Super Contributor
timestamp: December 18, 2014, 06:29:48 am
content: QuoteHmmph. I managed to see "Cube" without realizing that the "HAL" they referred to was something different than the "standard peripheral library." Is there a comparison document somewhere? Are they still providing source code for the new HAL? Having access to the source was one of the (few?) good parts of the old libraries."Standard" libraries that become obsolete every couple of years in favor of something new are pretty sucky.Perhaps the original peripheral library was supposed to be somewhat CMSIS-compliant, and they switched when HAL for peripherals was dropped from CMSIS?

author: AndyC_772
author_rank: Super Contributor
timestamp: December 18, 2014, 12:06:30 pm
content: IMHO the ST libraries have always been more of an obfuscation layer between the code and the underlying hardware. You still need to know how the hardware works, and exactly how it must be programmed.The whole point of having a library is to aid in portability and future-proofing. One whose interface changes so completely defeats the whole purpose of its existence.It's easier, faster, more readable, more compact and more future-proof just to use the #define'd names for the registers, and poke them directly... IMHO, of course.

author: pyrohaz
author_rank: Regular Contributor
timestamp: December 18, 2014, 04:38:41 pm
content: Quote from: westfw on December 18, 2014, 06:29:48 amI can't seem to find a way within CoIDE to use the standard peripheral library but it seems that the HAL is essentially another layer equivalent to the std periph library of what code I've read anyway! I agree with the libraries becoming obsolete. I'm happy using the old std peripheral libraries, the problem comes however when these libraries no long map to ST hardware!Quote from: AndyC_772 on December 18, 2014, 12:06:30 pmIt definitely is a hardware obfuscation layer though a useful one as I can program without having to refer to the reference manual every time I want to check a setting! Maybe I'm missing the point of the HAL library here? It would be nice for the HAL and Std periph library to develop side by side for each user.

author: dannyf
author_rank: Super Contributor
timestamp: December 18, 2014, 05:20:04 pm
content: Incorporating st libraries (or any libraries) into a project is fairly simple: you need to copy the source files (.c/.h) into the project folder, include the .c files and set the include path to the .h files, in addition to setting up any applicable switches / macros.After that, hit compile / build and you are done. For the older CoIDE, that's all done by the IDE for you.Or in the case of a pre-compiled library, you need to set the include path to the .h files and in the linker section include the compiled library.In the case of those HAL libraries, they are very much similar to the old st names, starting with HAL_. Porting is not difficult.What troubles me is that ST never articulated why they are abandoning the st libraries and what benefits people could expect from the new HAL libraries.Without understanding that, the users are left wondering if this is going to be another code item.I certainly wouldn't switch unless I have to.

author: Brutte
author_rank: Frequent Contributor
timestamp: December 18, 2014, 07:21:01 pm
content: Quote from: dannyf on December 18, 2014, 05:20:04 pmThe whole point of a library idea is that it is maintained separately and only linked (here statically) with your firmware at the very last stage.

author: jancumps
author_rank: Unknown
timestamp: December 18, 2014, 07:43:26 pm
content: Quote from: Brutte on December 18, 2014, 07:21:01 pmThat depends on what incarnation of the word library you are talking about.the term is used for a compiled 'lib', but also for a set of functions, an API.In that case it can be source files.

author: westfw
author_rank: Super Contributor
timestamp: December 19, 2014, 03:49:19 am
content: QuoteAh, but a wholesale copy of the library source into your project is a good idea from a "revision control" point of view.Copying the source of a library into a read-mostly copy for each project is one of the better uses of the current "available disk space is nearly infinite" state-of-the-world that I've seen. (although it still offends my old-time sensibilities.)(Trying to recompile/use old source code, when all the libraries it is dependent on have changed subtly, really sucks.)

author: dannyf
author_rank: Super Contributor
timestamp: December 19, 2014, 10:46:11 pm
content: To give you some sense as to how similar the two are, here is a piece of code that I use to turn a pin to push-pull output.ST Periph_Lib version:Code://set pins to output//port = GPIOA..x, as the chip may supportvoid PIN_OUTPP(GPIO_TypeDef* port, uint16_t pins) {GPIO_InitTypeDef GPIO_InitStruct;/* Configure PC8 and PC9 in output pushpull mode */GPIO_InitStruct.GPIO_Pin = pins;//GPIO_Pin_0..15 + GPIO_Pin_AllGPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT;//GPIO_Mode_Out_PP -> push-pull; GPIO_Mode_Out_OD -> open drainGPIO_InitStruct.GPIO_OType = GPIO_OType_PP;//_PP for push-pull. _OD for open drainGPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;//GPIO_Speed_50Mhz -> 50Mhz; GPIO_Speed_2Mhz -> 2Mhz; GPIO_Speed_10Mhz -> 10MhzGPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL;//_UP for pull-up, _DOWN for pull-down. _NOPULL for no pull-up or -downGPIO_Init(port, &GPIO_InitStruct);}ST HAL_Lib versionCode://set pins to output//port = GPIOA..x, as the chip may supportvoid PIN_OUTPP(GPIO_TypeDef* port, uint16_t pins) {GPIO_InitTypeDef GPIO_InitStruct;/* Configure PC8 and PC9 in output pushpull mode */GPIO_InitStruct.Pin = pins;//GPIO_Pin_0..15 + GPIO_Pin_AllGPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;//GPIO_Mode_Out_PP -> push-pull; GPIO_Mode_Out_OD -> open drain//GPIO_InitStruct.OType = GPIO_OType_PP;//_PP for push-pull. _OD for open drainGPIO_InitStruct.Speed = GPIO_SPEED_HIGH;//GPIO_Speed_50Mhz -> 50Mhz; GPIO_Speed_2Mhz -> 2Mhz; GPIO_Speed_10Mhz -> 10MhzGPIO_InitStruct.Pull = GPIO_NOPULL;//_UP for pull-up, _DOWN for pull-down. _NOPULL for no pull-up or -downHAL_GPIO_Init(port, &GPIO_InitStruct);}The changes are silly in that ST could have easily retained the old naming convention, or better yet, have to thought through earlier and used the same convention across all of its chips. If anything fails, they could have used a file to maintain compatability with the old code.But as all of my code pieces are built on the middle layer, on routines like PIN_OUTPP(), there is no change to my user code, once the middle layer has been ported over to HAL_Lib.However small, that's not an investment I want to make now.

author: dannyf
author_rank: Super Contributor
timestamp: December 19, 2014, 10:50:02 pm
content: As to CoIDE v2, I think you may have found this out yourself as well, it is not for prime time, yet.I wouldn't jump onto it. Before they get better, I continue to use my trusty old CoIDE v1.7

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: December 19, 2014, 11:14:12 pm
content: Here is another comparison, with just what I had to hand. Obviously some of the changes could be due to the different chips.First is stm32f1 old libs. Next is stm32f0 new libs.stm32f10x_adc.hQuotestm32f0xx_hal_adc.hQuote

author: stmdude
author_rank: Frequent Contributor
timestamp: October 23, 2015, 07:21:06 am
content: Thread necromancy, but relevant (I hope).I bit the bullet a few months ago, and did a few new projects from scratch using CubeMX and the new HAL.At first, it's quite a pleasant experience actually. Using CubeMX to figure out the perfect STM chip for the project is very nice, and pin-selection for the various AFs is very pleasant. Gone is the days of using the datasheets for figuring out pin-assignments.The ease-of-use here even lead to slightly better PCB layouts, as I could play around a bit with the pin-assignments during layouting to get it more efficient.As for the HAL, it's a learning-curve, and once you figure out that the actual documentation is at the top of the .c files (not .h), it's pretty straight-forward.HOWEVER... In my opinion, the HAL is far from production ready. I keep running into missing functionality when I go beyond the very basic stuff, and downright nasty bugs.The two very obvious examples that comes to mind is implementing an i2c slave (as in, the stm32 acts as a slave). To my surprise, the HAL doesn't have a mechanism to do to this, nor to manually do i2c re-starts. Had to bang the registers directly for that.The other example is implementing an multi-channel ADC with DMA transfers. This is fairly simple to do with the HAL, especially after CubeMX generated all the setup code for it. And, it actually works. Problem is... It only works _once_. If you reset the cpu-core (as in, hot reboot), the HAL doesn't reset/initialize the ADCs correctly, and it stops working. Power-cycle, and it works again. Once..Power-management is also a bit of a hassle using the HAL.Now, while I still occasionally use the HAL for quick and simple tests and proof-of-concepts, everything that goes beyond that uses StdPeriph, at least in my shop (and by extension, my workplace, as I get to make those decisions there.).However, I still use CubeMX all the time. Just not the code it spits out./J

author: AndyC_772
author_rank: Super Contributor
timestamp: October 23, 2015, 08:11:31 am
content: Agreed, CubeMX is a perfectly good tool for working out what a device's pinout might be, and which combinations of peripherals are usable at the same time. I use it to work out clock configurations too; the interactive block diagram of the clock tree is excellent.I don't think I'll ever use the actual code again, though. Just the headers.