Get a preview of the latest STM32Cube HAL update for STM32U5 - Page 1
Forum section: electronics / general

author: STM32Talk
author_rank: Newbie
timestamp: August 04, 2025, 01:58:19 pm
content: Hello everyone,I am excited to share a preview of the new STM32 HAL2.To clarify, I work at STMicroelectronics and am part of the team responsible for this update. However, this is my personal account, and the views expressed here are my own. I am sharing this update here to reach the developer community directly and foster open discussions in a more informal and accessible way.At the beginning of July, ST released an early look at the major update to the STM32 HAL, called HAL2. It is shaping up to be a significant upgrade featuring the following:• Smaller code footprint and improved performance.• Enhanced RTOS support.• Cleaner and more useful example projects.Alongside HAL2, ST is launching a new documentation platform for STM32Cube. This preview provides early access to the new HAL2 documentation.For a detailed overview of what is new and what to expect, refer to this article on the ST Community:https://community.st.com/t5/developer-news/get-a-preview-of-the-latest-stm32cube-hal-update-for-stm32u5-on/ba-p/821784If you want to try it out, the preview is available now on GitHub here:https://github.com/STMicroelectronics/STM32CubeU5-V2-PreviewI am available on the ST Community as user:https://community.st.com/t5/user/viewprofilepage/user-id/691, for any questions or discussions, so feel free to reach out there.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 04, 2025, 04:08:14 pm
content: Hi, I personally only use the LL libraries. So my hope is that the new version will not break compatibility for the LL libraries.Otherwise, I can see that there are some changes in how the directories are layed out, but that's easy to figure out.What I noticed is that there aren't any provided example for the LL library so far for the U5, but since it's a preview, that may just be why. Otherwise, I think that could be useful.

author: mark03
author_rank: Frequent Contributor
timestamp: August 04, 2025, 11:02:31 pm
content: I don't understand the attraction of the LL libraries. From what I can see, almost all LL functions consist of modifying the contents of a single peripheral register. That being the case, it's (IMO) cleaner and more readable to access the registers directly using the CMSIS identifiers in stm32____.h, and well understood conventions like ANDing with the complement of a named bitfield, and/or ORing with terms like (new value << some_bitfield_name_Pos), instead of leaning on either LL functions or preprocessor macros like SET_BIT, CLEAR_BIT, MODIFY_BIT. Then you write informative comments above each register-access line of code, explaining what your register accesses are doing.This has the great benefit that code can be written with the Reference Manual open on one screen and your code editor on another, without having to dive into some other cross-reference to find out what the right LL function is called. It is not "more efficient" (I assume a good compiler will remove the function-call overhead of the LL stuff); rather, it is easier to write, and more readable / self-documenting for later maintenance.As to whether HAL2 will be a major improvement over HAL1, I am sorry but I am not optimistic. I am of the strong opinion that the quality of ST's libraries is a function of the quality of the people writing them, moreso than the design goals and constraints. Thus, if the people are of the same quality as the people who produced HAL1, HAL2 will not be substantially more useful, no matter how different the goals are. I mean this as no criticism of the OP specifically, who could very well be a genuis-level software engineer for all we knowNow, if you told me that HAL2 was being developed by a new, crack team of SWEs with twice the average salary, sure, I'd pay attention. But I doubt it.tl;dr: "We cannot solve our problems with the same thinking we used when we created them." ---Albert Einstein (or so the Internet says)

author: uer166
author_rank: Super Contributor
timestamp: August 05, 2025, 12:06:22 am
content: Quote from: mark03 on August 04, 2025, 11:02:31 pmI disagree, LL make the code largely self-documenting regarding what you're setting and what you're doing. It takes care of weird quirks of certain register accesses that may be asymmetric or may have side effects as well. It is true though that to write using LL you need roughly the same amount of background knowledge as if you were doing raw register access, the benefit is purely code cleanliness.

author: mark03
author_rank: Frequent Contributor
timestamp: August 05, 2025, 12:16:15 am
content: Quote from: uer166 on August 05, 2025, 12:06:22 amI think plain CMSIS accesses make the code substantially more readable than LL calls, and you can write the code with fewer documents open in other windows. I will grant that "weird side effects" (apart from basic things like "write 1 to clear") are a corner case where additional abstraction may be desirable. In all cases, though, you are really depending on good comments to explain what the register access intended to do (NOT an English restatement of the literal change you are making to the register). Since most SWEs don't write great comments, if yours don't then that could be a good case for using LL

author: STM32Talk
author_rank: Newbie
timestamp: August 06, 2025, 08:46:07 am
content: HAL2 will now be based on LL, therefore using the LL API when possible. For LL not many big changes, the largest one is that is removal of stm32u5xx_ll_xx.c files, which is mainly the initialization APIs, that does not fit in the LL scope. For the examples you are right, it is simply because it is a preview that focuses on the HAL. The current example list is also a very small subset of what will be available.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: August 06, 2025, 09:14:47 am
content: If you stick with CMSIS then at least you don't have to deal with a new library every 5 or so years.I'm really struggling myself to get a grip on STM32, See also:https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/I'm getting the idea that whatever library you attempt to use, it's not documented / detailed enough, so you end up reading the reference manual anyway. And if you know the registers and the bits you need to accomplish your task, then the HAL or LL is not of much use.That is for the simple things, such as timers, UsART, SPI, I2C etc. For the more complicated things, from setting up the initial clock with PLL synchronization, and USB (Ethernet?) peripherals using a (hopefully decent) library is pretty much mandatory.

author: STM32Talk
author_rank: Newbie
timestamp: August 06, 2025, 12:05:52 pm
content: QuoteHave you had a look at the two set of doc:https://dev.st.com/stm32cube-docs/stm32u5-hal2/2.0.0-beta.1.1/andhttps://dev.st.com/stm32cube-docs/examples/1.0.0-beta.1.0/They are both in early stages, but hopefully can give an idea of where we are going. Does this type of doc match what we might have been missing? Overall the idea is that when you are using HAL for the "simple things" only the HAL doc is needed not RefMan

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 06, 2025, 02:31:58 pm
content: Quote from: STM32Talk on August 06, 2025, 08:46:07 amI'm personally mostly using the _ll_xx.h files, but occasionally a very few of the _ll_xx.c files as there are a few functions that encapsulate some things (yes, mostly initilization) with minimal overhead. The reason is not just laziness, but that those functions do combine writing to the same registers when needed, whereas when using the individual functions in the .h files, there will be several writes to the same registers (that can't be optimized, register writes are always volatile). So, that's not a wonderful move for those using LL.But we can still stick to the latest LL libraries for existing STM32 devices instead of updating to HAL2. At it seems HAL2 is mostly a benefit for those using the HAL.

author: STM32Talk
author_rank: Newbie
timestamp: August 07, 2025, 07:13:09 am
content: It is also important to note that, with the removal of init functions for LL, STM32CubeMX versions that will support HAL2, will be able to generated the initialization for you, without the overhead of the ll init functions today