Traditional Coding or Code Generators for STM32

[EVblog1]

I usually write code for PIC microcontrollers using XC8 by following the traditional approach. I write the peripheral drivers and application code myself instead of using a code generator because I feel more comfortable with manually written code than generated code.

Since PIC microcontrollers are relatively simple compared to STM32, RH850, or TI microcontrollers, I'm curious about how developers work with those platforms. If you're using STM32, RH850, or TI microcontrollers, do you mostly write the code manually, or do you rely on code generators? I'm interested in knowing what approach developers typically follow in companies

[Siwastaja]

Write your code yourself, or if you don't want to, let a state-of-art coding agent (like Codex or Claude Code) do it for you (i.e. vibe it). MCU IDE code generation was always iffy. Now it's finally completely dead, since for those who want a computer to write their code, there is something much much better available, something which far better understands the actual interactions between parts and your intent.

[cfbsoftware]

I have never used code-generating wizards when writing embedded software. I write all of the code myself for STM32. However, I'm an extreme example as I have written my own tools as well. I started with just a text editor and compiler. I then wrote the IDE (a syntax-aware editor with code navigation and linking / building capabilities). I also wrote the Cortex-M code generators for Niklaus Wirth's existing Oberon compiler which generates the Arm instructions directly without the need even for an assembler.

I have used AI (ChatGPT) recently as I find it easier than starting a new project with a blank sheet of paper. However, you do need to have an excellent understanding of the subject matter. I have found it makes many newbie mistakes and needs to be cajoled into writing decent code. However, I'm yet to try Claude, maybe that does a better job?

[nctnico]

Where it comes to STM32, most seem to use the HAL library as a crutch to get going quickly. Make sure to take a look at NXP's LPC series of ARM microcontrollers. The documentation is so much better and the peripherals are way more consistent between the various types that it is much easier to write your own code instead of being forced to use a crappy software library. I know STM32 is popular but for me it would be absolutely the last choice when needing an ARM microcontroller.

[NorthGuy]

There's no dramatic difference. There are more registers. So it may take some time to figure out how to set up clocks, for example. Or you may need to take care of caches or use memory barriers here and there. But nothing that would require you to change the way you work.

[EVblog1]

Thanks to everyone who shared their perspectives.

I think my original question may have come across as "code generators vs. manual coding," which wasn't my intention. I'm not looking for a debate on which approach is better, since both clearly have their place.

What I'm really interested in is the development workflow typically followed in commercial embedded projects. For teams working with STM32, RH850, TI, or similar MCU platforms, is it common practice to use the vendor's configuration tools (CubeMX, Smart Configurator, SysConfig, etc.) to generate the hardware initialization and then develop the drivers and application logic manually? Or do many teams avoid generated code altogether and implement everything from the ground up?

I'm interested in understanding what is considered standard practice in production environments and the reasoning behind those choices.

[SiliconWizard]

The question is biased as there is very often a middle ground: using vendor's SDKs (to various extents) rather than write low-level support entirely from scratch, but not use "configuration tools".
The two are orthogonal.

Among the "major" vendors, I think ST has managed to confuse people the most. They have invested a lot over the years in the CubeMX tool, while their support library (HAL) is bloated, hard to read and has virtually no useful documentation other that its source code itself (which again is hard to read, due to them sticking to an absurd degree to MISRA conformance, leading to convoluted constructs and a LOT of duplicated code, it's horrific IMHO).

There is no standard practice - it mostly depends on the environment. For safety-critical devices, third-party code generators are usually a big no-no unless you have been able to validate them (good luck), and third-party libraries, often as well. unless the vendor can provide solid evidence of correctness with an exhaustive test set. For ST, the fact their HALs are MISRA-compliant doesn't mean they are validated for any given purpose. It looks cool on a powerpoint, but that's about it. If you use that, you're still fully responsible for the outcome.

For non-safety-critical stuff, I've actually seen a lot of companies, especially smaller ones, use CubeMX generators. If you're not bound by specific standards/regulations, you're on your own. You will use whatever you're comfortable with and gets you where you want to be. In any case, reviewing your results on a regular basis is a good idea: make sure, with objective indicators, whether your use of automated tools and third-party libraries have really brought more benefits than problems. It's rarely obvious.

[rf-fil]

I do a lot of STM32 commercially. Most of the time, I use CubeMX to generate the initial project. Then I add my own code into separate directory and try to touch the CubeMX generated code as little as possible. Time is money. Avoiding the STM32 HAL because you don't like how the code looks, and deciding to try and decode thousands of pages of ST documentation instead seems unhinged, lol.

[peter-h]

That's what I do too.

[NorthGuy]

I'm interested in understanding what is considered standard practice in production environments and the reasoning behind those choices.

Considered by whom?

There are different companies. They consist of people of different skill levels and different personalities. The diversity of projects is enormous. This produces huge variety of approaches. Thinking that there exists a single "standard" way of doing things is incorrect at best.

[Siwastaja]

I'm interested in understanding what is considered standard practice in production environments and the reasoning behind those choices.

And why would that matter?

If it does, then your question is even more heated and polarized than it otherwise is already. Half of the "big boys" (or those pretending) say that the idea of using some random tool to generate code which you then modify is against all sane software development practices; a last resort hobbyist hack - and they are kinda right; this whole CubeMX thing doesn't really belong in elegant, professional software development flow, where code is written, unit tested, integration tested and versioned. Polar opposite of point/click/modify.

And then again, many companies resort to such unelegant, unprofessional way of development anyway, and if it works for them, great - and if it works for you, then great! - hence my comment: why would that matter?

What makes me laugh though is some people on forums who obviously have absolutely no idea how software is professionally developed touting CubeMX code generation on a random Windows machine and then being randomly modified and put into a dropbox or something as a pinnacle of professional large-scale software development. The whole flow is a textbook example of a hobbyist flow - and don't get me wrong, there's nothing wrong in that, and it probably is faster way to good results, especially in smaller startups. But it isn't The True Software Development Way; if you are looking for that for any reason, look for: working in teams, writing specifications, writing tests, writing documentation, version control, code reviews - stuff like that. The CubeMX/ST HAL way bypasses all of this: you can't automate the tooling, it doesn't have any documentation (formal or not), it is almost impossible to work in teams, testing is difficult because nothing is modular, autogenerating and modifying autogenerated code or adding between INSERT THERE tags is poison for traceability / version control. and so on. So guys, keep using and recommending CubeMX but don't pretend CubeMX must be used because "Real Software Developers in Real Companies do it like that". They don't. Ask paulca.

[uer166]

a last resort hobbyist hack - and they are kinda right; this whole CubeMX thing doesn't really belong in elegant, professional software development flow, where code is written, unit tested, integration tested and versioned. Polar opposite of point/click/modify.

I kind of agree, however real companies do horses for courses. We have multiple codebases for same boards because some are bringup FW for EEs to play/hack around with and be able to modify FW easily and use CubeMX, others are pure IDE-less environment for large scale deployment and is more production-focused.. To OP: don't listen to anyone claiming there's only one "best practice" since that misses the point entirely.

[EVblog1]

You all make a fair point. I agree that there isn't a single universal standard. Different companies have engineers with different backgrounds, different project requirements, and different development processes, so naturally their workflows will differ.

I got answer what I was trying to understand, so there's no need to continue it further. Thanks everyone for sharing your perspectives.

[smokeless0864]

Real man write their own HAL.

[alex_]

New to the STM32 ecosystem here after decades working with other brands. Using a fairly recent U5.
Tried to find my way along the IDE and getting to blink the LED was quite an (awful) experience.
Anything more serious is just : why why why ?

The HAL vs LL is confusing, incomplete and often incompatible.
the code generated is WTF is this so inefficient ? And buggy on top of that.
So back to basic, manual init of the peripherals as needed, trying to understand the bitfields and wondering where is the documentation ? Where are the simple examples ?

so my advice is stick to your MCUs, stay away from the STM32 as there is neither a good documentation nor a good code generator.

[NorthGuy]

... trying to understand the bitfields and wondering where is the documentation?

There are 3 documents:

Datasheet - pinouts and electrical characteristics

RM (Reference Manual) - explains all the modules and registers

PM (Programming Manual) - explains ARM core things - basically repeats ARM docs, but is written much better

All three can be downloaded from the home page of your chip. Plus there are app notes and whatnot.

Where are the simple examples?

If you need examples, AI will create examples for you. They probably will not work, but it may give you ideas.

[SiliconWizard]

So back to basic, manual init of the peripherals as needed, trying to understand the bitfields and wondering where is the documentation ? Where are the simple examples ?

In the examples/ subdirectory of all of their STM32CubeXXX SDKs. For instance, for the recent STM32C5 series:

https://github.com/STMicroelectronics/STM32CubeC5/tree/main/examples

[NorthGuy]

So back to basic, manual init of the peripherals as needed, trying to understand the bitfields and wondering where is the documentation ? Where are the simple examples ?

In the examples/ subdirectory of all of their STM32CubeXXX SDKs. For instance, for the recent STM32C5 series:

https://github.com/STMicroelectronics/STM32CubeC5/tree/main/examples

I think AI works better. Type "I need a led blinking program for STM32C591 with registers without HAL" in Google.

[alex_]

If you need examples, AI will create examples for you. They probably will not work, but it may give you ideas.

Agreed. But for the U5 which is architectured differently from the older families and that lacked stackoverflow content, AI was (I will try again) useless, always referencing some registers that do not exist anymore. At the end if the manufacture does not generate good samples the AI has nothing to train on and just hallucinates solutions.

In the examples/ subdirectory of all of their STM32CubeXXX SDKs. For instance, for the recent STM32C5 series:
https://github.com/STMicroelectronics/STM32CubeC5/tree/main/examples

The github samples are pretty simple. For the power management for ex they show simple scenarios, far from my real applications that mixed interrupt sources and low power requirement. It was either low power never waking up, or not low power. Apparently a known issue of this family but hidden by ST.

[SiliconWizard]

Admittedly their examples lack a lot of details, but I haven't found that much better with other vendors.

One thing that I mentioned earlier though, but is not limited to ST and rather common: the more a vendor invests in code generators and HALs and often the less they invest in documentation. They assume that all users will use their tools & libraries and good luck for anyone who doesn't, or anyone who needs a feature that they haven't implemented yet.

There's a reason for that: writing code is easier than writing documentation.

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.

[uer166]

New to the STM32 ecosystem here after decades working with other brands. Using a fairly recent U5.
Tried to find my way along the IDE and getting to blink the LED was quite an (awful) experience.
Anything more serious is just : why why why ?

The HAL vs LL is confusing, incomplete and often incompatible.
the code generated is WTF is this so inefficient ? And buggy on top of that.
So back to basic, manual init of the peripherals as needed, trying to understand the bitfields and wondering where is the documentation ? Where are the simple examples ?

so my advice is stick to your MCUs, stay away from the STM32 as there is neither a good documentation nor a good code generator.

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

[Siwastaja]

The story is always the same:
* Documentation missing
* Examples missing

This is ridiculous because the effort of doing proper documentation and examples is orders of magnitude smaller than the collective grieve of everything being so difficult for everyone. But this is psychology; it's a bug in our brain. We "want" things to be simple and easy, but deep down we don't want it, instead we want to prevent others from competing and having power. This is the only explanation which fits every company and project - megacorporations, non-profits, small and large, individual hobbyists - having the same blind spot - incapability of doing documentation and examples.

Human kind has proven complete incapability of writing documentation and examples. It just is impossible. After decades of banging head on the wall - and we can't change our nature no matter how much we want to - AI came and solved the problem. It parses together the missing documentation from anything it can find, and creates you exactly the examples you need. Use it proudly and without shame if you want to leave frustration behind and start getting work done. You can let it vibe up everything, or you can use it just to find the missing pieces, and/or check your code. Your choice.

[Kjelt]

For a professional software company with SW teams and long term software development projects you want to skip Cube.
Reason: long term project stability, being able to reproduce softwarestacks from 3 yrs ago , etc.

For a small company or all the hobbieists out here, it works and it is fast for quick development or prototyping.
If you claim Cube is difficult and hard to understand you are probably not a SW engineer or lack experience.
Go to youtube and find ControllerTech for tons of directly working examples.

Also the people promoting AI for code generation, yeah..... My experience is that AI for embedded dev can certainly work but when it comes to the implementation there are many issues, like it does not work for that specific microcontroller (many STM32 variants, many different peripherals and many different features (or lack of)). Always be specific, telling him your uC variant before going down the rabbit hole.

Just my 2 cts, was a commercial emb. SW engineer for over 20 years on STM8 and other micros, and really wished I had a Cube generator back then instead of colleagues designing difficult to maintain X macros to configure the micro 
Give it a try don't give up in a day, get when stuck advice here or from youtube and get fun projects running within days.

[paulca]

Write your code yourself, or if you don't want to, let a state-of-art coding agent (like Codex or Claude Code) do it for you (i.e. vibe it). MCU IDE code generation was always iffy. Now it's finally completely dead, since for those who want a computer to write their code, there is something much much better available, something which far better understands the actual interactions between parts and your intent.

This is where things get interesting as what you say is correct, but misses an important point.  Determinism.  Without determinism you are not doing engineering, you are just messing around.

When you use a code generator you can predict the code it will write 100% of the time.  When an LLM does it, you can't, because the LLM is non-deterministic by it's inherent nature.

Where code generation is most used is in "integration".  Two or more systems (or components within a single process) work off of a shared definition of the integration "API".  That definition is code and is auto generated by one or more components from a set of descriptors.

It has been discussed that the whole API code-gen layer could be removed and just use an LLM, but it was quickly squashed by the LLM itself saying, "DO not do that."  It predicted that variations would occur as each component generates it's own view of the integration and the components will diverge.

[Doctorandus_P]

For a big part it depends on what you're doing with your uC. If you're bit banging SPI or a serial interface, you want efficient control over I/O pins, and direct register programming is probably the best method. And learning how the I/O registers of the uC you use work is pretty basic knowledge.

On the other side. I would not want to write a complete USB stack for a uC with only register programming. Having a library that can get a CDC (or other) device going from a handful of library calls is pretty nice.

For some madness, you can have a look at Obdev V-USB. It's a software USB stack for the AVR uC's (which do not have USB hardware). It's partly written in assembly because of strict timing requirements.