24
\$\begingroup\$

So I've been experimenting a while with the STM32F407 (I'm new to ARM) and decided to write a simple app using the HAL libraries since it seems ST has discontinued the Standard Peripherals Libraries. So my question is, what is the point in HAL? Wasn't StdPeriph doing its job? Why would they discontinue it for HAL? To me it looks like HAL is a complete mess.

The documentation is AWFUL, at least for StdPeriph there is a complete reference organized well enough to easily find what you want (http://stm32.kosyak.info/doc/). For HAL there is a crappy PDF (http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf) that has seemingly random structure. Reading any section, for example regarding a peripheral, I can't seem to understand the requirements to configure it and customize it properly. It looks more like personal notes from someone who doesn't want to forget stuff, than a reference.

I know I can use CubeMX to initialize GPIO and configure peripherals, but my aim is to do it myself so I understand better their operation, not have a piece of software do it all for me. Am I doing something wrong? Is it the ARM newbie in me that confuses me? Or is the available documentation THAT bad?

\$\endgroup\$
  • \$\begingroup\$ Would something like ChibiOS oerhaps suit you better? They have an RTOS but also a very good HAL you can use without the RTOS. \$\endgroup\$ – IgorEE Mar 31 '16 at 9:33
  • \$\begingroup\$ ST hasn't exactly discontinued the Standard Peripherals Libraries, but they will not be releasing new versions of it for newer families. They have stated (somewhere on their forum but I can't seem to find it) that they would continue to support the SPL for the families that it has been released for (including STM32F4). Since you're new to ARM, it's probably best to go with HAL. I have a great many modules already written using SPL so the transition will be a pain and I have been putting it off. This is bad since once I decide to use a new family, there will be all the more code to port to HAL \$\endgroup\$ – Tut Mar 31 '16 at 11:24
  • \$\begingroup\$ This ebook: leanpub.com/mastering-stm32 is a good introduction for newbie (but for professional also) to the STM32 world. \$\endgroup\$ – Lorenzo Melato Apr 5 '16 at 16:35
13
\$\begingroup\$

Creating your own libraries is quite simple. Their register spec documentation is pretty good, most if not all of the peripherals are easy to setup. I find it much more painful to use their libraries. but perhaps that is just me. This is true for st, nxp, ti, atmel to name a few (not so much for intel and microchip).

Why do they change libraries, could be any number of reasons, some new boss took over, some division got shut down another took over. Marketing wanted a new image for the product. As ElectronS mentioned, could be an attempt to abstract away from the hardware more to attract users not willing or able to do bare metal. I would go further on that and say they are probably trying to compete with the Arduino phenomenon. Which mbed and everyone else has always tried to do and failed (even before Arduino).

In any case the further away from the hardware it gets the more bloated and slower, so the more you have to spend per unit for rom, ram and mhz. Just so you could spend the same amount of time programming? Just doing it differently?

You say you come from the PIC world, now they did do an okay job with tools, their chip docs were dreadful though, some of the worst. they compensated with libraries and sandboxes.

At the end of the day, try the various options, try the competing products to see how their tools compare. A lot of that you can do for free just to see if it makes sense and you can compile stuff. Maybe even use an instruction set simulator. Find the one that matches for you.

Note, the without canned libraries option is ALWAYS available to you. You are not limited as to what toolchain you can use, what host operating system, what ide, editor, etc. They might stick it to you on programming the parts, if their options are extremely limited in that respect move on to some other chip or vendor if you can.

To sell a chip product like this they have to provide a development environment whether it is all theirs or free stuff they glued together. And they tend to put a library of some kind together. It only has to look just good enough and the blink the led example work just well enough to get either your management or your hardware team to design in their product, then when your board product is tossed over the wall to software, is when the pain does or doesnt arrive. If it almost works but not quite is a big win for the chip vendor as you will now pay for tech support for that last little bit. So it is in their best interest to be almost there but not quite.

The chip vendors only have to look good enough to get the design win. They have to keep improving (? changing) the product to attract new and old customers. So they will have do overs, how far apart and how many prior libraries the continue to support, varies. So just about any library you get used to will go away eventually. So learn to adapt (or dont use their stuff and go your own, which you can support indefinitely). Granted, ideally, you only need to develop the application once per product, make your firmware perfect (good luck if using third party libraries), and you wont need to go back and find a computer that will load their toolchain if you can find a copy of it, and remember how to use that old library. Remember not only should you save your source code, but you should save all of their tools and docs.

Their libraries are only supported on usually one toolchain, under one maybe two IDEs and sometimes only on Windows, and certain versions. Again you have none of those limitations, most definitely not for ARM, if you do your own thing. You can always read any/all of their libraries to see how they do things. But that is often very scary, they dont use their A team developers for libraries, I have extracted a few lines of code to ask interview candidates what is wrong with this code.

to save time and effort both on the silicon side and the software side they very often recycle the same ip, so once you see how the peripheral works on one of their chips it often works the same way on many other of their chips. Yes the clock systems can be tricky with or without their libraries. High chance of bricking the chip, that is where most of my chip/board bricking has happened. Helps to understand how their chips work for example the AVR's, most if not all, can be reprogrammed while the chip is in reset, so any bad code that messes up the pins needed to re-program, or hangs logic needed to reprogrammed, doesnt matter, you can reprogram those chips. Some of these vendors (st is one) has an internal bootloader which you can select using a strap (BOOT0 for example in the st world), you could easily put your own strap in while developing and should whether or not you use a library.

One size fits all fits no-one well. Particularly true for software. So any attempt to abstract away the hardware, just makes it slow and bloated. Might as well get a bigger chip and run linux on it, if that is what you are truly after. A lot of this is as a result of the developers though, not wanting to get their hands dirty, so we have basically asked for this, and they are trying to supply it.

Again, dont lock yourself into st or any one vendor (unless it is too late and management and or the hardware team has stuck it to you, note the stm32 products are nice and easy to use). Shop around. TI is putting a lot of eggs in the cortex-m4 basket. You can do the mbed thing on a number of these arm products as well as the vendor supported solutions.

One thing you can always rely on, is that they will change libraries from time to time and eventually stop supporting the one you got used to.

\$\endgroup\$
  • \$\begingroup\$ Great argument on developing your own libraries , almost convinced and i would like to try that , what do you think i would need other than the the stm32fxx reference manual ? should i also read the arm core manual ? will i be using CMSIS ? how i will access registers and memory ? could you elaborate more or provide example on how to get started \$\endgroup\$ – ElectronS Apr 6 '16 at 7:05
  • \$\begingroup\$ some more things to think about. every line of code adds risk. explaining to your boss that you are planning to use tens to hundreds of thousands of lines of someone elses code, without reviewing every bit of it that you are using. layers of code, esp when abstracting, causes the binaries to be larger and the performance to drop. So again explaining to your boss that the 10million units of product are going to cost an extra 35cents per or 3.5 million dollars because you chose to use a library cause your being lazy. \$\endgroup\$ – old_timer Apr 9 '16 at 18:32
  • \$\begingroup\$ your boss could hire an army of folks to replace you for that kind of money, have every line of code reviewed so that they dont get 10,000 units in and find they have to trash them all over a software bug caused by using risky software. and use a smaller part that costs less at a slower clock rate that uses less power and runs longer on one battery charge. sometimes it is worth the effort. and sure, sometimes not. \$\endgroup\$ – old_timer Apr 9 '16 at 18:34
  • \$\begingroup\$ thanks for the more points you stated , but could you answer my question , on best way to start ? using CMSIS and HAL .h files for register names and memory locations ?? \$\endgroup\$ – ElectronS Apr 11 '16 at 7:05
  • \$\begingroup\$ There is no "best", using that word makes it personal opinion, not fact. Just pick one and start, or do like I might, try one until you hit a road block, then try another, and another, and go around pushing each road block back to the next road block until one or all break through. \$\endgroup\$ – old_timer Apr 11 '16 at 11:07
13
\$\begingroup\$

Let me tell you that a lot of us share the same disappointment you have with HAL libraries , they are indeed poorly and vaguely documented and still new contains many bugs.

So to answer your question why did ST decided on HAL is simple:

  1. They want to create a hardware abstraction layer which in plain English means they want software development and code to be independent of the micro-controller , so if you write a code today for stm32f4 and you need after a couple of years to migrate to stm32f7 it will be easy and code will be highly modular.

  2. This also allows more developers like software programmer to work with the micro-controller without really understanding or going into the deep details of how the hardware is achieving a task. Companies like ST and TI (starting this road now) are trying to make embedded development similar to PC code development where you use high level drivers to develop code FAST. The clumsiness and lack of optimization in their drivers and libraries is compensated by the high performance of the ARM devices.

  3. I think STM32cubeMX is a great tool if you are using HAL libraries , because the most time consuming job is initializing peripherals and now you can do it in a very short time , with visual interface that can be easily changed without affecting the user code ( if you write your code in the appropriate place ) You can use Stm32cubeMx and then review the code and try to understand how and why they are using each function , in this way you are trying to solve an exercise and having solution manual nearby for correction which is great IMO.

  4. ARM core is quiet complex so the old methods we used on 8-bit micro controller like handling registers directly (writing C in assembly fashion) is not feasible , it is time consuming and makes the code hard to maintain due to complex architecture (check the clock setting for example)

\$\endgroup\$
  • 6
    \$\begingroup\$ This is all very understandable, however all these apply to StdPeriph too, don't they? I mean, it already IS a hardware abstraction library, so what's the point in creating a new one instead of improving the old? I'm genuinely curious, I'm very new to ARM, I've been using PICs for many many years. \$\endgroup\$ – John Mar 30 '16 at 23:31
  • \$\begingroup\$ Even more so for the CMSIS compliant libraries \$\endgroup\$ – Scott Seidman Mar 31 '16 at 0:32
  • 1
    \$\begingroup\$ @john , as far as i understand the HAL is more abstractaed and less hardware dependent than standard libraries. \$\endgroup\$ – ElectronS Mar 31 '16 at 10:41
11
\$\begingroup\$

I know this is going to be long and opinionated but as we've just (successfully) released our new product using the HAL, I think it is worth being considered. Also, I don't work for ST, I have hated every bit of the HAL, almost restarted the project with StdPeriph, I have felt the pain - but now I understand why.

First, a bit of background. We develop ultra low power telemetry systems, and our product is powered by an STM32L1. When we started working on the firmware, we had the usual choices for (bare metal) ST devices: do everything by hand, use the StdPeriph libraries, or go with the HAL. The ST guys convinced us to go with the HAL - so we did. It was painful, we had to work around bugs in the software (the I2C part drove us crazy for quite some time) and I still dislike the overall architecture. But it works.

When I switched from desktop to embedded, a bit more than a year ago, I was stunned by something strange I couldn't name or even grasp. Over time I was able to understand what was - or rather, what is - going on: the embedded world is in transition. Silicon gets cheaper everyday and MCUs are more powerful and versatile. More and more devices, regardless of their size, power needs, rely on generic MCUs. More and more companies join the game, bringing in a horde of new developers with various backgrounds. The "mean" culture drifts away from the traditional "EE guy with programming wizardry skills" to "SW guy with vague hardware knowledge".

Whether this is good or bad is irrelevant. It just happens. Actually, it also happened to the software world, more than once. The web boom in 2000 attracted PHP/MySQL newbies - go tell them there are registers in the CPU, they will answer "I'm using Linux, so there is no Registry in my OS". Earlier, multi-user OSes running in protected mode allowed lazy developers to never set up an ISR in their entire career and be fine. Even earlier, keyboards and screen made card punchers and printer manufacturers go crazy.

And yes, the current trends make me personally sad, as I see ignorant developers in awe with the latest shiny techs, while being totally unable to link them with history. When I see a younger me coding a game in Javascript with WebGL in 2015, I want to shout "There is nothing new! I did the same with C++ and the 3Dfx SDK back in 1995!". What the story doesn't tell is that his game runs on my mobile phone, whereas mine needed a gamer PC (and an installer, and I couldn't push updates by the web). The truth is, he could develop is game in one month, where I did the same in six, or twelve.

Obviously, neither ST or TI or Intel or whoever manufactures chips wants to miss the turn. And they are right. The HAL is ST's response, and is actually quite sound, not only on the business or marketing side, but on the engineering side as well. The reason why it is sound lies in the name:

Hardware Abstraction Layer

If anything else, this is what you should remember. The HAL is an effort to move away from the hardware. It is good engineering because it allows us to decouple the functionality from the details. Layering is what allows to develop complex programs - one abstraction on top of another, down to the hardware. Abstraction is actually the most powerful tool we have to manage complexity. I very much doubt anyone on this planet would be able to program a web browser in assembly for a specific CPU.

The cultural shift is indeed hard to digest, but as I have to reckon one does not need to have read Knuth's Art of Computer Programming to develop web applications, the EE world must admit there are newcomers that can (and will!) develop embedded code without having read the Fucking Holy Reference Manual.

The good news is new players doesn't mean less work for older players - quite the opposite, IMHO. Who are they going to call when things "don't work?". If you have RTFM (unlike them), and if you know what each bit of this obscure configuration register do, you have an advantage.

Between your readings and experiments, just go with the HAL. New MCU? No problem. New MCU line? No problem as well (I coded a test on a STM32F4 Nucleo in just a day with CubeMX, and then simply ported it to our device ... it just felt right). Mocking for unit tests? No problem. The list goes on and on, because abstraction is good.

Of course, the HAL itself is not 100% OK. It's documentation is awful (but you have RTFHRM, didn't you?), there are bugs, ST just dumped a beta version at us (seems pretty standard these days) and their public support is a joke. But not releasing the HAL would have been even worse.

\$\endgroup\$
  • \$\begingroup\$ I see where you're coming from. As I understand, things (unfortunately) go the Arduino way, trying to hide as much of the reality from the programmer to lure more high level software people into hardware programming, and this is the reason behind such libraries as HAL. Seeing however how badly documented it is and a complete mess too, I don't think they will succeed in doing so anytime soon. \$\endgroup\$ – John Apr 3 '16 at 0:25
  • \$\begingroup\$ @John: HAL doesn't hide any "reality". Everything is there for you to tweak. All parts are optional - e.g. you may want to use only the macros to access the registers, or only a specific driver (e.g. I2C) or everything including ISRs and clock config. Your choice. However, I agree the documentation sucks a lot. (I've told ST and they promised they were working on it BTW) \$\endgroup\$ – Tibo Apr 4 '16 at 7:24
  • \$\begingroup\$ We are repeating doing the same with new tools. Because new tools promise to make the job easier and faster thus cost efficient. But we are still doing the same, because human beings are still the same, no matter if it was 2095 or 1995. The choice leave to us is if we follow the new tools or stay with our already familiar tools. \$\endgroup\$ – Jony Oct 26 '17 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.