Is auto generated projects for embedded system the future?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.