Again I waste my time complaining about ST products, especially the ST32CubeMX.

[ivanbraga]

I could leave without commenting, but if I do not do this, they can not improve their tools and interaction with the client.

It may even seem from my last posts, that I just want to speak badly. More if ST reads, and pay more attention to users' posts, someone would already be at home resting.

I'm using version 5.1.0 of ST32CubeMX, and it seems to be the latest.

Well I was wanting to organize the way the peripheral / middleware code calls are generated.

Since I did not find anything that gave me this option in the Project Manager / advanced settings, I made the default to find an answer.

Help / Manual.

Here comes the best part, "or I would say, worse," the pdf opens UM1718- Rev 28, I go to page 124 - 4.7.3 Advanced Settings tab and I find this.

Figure 98 shows the peripheral and / or middleware selected for the project.

Ordering initialization function calls.

By default, the generated code calls the peripheral / middleware initialization functions in the order in which peripherals and middleware have been enabled in STM32CubeMX. The user can then choose to re-order them by modifying the rank number using the up and down arrow buttons.

But figure 98 refers to the old version.

Okay, I think, at least it should work the way it is written.

Wrong, does not work, at least for me.

If anyone knows how to do this in version 5.1.0, please explain me.

It is nothing emergency, it is more to follow a form of organization of thought and codification.

Now I vent it.

I can not wait to finish this project and stay a few years without having to use these tools.

I even like the components I'm working on. Already the organization of the documentation and the management of the tools, I want distance.

Ivan Braga

[Rogers.Gary]

Hey, totally agree with you. I just found a bug when setting up DMA transfers. ADC parameter panel says DMA isn't set up in "DMA tab", when in fact it is, and won't let you enable DMA transfers. This, and many other quirks. This next few lines might get me scorched, but at this point, I don't care. Using Cube/HAL is extremely frustrating, and it makes me wish I had stayed with the F4 series processors and CMSIS. Grrrrrr...... I really dislike it when a company pushes stuff out for users to "debug" their software, meanwhile, we have deadlines to meet and have to deal with this boat anchor. No matter, as long as ST meets their sales goals, we're just a bunch of whiners. :flushed_face:

[ivanbraga]

I agree. :loudly_crying_face:

[AvaTar]

I see a two-stage approach on ST's side at work here.

Cube/HAL is mostly for the unexperienced, superficial newbie. It provides a quick sense of achievement, without much intellectual investment. But the name and the brands stick.

Sales are dominated by larger companies that buy in 10k/100k parts p.a. quantities, hire proper embedded engineers, and don't wast time with any bloatware.

[Jack Peacock_2]

As AvaTar points out commercial designs aren't going to rely on Cube/HAL. Cube is how ST competes with Microchip/Arduino for beginners. Produce some kind of sorta working code quickly, move someone up the learning curve a bit, get them interested in using the controller. Understandable, embedded programming can be a daunting task to someone primarily trained as an electrical engineer. But nothing comes for free. Once you get to a major design you discover that great library of free code causes more problems than it solves. Not thread-safe, loops in interrupts, no parameter checking, hard-coded delays, magic numbers with no explanations, all done to get something out the door quickly.

I like the STM32 hardware, especially the close footprint match between families. Overall I consider ST one of the best at M series parts. I've used the product line since the first F1s came out, replacing ARM7s. Fortunately I have a large, proprietary library of well-tested code to rely on when a new design comes along. There are some hassles in that approach, compounded by the lack of example code now that the SPL is gone (and no, LL is just a bad joke, not a replacement).

Reference manuals for newer parts have suffered from shrinking descriptions, I suppose because ST assumes they can bury the complexity in the HAL rather than explain how it actually works. It seems programmers are actually cheaper now than technical writers. Short term gains, but long term it's the datasheet and reference manual that sell commitment to a controller family.

Will I continue with ST? Sure, but it's in spite of, not because of, Cube and HAL. I'm not going to use the Bluetooth controllers though. ST is late to the game, plus they're trying to force the HAL on developers. Competitors already have better products without going that route. But I do have L4 and L0 boards sitting on my desk, ST did get the battery operation right.

Jack Peacock

[AvaTar]

A great and detailed explanation, I agree wholeheartedly.

And yes, I have realized the quality "rot" of ST's documentation and LL code as well.

Several peripherals, like CAN, are not supported by any LL code, only Cube. Dealing with ECUs in the automotive/construction machinery business, this is a serious deficiency.

[T J]

The Cube and HAL have many issues,

some projects, you have to enable systick manually, why is that ?

but basically, the ST family is robust, their DMA work is flawless.

[Rogers.Gary]

Agree with these perspectives. *Once* you get the stuff working, it is bulletproof. Getting there is the issue. Like you guys, I am more in the HW side as well. I found CubeMX a great tool to get through the HW design without resorting to the manual - it helps speed up the process to figure out connectivity. In the scheme of things, ST has to know designers are under time constraints too. Grinding teeth and pulling hair to figure out where some of these issues are serves no one. I would much rather nearly understand well and do register level coding. But who has the time to go through the manual and figure this out? A few on this forum like waclawek, seem to thrive on this mode. In the long term it may be better for sanity. On the more complex interfaces like USB (or other 3rd party) I dunno how one could spend the time to register level or even LL the code to work with these interfaces.

One peculiarity with CubeMX is the lack of "examples". I use IAR, and it has lot of HAL based code examples supplied by ST for the EWARM package. Now let's get this straight. ST really wants us to use CubeMX, which generates HAL, but will not give us the IOC file used to generate the code example? I see this as a huge disconnect. I don't care what platform the code was generated for, it will demonstrate that the *base* code is intact, and we can look at that in relation to the CubeMX to understand what is going on.

Hopefully once ST starts to listen to these points from users they will provide some insight to their thinking and help us understand why. Until then the sliver under the skin continues to annoy.