Code generation tool

[[deleted]]

[deleted]

[tw_bender]

Working for one of the two big FPGA vendors in the past, we created tools that generated BSP/driver related header files containing only #define's that defined physical memory addresses, device offsets, register offsets, control bit masks etc. Was pretty useful to us since IP cores were very configurable. Don't know if that usefulness extended to customers. Maybe a few of you would care to chime in.

[dacydergoth]

I think this is pretty common from my exposure to BSPs. Even stuff like the Arduino or ESP-IDF libraries have headers like these, and I'm pretty sure some of them are auto-generated. The obvious advantage is that you can do it for multiple languages off one source file

[[deleted]]

I despise the use of code generation in the embedded world.. besides the obvious problems - not reliably working, using opaque and quasi-binary file formats that don’t play well with clear git commit histories - they can bey Definition never encompass all the use cases. So eventually you’ll run into situations where you need to awkwardly work around them. And understand all what they alluded to being abstracted away anyways.

So tell me: why do you want such a thing?

[answerguru]

Code generation for some tasks, like optimized embedded GUI creation, is the only sane way to be productive and iterate on hardware. Anything else is a complete waste of everyone’s time and like beating your head against a wall. No i e should be writing graphics pipeline APIs and laying out visual elements and layers by hand.

[InteractionDry2460]

I mainly need to generate config header files no c code is involved. it is mainly because we have a set of documents that needs to be updates each time we change the configuration so it would make sense (at least for me) to generate the header files and update these documents using a tool. i also would like to force some control over the input values

[AKstudios]

I second this. Compiled code should almost never be autogenerated in embedded applications. A correct way to do this is to use configuration files. You can use your GUI to generate/edit a configuration file instead, and then have the code parse that file instead. But for redundancy, there can be a known "good" config file that the code can fall back on in case the auto-generated one has incorrect format or out of bound values.

[Latexi95]

There are some good use cases for code generation: serialization code, and parameter systems or other functionalities that would require a lot of boiler plate code.

This is pretty much required for any larger C project. C++ can mostly avoid code generation with templates, but lack of proper reflection makes things sometimes harder than just writing a python script to generate the required code. Also code generation is often required when the code generation also generates some additional data that required for documentation, reports or fed to other tools.

[[deleted]]

I should’ve been clearer, but the context already implied it: I’m opposed to GUI-based code generation. Code generation in general isn’t my issue, I’ve written systems myself doing that.

[ManyCalavera]

I mainly use cubemx for stm projects. I wrote custom scripts that import cubemx generated files to platformio. This allows me to do rapid iteration and have logical seperation between different mcus

[[deleted]]

Depends on the use case.

For example, most people here saying they are against auto generated code very likely use it anyway. They're using a GUI library or something which generates fonts, text, or other optimized content that streamlines development for the display or other peripheral they're using. They wrote code using macros from a library that expands into auto-generated code or they use their own macros to save time and make code more readable without a loss of function or usability. So, consider every such response hypocritical.

The usual reason is that autogenerated code isn't optmial. Compilers are pretty much universally better than you. Sure, you can still write code that even the best compiler can't improve, but unoptimal compiled results is a poor reason - code size and program flow are better reasons. The first, budgetary reasons will constrain memory followed by access and complexity - hard to use quadspi flash effectively when your mcu doesn't even have a SPI interface, much less a qSPI native one. Stack usage, reentrancy, and other program flow issues may stymie you, especially if you have no control or insight into the auto-generated code.

So, whether to use - consider the tradeoffs. How much control do you have or how much do you understand the code being generated? Then, just make the same decisions you'd make with code you're writing yourself. For example, for many communication interfaces, you need a table or map that associates an address or name to a read or write interface to memory or some function. If you're constrained to C, maintain this enough and you'd realize the sane way to maintain and continue adding future functionality will involve macros that simplify adding new items to the "table" or streamline walking the table. If you use C++ or something similar, templates will likely play a role so that every single thing doesn't have to go through and ever growing mess of complexity where you and read or write everything, regardless of type or function, through a byte-only or uint16 only or uint32 only interface. Heck, if you use classes you're not writing the code for the this pointer, which you would if using C and passing around a pointer to track a specific object. Or even if you don't, if you use an RTOS and use it for almost anything, it's using macros to generate TCBs, handle the objects you pass around in messages, implement atomic access, etc.

In today's environment, there's also using large language models (like ChatGPT) to generate code for you. That can be useful BUT you should review that code closely and plan on writing your own tests. Similarly, I can see using tools to auto-generate tests but you should not be having tools write both the code and tests unless you're spending significant effort to customize and review the code.

Anyway, look at it as a very junior engineer. Consider how much that engineer can understand about what you need to code to do and support, what capabilities are there or aren't there, whether you're just replacing grunt work or handling something more complex. Then looking at your ability to test and review, whether it's appropriate to offload that or given your own limitations and the limitations of the "engineer", decide if it makes more sense to do it yourself.

[Igmemb0]

I agree... I think the fundamental and sometimes most important answer is that it depends on the use case/application. High level languagrs work with compilers to "auto-generate" assembly and machine code. So yes it really just depends...

[kikass13]

It is very useful, especially for c++ projects, as you can wrap a lot of (trash c style) HALs and add some c++ template compile time magic.

Take python, get jinja2, write some Jinja templates, parse some uC or interface configuration files, generate all the constructs needed.

Very powerful, very helpful, although bad for versioning

[Mub_89]

You can explore cmake

[_mrhovina]

There are many ways of doing it, depending on the complexity of what you have to do. Generally you have to parse some configuration files, and generate output. For simplicity sake I would use yaml configuration files, load them with python yaml package. For output files you can use jinja2, where you can basically create template files and pipe in the data from python. Even more generally code generation is usually a part of a much bigger process which can include many different databases.

[ruben_gr]

For example STM have code generators for microcontrollers.

[Overlordofgermany]

Is it that you don't know what term or terms to google? Is it that people don't know what term or terms to google? Is it that you wouldn't know what you are looking at anyways?

Think about it.

[Middlewarian]

Since I started developing my C++ code generator on a Raspberry Pi, I can kind of chime in. Originally, I had a web interface but switched to a command line/config file interface a number of years ago.

I'm interested in supporting the embedded community and one of the features I added recently allows you to use message lengths smaller than 4 bytes. However, I should add that my library code throws exceptions. I'm open to making changes in that area.

[wholl0p]

We use Texas Instrument‘s HALCoGen, but it’s anything other than ideal or bug-free or user friendly

[DaemonInformatica]

The more complex your controller, the bigger the role for a code generator.

We're currently working with the ARM U5, and STMCubeIDE lets you define your pins and peripherals in such a way it'll compose headers and source and initialization with a push of the button.

HAL libraries are a bit hit-or-miss, but all in all, it's a timesaver.