I'm using CubeMX for auto generate projects for the STM32 micro controllers. I really like CubeMX because it's fits both STM8 and STM32 micro controllers.

One thing that I'm wondering about is if CubeMX is really good if you want to program micro controllers in general?

I mean....if you are used to use CubeMX for STM32...you going to be stuck with STM32. In other hands, is there any reason to change the platform if your current plat form is suitable for you?

I have talking a lot with old school micro controller programmers and they spit on CubeMX and call it cheating. I don't know if they have the experience to say so, or if they are jealous because younger generations get it much easier to do the same thing they do, without any hard working hours in the basement every day.

So if CubeMX is the future, will not other micro controller manufactures also create software that also auto generate projects for the selected micro controller? As I know, only Silicon Labs and STM have something called auto generate project software. Will other companies follows up?

If not? Is register programming the only way to learn program micro controllers?

  • 6
    \$\begingroup\$ (the first auto-generation tool was called an assembler) \$\endgroup\$ Commented Mar 24, 2021 at 12:40
  • 8
    \$\begingroup\$ I think this will attract opinion based answers. Use a tool if it makes sense. Don't use a tool if it makes sense to not use it. \$\endgroup\$
    – Justme
    Commented Mar 24, 2021 at 12:41
  • 9
    \$\begingroup\$ Code generators are ok if what you want to do fits their mold. A well rounded embedded practitioner should be able to write low level code if necessary, understand computer architecture and assembler programming but these skills are not a definite requirement to solving a given problem. At some point you’ll have to debug a tricky problem, so having an understanding of what happens behind the scenes is a benefit. \$\endgroup\$
    – Kartman
    Commented Mar 24, 2021 at 12:43
  • 7
    \$\begingroup\$ @user253751 and then when FORTRAN came out, they said we weren't going to need any more programmers because business people would just write the code in 'English'. \$\endgroup\$ Commented Mar 25, 2021 at 1:09
  • 2
    \$\begingroup\$ I don`t think these kind of things can substitute the standard programing, the true word for this is just "setting device", not programing. Very often you need something not available in libraries and then you are lost. It is also the arduino problem, you can do project very quick until you are using premade lib, otherwise you end up in AVR,ESP... and can you bring even more problems. \$\endgroup\$
    – user208862
    Commented Mar 25, 2021 at 7:17

7 Answers 7


There have been repeated attempts to create various different auto-generating code for the last 20-30 years or so. Each time, it's marketed as something revolutionary, but it never becomes a success. This isn't something new at all. Siemens/Infineon had such tools way back in the late 1990s. Motorola/Freescale also attempted something similar in the early 2000s. Microchip, too, though I never used it.

Sure, part of the reason why it never becomes a success might be orthodox programmers who hate everything new. I mean, people still use 8-bit MCUs even today, and the main reason for doing so isn't technical, but "I don't want to learn anything new". There is a valid argument hidden in there, though: once you learn a toolchain well, you get incredibly productive with those parts, so you do reduce time to market significantly if you keep using the same old tools for the same old MCU family.

But I suspect that the main reason why auto-generating code never kicks off is this: when things go wrong, you need to be able to troubleshoot your code. If you haven't got a clue about what the registers do and never even read the manual, you will be lost, with no way of recovering the program. Sooner or later, you will actually have to know what you are doing.

One real-life anecdote demonstrating this is when I worked at a workshop using a toolchain that I already knew well, and they tried to sell us auto-generating tools. I poked around a bit and asked the guy giving the presentation why the tool needed to compile 130k lines of code to toggle a GPIO pin on and off…he didn't know.

This has always been an issue with pre-made libraries or auto code generators made by silicon vendors—they are of incredibly poor quality. The silicon vendors have some sort of internal branch competition over who can produce the most horrible toolchain of all time, or the most horrible open-source library, or the worst written code examples in their application notes. Some of the worst tools, libraries, and code I have ever encountered in my programming career have come from silicon vendors. The various poor Eclipse IDEs by pretty much every silicon vendor stand out in particular. For example, (speaking of Silabs) Simplicity Studio is perhaps the most dysfunctional programming tool ever released, across all categories.

Is there a future for some of the worst programming tools ever released? I doubt so, and that has nothing to do with auto code generation and everything to do with non-existing quality. Bugs, bugs and more bugs.

Having some manner of reference code, auto-generated or not, is a huge time-saver, however. It's pure madness to have a MCU vendor sell a particular part to a thousand different customers, then each and every one of them has to re-invent the wheel by writing their own drivers for timers, ADC, SPI, UART, and other very common stuff. Also, MCUs only become more and more complicated, with intricate clock set-ups, peripheral routing, DMA, and so on. Looking at pre-made code helps.

  • \$\begingroup\$ Comments are not for extended discussion; this conversation has been moved to chat. \$\endgroup\$
    – Voltage Spike
    Commented Mar 25, 2021 at 15:37
  • 3
    \$\begingroup\$ This answer would be considerably improved without the rant that categorically says the "main reason" for using 8-bit MCUs today is "I don't want to learn anything new". That statement appears to be biased personal opinion. Sure, for some people in some situations, that will be the reason (and as explained in the answer, it might be based on underlying quite valid reasons), but categorically saying that everyone who chooses to use an 8-bit MCU today is doing it merely because "I don't want to learn anything new" is, at best, hyperbole. If it didn't express that bias, I'd upvote. \$\endgroup\$
    – Makyen
    Commented Mar 25, 2021 at 18:23

People have been inventing ways to generate code without having to write any code for decades now - and they all hit the same limitations.

CubeMX does not really do anything very clever (complicated yes, clever no) and it's not really writing original code the way a programmer would - it's creating a configuration with blocks of pre-written code, filling in blanks to align functions to the chosen hardware configuration and inserting or deleting blocks as they're used or not.

The HAL libraries it pastes in by default are complex-looking and not widely liked, you can switch it to generate similar results using the Low-Level (LL) libraries and the results are much simpler and only a couple of steps removed from the bsic CMSIS header files which define peripheral addresses etc. as more readable entities.

What none of this stuff will do for you is actually create original useful code - sure it might include a driver for a display and allow you to tie it to certain IO pins with certain parameters so it all works without any typing on your part - but it's never going to know what you want to actually DO with that screen, and the only way to accurately describe what you want the thing to do is through writing code.


It all depends on who you are and what do you use it for.

If you are a hobbyist that wants to start a project, you can use CubeMX to have all the peripherals you need configured and a LED blinking under a real-time OS in 15 minutes so you can start building your application.

If you are a medical device manufacturer, you may not even be able to use CubeMX due to regulations how code should be 100% validated for use, if ST licence allows for it.

As an example let's take STM32H743 which is quite a beast. Without any code generator, you could spend days reading the HAL manual how to use the HAL to set things up. Even worse if you don't use HAL but want to write to registers yourself. Getting the MCU PLL to work reliably at wanted frequency is not an easy task, controlling all the caches and onboard voltage regulators to correct settings to run at say 400MHz. Then you need to figure out which buses and peripherals need their clocks enabled and in which order before you can even start configuring a single GPIO pin.

And using CubeMX does not limit you to STM32. You can do code that is MCU specific. You can also write a simple layer which hides away MCU specifics, so same application code will run on any platform as long as the specific layer is reimplemented for a new platform. Basically how a C or Python program that prints "Hello World" is identical on both Windows and Linux.

  • 2
    \$\begingroup\$ I wrote about the complexity of modern devices (different location) a while ago; the last time I picked up a new microcontroller, I had to wade through several thousand pages of information. Finding the information you need in the manuals really is quite a treasure hunt, but necessary if you need to do register level debug. \$\endgroup\$ Commented Mar 24, 2021 at 14:18

This is by no means a unique feature: Renesas code generator and Infineon Toolbox come to mind. Those tools all have the same flaw: they force you to use a certain framework which is not flexible enough in practice. The moment you edit the auto-generated code to adapt it to your needs, you lose the option to use the code generator again: it will typically simply overwrite your changes.

The way you use those tools in serious SW development is creating a prototype SW which uses a certain feature, study it, then implement your own code (possibly borrowing parts of auto-generated code). It's usually much faster than trying to write your own code from scratch using just the datasheet.


Code generation as you speak of it is mostly a way to setup and abstract away the direct hardware setup register interface.

That has been a trend for quite some time from several (all?) chip providers, and is known as a HAL (Hardware Abstraction Layer). Auto-generating that code from a GUI has been done by at least Atmel and ST and probably others already. However, the generated HAL hasn't really been useful for more than one series of devices from the same manufacturer anyway, since your code would have been quite closely coupled to the actual hardware anyway.

Another, newer(?) trend is to use a HAL that is vendor- and chip-independent, and only write your application code on top of that. For example, the ZephyrOS Project solves this initialization by using a board file that defines what hardware and CPU features are available and at which ports / addresses.

Your own code only has to utilize the generic APIs for accessing hardware features, and your code will be portable by default, with no need to auto-generate custom setup code for your CPU.

The overhead means it's not the right fit for all occasions, but IMO the answer to your question of whether auto-generation is the way into the future, I would say we've already moved past that.


Obviously there are many answers here which basically forbid the use of "generated" software. I'll take a stand for the other side: Use what's there.

I am what you would call a (more or less) professional software developer (at least that's where I get my income from). I have been working with larger teams as well as alone. Unless there are very good reasons (safety, medical, it's you two I have in mind) I try to use what's already there. There is no reason to re-invent the wheel.

The main question is where do you put the line. I think register access is commonly viewed as pretty low level. What about the system initialization, the part before main actually starts - that is generated code as well - have you really ever written that from scratch? Do you consider assembly generated code? What about a USB stack - really re-invent that? Including data and instruction caches combined with DMA access on the way?

I agree that from time to time it will be necessary to be able to debug into register level, to understand the inner workings - but I will do that when it's required.

I don't mind spending a little more flash if cost reduction is not the most important goal. Should I see the need for reducing the memory footprint, I would use other means to determine where one could achieve reductions; the various outputs from the compiler/linker are pretty nice once you start using them. Simply saying that the framework sucks because it uses too much memory is easy, compare it to your own code once it's finished is much harder. Again, if you don't like what's generated, you're free to modify it to your needs. Usually such code will cover various edge cases you wouldn't think of. Don't fall into the pit of premature optimization.

Would you write a RTOS on your own? Are you sure you can achieve better code quality than some OTS package which has been tested by thousands of users? Renesas for example has a software package targeted at functional safety - sure you don't want to use that code?

I understand that there are many libraries out there where the code quality is ... questionable (I'm looking at some arduino libraries here) and which I wouldn't even touch.

I try to focus on the application I'm building, not the surroundings or interfaces - others have already thought about that long time. If the hardware is able to do something but it's not implemented in the framework, I can still add it for my use. The framework is not meant as complete for each and every purpose but - if it doesn't fulfill your need - you can always adapt it to your needs.

In the end, it's the customer who will pay you and you will only get paid for what was specified.


I think that it is the future. ..sort of.

On the last several projects I've started, the MCUs have all had some sort of code generator. CubeMX for the STM32, Atmel Start for the ATTiny, and Microchip Code Configurator for PICs. I use them every time I start on a new design. Why? It has 2 huge advantages over starting from scratch.

  1. The code generators make it very easy to test different pin assignments of GPIO and peripherals. If you're using a lot of peripherals, and each one can be assigned to several different pins, doing this by hand can be very tedious. Doubly so if you want to find "the best" solution, and not just any combination that works.
  2. They make it much faster to get started with a new peripheral. No more "oh I didn't realize it doesn't work unless I disable this other thing" type situations. I find that when I'm writing the registers to control a peripheral for the first time, it usually takes several iterations of trial and error to get things going. With the generated code it's the opposite, it works the first try more often than not.

So why do I say "sort of"? Well I agree with others that once the project is off the ground they don't really change anything. You'll inevitably have to read through and modify all that generated code ..so essentially all you're getting is some good example code to start with. It's very convenient, but not essential.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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