STM32

[SiliconWizard]

Well nothing other than a Nucleo-F091RC although if I do use STM32 it would be nice to figure out how to work with the HAL

As I've said in other threads, if you're going to use the HAL, start with looking at all the example projects that come with the download instead of fiddling with the Cube app first. They are categorized by peripheral/functionality.

I know many despise STM32's HAL, but I think it's actually not that bad especially when you're starting with STM32 MCUs, and I've done a few useful things with it. All the source code is provided, so you can look at how things are implemented.

[Simon]

Well i was put back onto the idea of STM by a subcontractor work use who first told me about all their ballsups of the past but now says that it has matured into a usable solution. The last thing i want for example is that I write a project and them update the HAL and find that names of things have changed and my code stops working.

[SiliconWizard]

The last thing i want for example is that I write a project and them update the HAL and find that names of things have changed and my code stops working.

I have never seen that happen with the HAL, usually STM is pretty cautious about not breaking things like that. So you may find the HAL "bloated" (the code size is not tiny indeed), but it seems decently maintained. (Now bear in mind I've mostly used the L4 series so I can only talk for the HAL for L4, but I think it's pretty similar across series...)

[Simon]

I think it was some time ago but I think there have been situations where a chip is made with one UART, so all registers are called UART. then they want to put more uarts on so it becomes UART0 and the code breaks.

[Berni]

Well it is pretty difficult to make a universal peripheral library work across all chips. New chips keep coming out that might do something in a slightly different way that the existing library is not made for and so it needs changing.

Some things are actually done pretty well in HAL, like having functions with the word IT in front for things that are interrupt driven so you can clearly see what to use. It provides built in mutexes and locks to prevent problems with multithreading and interrupts. Even sets up DMA for you if you use appropriate functions.

But then there are a lot of little things that make me facepalm. Like flipping a GPIO pin between input and output requires you to allocate a whole gpio pin init structure, fill that structure and then pass it in to the init function to have your pin reconfigured. Some peripherals also hold on to this init structure in RAM as part of the hal peripheral struct that holds the state of the peripheral. While i do applaud them for using simply a C struct to store this (Rather than making a C++ class for the same thing) that init structure can sometimes be over a kilobyte in size and has no use anymore after the init function finishes setting up the peripheral according to your wishes. I would much prefer the init would only do the very basic things to get the peripheral running and then have you call separate things like HAL_GPIO_SetMode(GPIOC, 10, GPIO_INPUT_PULLUP)

Then there are things where the HAL library is built to work well with a very specific use case in mind, yet this use case is something really niche and rare, while the most common use case is not supported at all. One such thing is you can ask to receive a certain number of characters from UART, depending on how you call it you can have the function wait as a blocking call, interrupt you or DMA them somewhere, notifying you when done and stopping receiving. This is great if you expect exactly 10 characters to arrive just after this call. But if you want to constantly receive? Well you could always keep asking for 1 character but the UART stops receiving when its done with 1 character and only starts receiving again once you call the receive function again so you will loose any characters that arrive in that time. Are you kidding me?!

Then you get things that are implemented without any thought as to there use case at all. Like having I2C with DMA. Sounds great since I2C is awfully slow so you don't want to wait around for data. Well turns out this is only really useful if you want to transfer a big block read of data as it will only do one operation at a time. It won't let you automate the usual I2C dance that happens before the read transfer (Adress the slave, write to address, restart, adress slave, read, get data...). My solution was about a 100 line long function that takes in a structure of instructions for the I2C to do and executes them in interrupts by direct poking of bits in hardware registers. Works great and will read data from multiple I2C chips, doing it from a single function call all in the background. Versus the many thousands of lines of code of that crappy HAL I2C library.

All feels like the HAL library was written by a bunch of high level programmers used to writing C code for Windows, following a checklist of implementing something for every peripheral in blocking, interrupt and DMA mode before moving on. None of those programmers having actually used any MCU peripheral libraries, having no idea what embeded programmers actually want a device driver to look like.

Still HAL is a great way of getting something up and running quickly and to get you familiar with the peripheral. Then you can slowly rewrite parts of the HAL library to actually do it in a proper way.

[Simon]

All feels like the HAL library was written by a bunch of high level programmers used to writing C code for Windows, following a checklist of implementing something for every peripheral in blocking, interrupt and DMA mode before moving on. None of those programmers having actually used any MCU peripheral libraries, having no idea what embeded programmers actually want a device driver to look like.

Well lets face it embeded programming seems to be a niche. Few books on it, no courses. I guess it's the programmers trying to do electronics by using an arduino all over again

[Jeroen3]

The last thing i want for example is that I write a project and them update the HAL and find that names of things have changed and my code stops working.

I have never seen that happen with the HAL, usually STM is pretty cautious about not breaking things like that. So you may find the HAL "bloated" (the code size is not tiny indeed), but it seems decently maintained. (Now bear in mind I've mostly used the L4 series so I can only talk for the HAL for L4, but I think it's pretty similar across series...)

You're right. Before HAL I had a different name. StdPeriph.

All feels like the HAL library was written by a bunch of high level programmers used to writing C code for Windows, following a checklist of implementing something for every peripheral in blocking, interrupt and DMA mode before moving on. None of those programmers having actually used any MCU peripheral libraries, having no idea what embeded programmers actually want a device driver to look like.

Well lets face it embeded programming seems to be a niche. Few books on it, no courses. I guess it's the programmers trying to do electronics by using an arduino all over again

There is nothing wrong with trying to get some abstraction. Especially since embedded processors are getting more and more capable.
The design of HAL is broken, it should have been C++, but that wasn't economically viable since the world still uses C. So they went with the device driver model, but they can't separate kernel from userspace, so it became what it is today. Redundant abstraction.
The best part is the sample code generator and IO and clock tree.

[Simon]

I have set up a simple project with CAN and GPIO enabled in the Cube IDE using the HAL. So just looking at the only header file i can find for the GPIO things are not clearly explained. I can see the gist of things but nothing is explicitly explained. I take it that in declaring a function that has no parameters leaving the parenthesis out is OK? if so that explains one small thing i was not expecting to see. I get the impressions that to understand this clearly i will need to thoroughly understand the registers anyway at which point why was I using the HAL again? Am i missing some documentation somewhere?

[Jeroen3]

Well yes, as I said before. The HAL is redundant abstraction. You still need to know about the specific functions of each pin. The only thing the HAL does it put the choices into drop-down menus and give your some limited feedback of illegal options.

[Simon]

what drop down menu? I can scarcely see what the functions are that i should write to enact any of the code. If this header file that I have found is the "public interface" then it is bloody awful as it carries no documentation at all. All that I have read in several books is that the c file is "private" and the header file will expose what is "publicly" available to be used in the application and is to have any documentation.

Going by that I have nothing and would find it faster to just read the manual and write my own driver thanks. Is the rest of it that useless?

[Karel]

All that I have read in several books is that the c file is "private" and the header file will expose what is "publicly" available to be used in the application and is to have any documentation.

Formally you are correct. And with closed-source software that comes as libraries and headerfiles, this is usually the case.
With open-source software however, documentation can be found often in the comments in the *.c files.

[Simon]

OK, I will give that a read but it still does not make sense because i don't care to read a load of code i am not interested in. I just need to know how to drive it. Even the couple of libraries I wrote for myself although I documented the how it works in the C file for my own sanity to avoid confusion I explained clearly in the header file how to use it. It's also how C works. Variables that are internal to the library stay in the C file but variables that are global allowing the library to interact with an application were declared in the header so that there was no confusion about which was which.

[ataradov]

What you are finding for the N-th time is that vendor supplied code sucks. It always does. What you need to decide is the level of suckiness you are willing to accept.

You will always have to read the code to understand. Writing code and documentation is a cost center, which directly contributes to the final price of the product. And in a world where you sort by price on Digi-Key, it is unrealistic to expect vendor to put more effort than bare minimum required.

[Jeroen3]

what drop down menu? I can scarcely see what the functions are that i should write to enact any of the code. If this header file that I have found is the "public interface" then it is bloody awful as it carries no documentation at all. All that I have read in several books is that the c file is "private" and the header file will expose what is "publicly" available to be used in the application and is to have any documentation.

The drop down menus in the STM32CubeMX java application of course!

Are you working with a proper editor? Go use Visual Studio Code and use that Go to Defintion button (F12)

[Simon]

What you are finding for the N-th time is that vendor supplied code sucks. It always does. What you need to decide is the level of suckiness you are willing to accept.

You will always have to read the code to understand. Writing code and documentation is a cost center, which directly contributes to the final price of the product. And in a world where you sort by price on Digi-Key, it is unrealistic to expect vendor to put more effort than bare minimum required.

Well I'm trying to understand it and see if I am happy using the HAL. If the GPIO is relatively well documented in the C file and there are more comments there than in the header file then perhaps I am happy with this level of suckiness. I am just trying to work out if the HAL is documented enough to work with or if I should barre bones it. the STM32F0x1 appears simpler than the SAMC. However ultimately if I was ever to use a more complicated micro controller the HAL may be more essential so best figure it out on the simple stuff first then be able to apply it on the more complicated stuff.

[Berni]

There is documentation for the HAL drivers, for example here:
C:\Users\<Username>\STM32Cube\Repository\STM32Cube_FW_F7_V1.5.1\Drivers\STM32F7xx_HAL_Driver\STM32F779xx_User_Manual.chm

Tho it is just doxygen generated html documentation so anything you find in there is pretty much going to be also in the source code comments. But perhaps easier to flip trough. without the mountains of source code in the way.

Best way to figure out how to use HAL is still the example code they provide. Just find the example that is the closest to what you need, copy paste it, modify to do what you need and done. Tho sometimes after messing around with it you come to the conclusion that HAL doesn't support this exact thing you want to do, so you go open the datasheet, look at how the peripheral works and add a extra driver function or two that does the thing, but still keep as much of the HAL as possible to avoid having to make a driver from scratch.

You will find drivers being shit for most 32bit MCU vendors.

And it is with a reason. It is very difficult to write a high level driver for modern complicated peripherals that can cover all possible use cases, there are simply too many or the driver becomes too bulky and complicated. Its much easier to make a low level driver flexible while staying simple since it mostly just needs to give you access to all the raw settings, but the user of such low level drivers has to understand how the peripheral works in order to use it.

In my opinion low level drivers are the way to go. You will need to look at the datasheet to understand the capabilities and limitations of your chip anyway, so might as well have a peek at the registers.

[Simon]

Well yes this is what I am wondering. By the time I have worked out how/if the HAL works I have learnt enough to just do it. The code does indeed seem quite bulky. I started to write my own low level drivers for the SAMC and comparing mine to the ST HAL they are much simpler to do the same thing and it all happens in a one line function not definitions all over the place and huge functions.

[Berni]

Its a lot easier to write a simple driver when you are writing it to do one job. But yes the STM HAL made it even more complicated than it needed to be.

The way i tend to handle it is to write my own wrapper for a HAL driver. That way i can hide away its ugliness, make a sleek single purpose driver. Then i mix and match HAL functions and my own custom functions however needed. Usually using the HAL for init, but then making a custom sleek fast send or receive function for pumping data trough it, or code for running the peripheral trough interrupts and such.

[thinkfat]

@simon

You can always have a look at libopencm3.
Its relatively less bloated than the official cubemx and has a fairly active community. It does take some getting used to.
but the API is fairly straightforward. I found it easier to work with libopencm3 than cubemx.

Just my 2 cents.

I've never looked at the STM32 HAL seriously, but the samples I found look very verbose. I much more like libopencm3, it's really a no-frills approach and pretty lean, IMHO. I've used SPI, I2C and USB peripherals so far, with and without DMA, no major problems.

But the documentation isn't great. It's barely more than a list of functions and sometimes you need to read the code and the reference manual side by side to discover what a certain library function is doing.

Of course it's not without its share of problems. Just recently some weird I2C code in one of the library functions would indefinitely block because a NACK condition wouldn't clear (it couldn't, the slave was in reset and wouldn't talk). Of course it was easily found with a debugger but it isn't an acceptable behaviour to block inside an endless loop on a common failure such as a typo in an I2C address.

[Simon]

I'm thinking that the STM32F0 series are simpler than other ARM based µC's I have started to look at. I may as well just bare bones it. By the time I have read the HAL with the manual for the chip and then worked out what the HAL does, yea, i may as well write my own.

[ataradov]

By the time I have read the HAL with the manual for the chip and then worked out what the HAL does, yea, i may as well write my own.

That's what a lot of people were telling you from the beginning. This is always the case. And it will be the case in the near future.

[Simon]

when you look at the CAN peripheral of the SAMC you'd be glad of anything I don't have a problem with GPIO stuff but if the HAL for the GPIO is near useless it's obviously going to be useless for CAN

[ataradov]

I did look at CAN peripheral and I wrote a driver for it without too much trouble. It looks like a lot, but when you get down to it, and start filling out the registers, most of them are just filled with some constant like 0.

Also, it is a standard BOSCH IP used by many other MCUs. There are all sorts of drivers for it out there.

It also looks complicated because its overall design is different from other peripherals, since it was not designed by Atmel.

[Simon]

Well I think I'll start working my way from GPIO to the UART and then tackle CAN.

[Simon]

So how much influence does Bocsh have? yes they wrote the standard but that is different from how a peripheral works