STM32 and their HAL library

[pyrohaz]

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?

[dannyf]

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.

[pyrohaz]

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.

So do you use the HAL or the std periph library? 

[HackedFridgeMagnet]

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.

[dannyf]

So do you use the HAL or the std periph library?

I have used both: primarily std periph library and try-out on HAL.

[pyrohaz]

So do you use the HAL or the std periph library?

I have used both: primarily std periph library and try-out on HAL.

How 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

[dannyf]

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.

[westfw]

they've moved from the ST standard peripheral library to the ST HAL peripheral library.

Hmmph.  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?

[AndyC_772]

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.

[pyrohaz]

they've moved from the ST standard peripheral library to the ST HAL peripheral library.

Hmmph.  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?

I 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!

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.

It 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.

[dannyf]

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.

[Brutte]

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 (..)

The 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.

[jancumps]

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 (..)

The 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.

That 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.

[westfw]

The whole point of a library idea is that it is maintained separately

Ah, 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.)

[dannyf]

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: [Select]

//set pins to output
//port = GPIOA..x, as the chip may support
void 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_All
GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT; //GPIO_Mode_Out_PP -> push-pull; GPIO_Mode_Out_OD -> open drain
GPIO_InitStruct.GPIO_OType = GPIO_OType_PP; //_PP for push-pull. _OD for open drain
GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; //GPIO_Speed_50Mhz -> 50Mhz; GPIO_Speed_2Mhz -> 2Mhz; GPIO_Speed_10Mhz -> 10Mhz
GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL; //_UP for pull-up, _DOWN for pull-down. _NOPULL for no pull-up or -down
GPIO_Init(port, &GPIO_InitStruct);
}


ST HAL_Lib version

Code: [Select]

//set pins to output
//port = GPIOA..x, as the chip may support
void 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_All
GPIO_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 drain
GPIO_InitStruct.Speed = GPIO_SPEED_HIGH; //GPIO_Speed_50Mhz -> 50Mhz; GPIO_Speed_2Mhz -> 2Mhz; GPIO_Speed_10Mhz -> 10Mhz
GPIO_InitStruct.Pull = GPIO_NOPULL; //_UP for pull-up, _DOWN for pull-down. _NOPULL for no pull-up or -down
HAL_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.

[dannyf]

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

[HackedFridgeMagnet]

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.h

typedef struct
{
  uint32_t ADC_Mode;                      /*!< Configures the ADC to operate in independent or
                                               dual mode.
                                               This parameter can be a value of @ref ADC_mode */

  FunctionalState ADC_ScanConvMode;       /*!< Specifies whether the conversion is performed in
                                               Scan (multichannels) or Single (one channel) mode.
                                               This parameter can be set to ENABLE or DISABLE */

  FunctionalState ADC_ContinuousConvMode; /*!< Specifies whether the conversion is performed in
                                               Continuous or Single mode.
                                               This parameter can be set to ENABLE or DISABLE. */

  uint32_t ADC_ExternalTrigConv;          /*!< Defines the external trigger used to start the analog
                                               to digital conversion of regular channels. This parameter
                                               can be a value of @ref ADC_external_trigger_sources_for_regular_channels_conversion */

  uint32_t ADC_DataAlign;                 /*!< Specifies whether the ADC data alignment is left or right.
                                               This parameter can be a value of @ref ADC_data_align */

  uint8_t ADC_NbrOfChannel;               /*!< Specifies the number of ADC channels that will be converted
                                               using the sequencer for regular channel group.
                                               This parameter must range from 1 to 16. */
}ADC_InitTypeDef;

stm32f0xx_hal_adc.h

typedef struct
{
  uint32_t ClockPrescaler;        /*!< Select ADC clock source (synchronous clock derived from APB clock or asynchronous clock derived from ADC dedicated HSI RC oscillator 14MHz) and clock prescaler.
                                       This parameter can be a value of @ref ADC_ClockPrescaler
                                       Note: In case of usage of the ADC dedicated HSI RC oscillator, it must be preliminarily enabled at RCC top level.
                                       Note: This parameter can be modified only if the ADC is disabled */
  uint32_t Resolution;            /*!< Configures the ADC resolution.
                                       This parameter can be a value of @ref ADC_Resolution */
  uint32_t DataAlign;             /*!< Specifies whether the ADC data  alignment is left or right. 
                                       This parameter can be a value of @ref ADC_data_align */
  uint32_t ScanConvMode;          /*!< Configures the sequencer of regular group.
                                       This parameter can be associated to parameter 'DiscontinuousConvMode' to have main sequence subdivided in successive parts.
                                       Sequencer is automatically enabled if several channels are set (sequencer cannot be disabled, as it can be the case on other STM32 devices):
                                       If only 1 channel is set: Conversion is performed in single mode.
                                       If several channels are set:  Conversions are performed in sequence mode (ranks defined by each channel number: channel 0 fixed on rank 0, channel 1 fixed on rank1, ...).
                                                                     Scan direction can be set to forward (from channel 0 to channel 18) or backward (from channel 18 to channel 0).
                                       This parameter can be a value of @ref ADC_Scan_mode */
  uint32_t EOCSelection;          /*!< Specifies what EOC (End Of Conversion) flag is used for conversion by polling and interruption: end of conversion of each rank or complete sequence.
                                       This parameter can be a value of @ref ADC_EOCSelection. */
  uint32_t LowPowerAutoWait;      /*!< Selects the dynamic low power Auto Delay: new conversion start only when the previous
                                       conversion (for regular group) or previous sequence (for injected group) has been treated by user software.
                                       This feature automatically adapts the speed of ADC to the speed of the system that reads the data. Moreover, this avoids risk of overrun for low frequency applications.
                                       This parameter can be set to ENABLE or DISABLE.
                                       Note: Do not use with interruption or DMA (HAL_ADC_Start_IT(), HAL_ADC_Start_DMA()) since they have to clear immediately the EOC flag to free the IRQ vector sequencer.
                                             Do use with polling: 1. Start conversion with HAL_ADC_Start(), 2. Later on, when conversion data is needed: use HAL_ADC_PollForConversion() to ensure that conversion is completed
                                             and use HAL_ADC_GetValue() to retrieve conversion result and trig another conversion. */
  uint32_t LowPowerAutoPowerOff;  /*!< Selects the auto-off mode: the ADC automatically powers-off after a conversion and automatically wakes-up when a new conversion is triggered (with startup time between trigger and start of sampling).
                                       This feature can be combined with automatic wait mode (parameter 'LowPowerAutoWait').
                                       This parameter can be set to ENABLE or DISABLE.
                                       Note: If enabled, this feature also turns off the ADC dedicated 14 MHz RC oscillator (HSI14) */
  uint32_t ContinuousConvMode;    /*!< Specifies whether the conversion is performed in single mode (one conversion) or continuous mode for regular group,
                                       after the selected trigger occurred (software start or external trigger).
                                       This parameter can be set to ENABLE or DISABLE. */
  uint32_t DiscontinuousConvMode; /*!< Specifies whether the conversions sequence of regular group is performed in Complete-sequence/Discontinuous-sequence (main sequence subdivided in successive parts).
                                       Discontinuous mode is used only if sequencer is enabled (parameter 'ScanConvMode'). If sequencer is disabled, this parameter is discarded.
                                       Discontinuous mode can be enabled only if continuous mode is disabled. If continuous mode is enabled, this parameter setting is discarded.
                                       This parameter can be set to ENABLE or DISABLE
                                       Note: Number of discontinuous ranks increment is fixed to one-by-one. */
  uint32_t ExternalTrigConv;      /*!< Selects the external event used to trigger the conversion start of regular group.
                                       If set to ADC_SOFTWARE_START, external triggers are disabled.
                                       This parameter can be a value of @ref ADC_External_trigger_source_Regular */
  uint32_t ExternalTrigConvEdge;  /*!< Selects the external trigger edge of regular group.
                                       If trigger is set to ADC_SOFTWARE_START, this parameter is discarded.
                                       This parameter can be a value of @ref ADC_External_trigger_edge_Regular */
  uint32_t DMAContinuousRequests; /*!< Specifies whether the DMA requests are performed in one shot mode (DMA transfer stop when number of conversions is reached)
                                       or in Continuous mode (DMA transfer unlimited, whatever number of conversions).
                                       Note: In continuous mode, DMA must be configured in circular mode. Otherwise an overrun will be triggered when DMA buffer maximum pointer is reached.
                                       This parameter can be set to ENABLE or DISABLE. */
  uint32_t Overrun;               /*!< Select the behaviour in case of overrun: data preserved or overwritten
                                       This parameter has an effect on regular group only, including in DMA mode.
                                       This parameter can be a value of @ref ADC_Overrun */
}ADC_InitTypeDef;

[stmdude]

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

[AndyC_772]

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.