Traditional Coding or Code Generators for STM32

[paulca]

On the OP.

It depends on what I am doing and why.  This applies to a whole spectrum of "canned" vs. "bespoke" in software itself.  "Code reuse" is almost a religion.  DRY:  Don't repeat yourself.  Implementation behind an interface, provides, delegates etc. an.inf.

They tend to all suffer the same issue.  Not unique to software either.  Once you move from "totally bespoke" to "partly off the shelf" you tend to find the "Good", "Supported", "Reliable", "Well Tested", "Battle proven" components you lift off the shelf can do FAR more than your original ask, whether you want it, need it or not.

The analogy I trend towards is a person who wants to put up a shelf in his workshop.  The process of drilling 6 anchor holes such that the shelf will be level is non-trivial task.  You could just use a drill... it is itself an off the shelf component.  Or you could by a wall mounted CNC drill platform and have it drill all 6 holes for you, perfectly level.

The issue with the later is, it will take longer to setup, configure, test, trial run and take back down again.  It will "cost" more in real money, something software has a tendency to bury out of sight.  W

When something goes wrong, you are no longer debugging a drill and a handful of wall plug anchors, you are debugging an entire CNC platform which can do 100 things beyond just drilling shelf holes.

To flip it around however.  If you are an interior designer who fits shelves into offices on a daily basis and just want it to get done fast, that overhead might be worth it.  Especially if the customer is paying for speed to market, velocity over "perfection" and can afford the extra support and possibly hardware budget.

So I would often "Prototype" projects using full CubeIDE auto generation.  Later when the actual path that works becomes much clearer I start refactoring out the Cube auto gen and putting much more concrete, specific and bespoke hardware init and control in place.  Reducing code dramatically.

Other times I might just want a test puppet rig and literally just fire up Arduino Framework and use it end to end.   Do not get "partial" or "personal" with your "level" of coding.  It's a bad smell, leads to ego and gatekeeping.

On all code generation.  NEVER, EVER mix them.  When you deal with a system like CubeIDE which uses "comment guarded" mixed generated and edited code, do NOT let it tempt you in to that  antipattern.  At very least put one line of code in there (two if you include the import):  "return mymain()" - yes I put the return there to troll you   Put all of your code in your own files.  Make the links clean and clear.

[Siwastaja]

If determinism is of any value, then this Cube-style flow goes out of window automatically anyway. This is why AI is such a strong contender. It will actually make your life much easier, if you just want things done, and don't care about minute details like "is all code style perfectly compliant to our style guide" or "is machine sometimes doing a costly mistake" or "who is responsible" or other red tape mumbo jumbo 

If you want full control, deterministic and elegant software design and verification flow, AI might be out of window, or scoped down, but Cube-style development is definitely out of question anyway, so that leaves only the magical Real Software Development on the table. This is why I'm saying stuff like Cube autogeneration is dead. Where it was dead already, it remains dead. Where it was thriving, we have something similar but much better now - something which is actually easy and quick when you don't know what you are doing and don't care how the result works and if it fulfills the specifications (the usual Cube story).

[alex_]

Not to blame you because ST docs do often times suck, but you sure chose a beast/hog of an MCU to blink some LEDs. It has one of the most complicated complicated clocking setups to enable easy variable speed for higher efficiency, lots of autonomous peripherals to offload work, and an amazingly flexible DMA system.

I don't know what other MCUs you used because but I bet it was nothing like this one in terms of complexity.

FWIW I have some complex radio/LoRa products based on the U5 and I find it an amazing chip

The system does not even have any LED
I chose that U5 series specifically for the low power (on paper) and DMA performance in tiny BGA package. But I was disappointed by the lack of working code samples and the very poor remappable pins.
Coming from some PIC the jump was hard, more memory but code size exploded, more IOs but very unpractical and little re-use, and overall very slow to react to interrupts

I will move away from Cube IDE and keep it as low level as possible but documentation is still the issue on these complex problems.

ST have a number of presentations on MCU features though (PDF + videos), so while they're usually more high-level, they often give you a better general idea than the RM. These helped me figure out the LPBAM stuff on the U5 series.

Maybe it's me, but I want to read a detailed and formal doc with some proper block diagrams. Watching a slow video makes me loose my time and focus and I don't get their message most of the time.

[nctnico]

Not to blame you because ST docs do often times suck, but you sure chose a beast/hog of an MCU to blink some LEDs. It has one of the most complicated complicated clocking setups to enable easy variable speed for higher efficiency, lots of autonomous peripherals to offload work, and an amazingly flexible DMA system.

I don't know what other MCUs you used because but I bet it was nothing like this one in terms of complexity.

FWIW I have some complex radio/LoRa products based on the U5 and I find it an amazing chip

The system does not even have any LED
I chose that U5 series specifically for the low power (on paper) and DMA performance in tiny BGA package. But I was disappointed by the lack of working code samples and the very poor remappable pins.
Coming from some PIC the jump was hard, more memory but code size exploded, more IOs but very unpractical and little re-use, and overall very slow to react to interrupts

I will move away from Cube IDE and keep it as low level as possible but documentation is still the issue on these complex problems.

ST have a number of presentations on MCU features though (PDF + videos), so while they're usually more high-level, they often give you a better general idea than the RM. These helped me figure out the LPBAM stuff on the U5 series.

Maybe it's me, but I want to read a detailed and formal doc with some proper block diagrams. Watching a slow video makes me loose my time and focus and I don't get their message most of the time.

It is not you. I also work with very complex SOCs from NXP (7k+ pages just for the hardware manual) and I'd much rather setup a peripheral on those than on an STM32. Basically every ST microcontroller is just some silicon slapped together with some wrong documentation made available as an afterthought. It really is beyond me why people even put up with such crap.

[Siwastaja]

Not to blame you because ST docs do often times suck, but you sure chose a beast/hog of an MCU to blink some LEDs. It has one of the most complicated complicated clocking setups to enable easy variable speed for higher efficiency, lots of autonomous peripherals to offload work, and an amazingly flexible DMA system.

I don't know what other MCUs you used because but I bet it was nothing like this one in terms of complexity.

FWIW I have some complex radio/LoRa products based on the U5 and I find it an amazing chip

The system does not even have any LED
I chose that U5 series specifically for the low power (on paper) and DMA performance in tiny BGA package. But I was disappointed by the lack of working code samples and the very poor remappable pins.
Coming from some PIC the jump was hard, more memory but code size exploded, more IOs but very unpractical and little re-use, and overall very slow to react to interrupts

I will move away from Cube IDE and keep it as low level as possible but documentation is still the issue on these complex problems.

ST have a number of presentations on MCU features though (PDF + videos), so while they're usually more high-level, they often give you a better general idea than the RM. These helped me figure out the LPBAM stuff on the U5 series.

Maybe it's me, but I want to read a detailed and formal doc with some proper block diagrams. Watching a slow video makes me loose my time and focus and I don't get their message most of the time.

It is not you. I also work with very complex SOCs from NXP (7k+ pages just for the hardware manual) and I'd much rather setup a peripheral on those than on an STM32. Basically every ST microcontroller is just some silicon slapped together with some wrong documentation made available as an afterthought. It really is beyond me why people even put up with such crap.

And yet, even that inconsistent and poorly documented STM32 HW seems like luxury if you look at the documentation of their suggested software layers or tools (e.g., HAL and Cube) - because a confusingly written datasheet with 1-2 errors per page is infinitely better than no documentation at all.

HW engineers get a stroke when they have to work with software because they are totally used to having documentation. Software folks on the other hand do not even expect documentation because they have never seen one; this also is probably the source of the "don't write your own low level code" misadvice; software folks recommend avoiding low level code because they ASSUME it's A) difficult, B) impossible without documentation, but they miss the fact that the documentation exists - they miss that because with software background, assuming it doesn't is a good default assumption. But with actual physical HW chips with configuration registers, the documentation always exists, and for most microcontrollers it's even very easily available without NDA. Life is made easy for the hardware guys!

[paulca]

How often does your hardware sprout new features or get refactored in service?

[Siwastaja]

How often does your hardware sprout new features or get refactored in service?

Many modern-day embedded devices receive updates nowadays. Even fire-and-forget dumb devices without after-sales updates get bugfixes that get applied in production, or some external component changes and requires a software change, or simply a new, better version of the product is released. It was already evident in early 2000's that locked-down design environments where some magical production PC contains the "right versions" of everything, and no one understands the code, do not work very well. Toolchains which do update, but with least amount of surprise and largest amount of determinism have survived the best - e.g., standard-compliant C code, written with some known-good development practices (like, avoid code generation and especially mixing generated and hand-written code in the same file), compiled with GCC, with minimalistic wrapper layers to separate peripheral access from logic.

[gspeed]

HW engineers get a stroke when they have to work with software because they are totally used to having documentation. Software folks on the other hand do not even expect documentation because they have never seen one; this also is probably the source of the "don't write your own low level code" misadvice; software folks recommend avoiding low level code because they ASSUME it's A) difficult, B) impossible without documentation, but they miss the fact that the documentation exists - they miss that because with software background, assuming it doesn't is a good default assumption. But with actual physical HW chips with configuration registers, the documentation always exists, and for most microcontrollers it's even very easily available without NDA. Life is made easy for the hardware guys!

Like do you even have any idea what you're saying, because it makes no sense whatsoever.

[Siwastaja]

HW engineers get a stroke when they have to work with software because they are totally used to having documentation. Software folks on the other hand do not even expect documentation because they have never seen one; this also is probably the source of the "don't write your own low level code" misadvice; software folks recommend avoiding low level code because they ASSUME it's A) difficult, B) impossible without documentation, but they miss the fact that the documentation exists - they miss that because with software background, assuming it doesn't is a good default assumption. But with actual physical HW chips with configuration registers, the documentation always exists, and for most microcontrollers it's even very easily available without NDA. Life is made easy for the hardware guys!

Like do you even have any idea what you're saying, because it makes no sense whatsoever.

It makes perfect sense on the STM32 context:
1) Low level HW: real documentation exists (reference manual); we often complain about it, but it isn't that bad - 99.9% of registers are documented and explained; there are errors and typos, of course.
2) ST HAL and Cube code generation: no real documentation at all. The best we get is, like in most other software projects, some doxygen-style autogenerated boilerplate that lists function prototypes, but do not explain what the inputs (arguments) actually are, what the function internally does, and what outputs and side effects it produces, and examples of how it is used in connection to other functions.

This is exactly the contrast with HW and SW. ST's reference manual actually explains the internal working logic of every peripheral with diagrams and text; it explains the purpose and available settings of every configuration register; it lists sequences of steps needed to make something happen; it even gives some usage examples, and timing diagrams of typical interactions (!).

So while not great, it has all those basic elements. ST's HAL documentation has none of this. No sequence / state diagrams (equivalent of HW's timing diagrams). And this is exactly the disconnect between HW and SW engineers - those who worked with microcontrollers are used to reading documentation and shit their pants when they have to deal with undocumented software libraries. Software professionals on the other hand have totally used to it and can manage.

Hope this helps; if you still don't get what I'm saying, you are beyond salvage and can add me to your ignore list; that's OK, we are built differently.

[paulca]

Have you ever used "man 3"?  I mean with commands like:

man 3 printf

Or "info"

info glibc

HAL is a "token effort" from STM.  Those 99% good HW manual probably costs them a million or so a year to run a team of tech writers.  Without them their business would degrade and people would go to MCUs with better manuals.  For HAL, having poor docs thats far less likely.

[Siwastaja]

Have you ever used "man 3"?  I mean with commands like:

man 3 printf

Or "info"

info glibc

Yes, POSIX and libc is largely documented, but try man 3 mbedtls and you are suddenly out of luck. Luckily we have AI nowadays to make sense in large nearly undocumented libraries, especially those with source code available because AI has been trained with all anecdotal forum data which takes weeks to manually dig, with the source code, and it can re-check from the source code once again in your context.

[Kjelt]

Mwah being an EE and SWE my entire career I understand both worlds.
And while HW without 100% correct documentation, timing etc. descriptions could cause havoc, pcb reruns, damaged devices/components over time, is software way more leanient, experiment around till it works, etc.

Even then the HAL for F4 at least has what was suggested, functionality, input , output parameter description or the code and parameter names themselves are self explanatory. Modern IDEs do the rest.

So if there is no concrete example and context given what is a real problem and why , then I would say 

[Siwastaja]

And while HW without 100% correct documentation, timing etc. descriptions could cause havoc, pcb reruns, damaged devices/components over time, is software way more leanient, experiment around till it works, etc.

Perfect summary. Interestingly, software projects end up massively expensive; serious overbudget, serious overscheduling is considered totally normal. Same would be unacceptable in HW. The attitude that "we can experiment until it works" is all over the software ecosystem, and while it's somewhat true, it is also toxic. This experimentation is very expensive. Now AI agents are really good at it, and they still suck at experimenting with HW (mostly due to obvious physical limitations), so outcomes are changing; attitudes stay.

[Kjelt]

Interestingly, software projects end up massively expensive; serious overbudget, serious overscheduling is considered totally normal. Same would be unacceptable in HW.

No you are too black/white again IMO. There are indeed lots of software projects that are started without the proper use cases and details needed too end it succesfully, or under estimated the amount of effort. But there are also numerous hardware projects that never see the succesfull product launch like hyperloop for instance. So it is not only software. In my current multi billion $ company much of the hardware is outsourced to third parties and they give enormous headaches because also there we see big issues with the proper unambiguous requirements. If there is a difference at least in my company it is the assumption that software is easily fixable, while a complete redesign/refactoring of our codebase could also take years, so it is never planned. The result is degradation of quality due to continuously stacking code on top of a flawed start design. That is something you do not see with hardware. If the first hardware part has a proven issue it will most probably be replaced by a different part. In software it can also take a lot of effort to redesign/refactor, project leads don't accept the months delay and pushing for "quick and dirty fixes".
In the end HW and SW are the same, they both end up garbage when the design and requirements are trash. GIGO, Garbage In, Garbage Out.