STM32CubeMX Makes Makefiles

When hardware manufacturers make GUI code-generation tools, the resulting files often look like a canned-spaghetti truck overturned on the highway — there’s metaphorical overcooked noodles and red sauce all over the place. Sometimes we think they’re doing this willfully to tie you into their IDE. Not so the newest version of ST’s graphical STM32CubeMX, which guides you through a pleasant pin-allocation procedure and then dumps out, as of the latest version, a clean Makefile.

Yes, that’s right. This is a manufacturer software suite that outputs something you can actually use with whatever editor, GUI, compiler, or environment that you wish — even the command line. Before this release, you had to go through a hacky but functional script to get a Makefile out of the CubeMX. Now there’s official support for real hackers. Thanks, ST!

If you’re compiling on your own, you’ll need to update the BINPATH variable to point to your compiler. (We use the excellent GNU ARM Embedded Toolchain ourselves, which is super-easy to install on almost any Linux.) If you want to use STM32CubeMX with the Eclipse IDE, [kali prasad yadav] sent us PDF instructions — it’s not hard.

If you doubt that the availability of a free, open, and non-constraining toolchain can matter for a silicon vendor, we’d point to AVR and the Arduino platform that spun off of their support of GCC. Sure, Atmel still pushes their all-in-one wonder, Atmel Studio, which is better than the Arduino IDE by most any metric. But Studio is closed, and Arduino is open. We’d love to see the number of Studio users compared with Arduino users.

Congratulations to ST for taking a big step in the right, open-toolchain, direction.

28 thoughts on “STM32CubeMX Makes Makefiles

    1. God knows. Doxygen has turned out to be the bane of software engineering of libraries in my opinion, because it makes it too easy to generate useless documentation and then check off that task in your product release cycle.

        1. Haha, yes exactly. Kudos to SFML and shame to the other thing. I have no idea what SFML is, but taking a quick peek reminded me of another gripe I have about Doxgen-esque systems: there is no documentation of the relationship amongst the components — like timing, sequence, utility, etc. So you’re still left with a more-or-less flat surface of function signatures that you get to figure out what the relationship is amongst them.

          Again, my complaint is primarily that Doxygen-esque systems are meritorious in their intent, but they fall short on their delivery. Additionally, I think they have a toxic effect of serving as an analgesia for the pain of having to produce genuinely useful documentation for your projects/products.

      1. I curse Doxygen documentation every time I see it. It makes the code unreadable and it’s almost never up to par with real documentation.

        Of course, that may be an unfair benchmark. If Doxygen is providing an easy enough system that those represent projects that would have otherwise gone undocumented, maybe it’s a good thing. (AKA: better than nothing.)

        But meh. I have two monitors. Give me code in one and docs in the other any day.

        1. I curse Doxygen documentation because I know that it is 87% likely to be nothing but the function signature anyway, maybe with the parameters. Duh! I can see that without the documentation. (and this HAL library documentation demonstrates my point). It also gives me a finger-in-the-wind as to the quality of the code, or at least the risks in using it. If you’re not proud enough about the stability, utility, and quality of your code to invest in good documentation, then ‘caveat programmer’.

          There are chips/systems/services which I will not design in, because their support libraries are just too risky/expensive in work hours to get something useful. In the case of the STM products, I’m pretty happy. I would give them about a B to B+ on the library stuff. +points for coverage of functionality of the chips, -points for documentation on how to use it meaningfully. And the example code is toy code, but that’s been the case for many decades…

      2. True. I also inherited some Doxygen documentation and I’m working hard to get rid of that utterly useless crap by having both useful external documentation and readable/well-documented code.

    1. Code/style-wise: really different. Download and code up hello world stuff and you’ll see.

      opencm3 has less coverage, but is also a ton less bloated. And it’s open. ST’s libs say that they can only be used with ST’s parts. Opencm3 has some degree of cross-compatability with non-ST ARM chips, although the devs do most of their work on ST parts, so it’s still slanted.

      I still use the SPL for ST parts in C, so I’m not an expert, but I’ve played around with opencm3 and the HAL. Honestly, I wouldn’t hesitate to use any of them, although opencm3 will require you to know a little bit more what you’re doing because it’s a little rougher.

      If you want to help write future libs and give back to the community, go opencm3. If you just want to use the code and get running ASAP, go Cube/HAL. (IMO.)

      1. And if you want to use STM32F0 chips, don’t use libopencm3. It has major shortcomings for that family (at least, as of February of this year) that make it verge on useless. For a good, open STM32F0 library, I recommend ChibiOS, whose HAL can be used without an RTOS if you really don’t need one.

  1. Some years ago I chose the AVR for use in a mass-produced telecommunications product (a PABX multi-extension I/F card), primarily on its gcc support. (That was where PIC lost out) I’ve used the AVR ever since in private projects, because once you accumulate an understanding of the peripherals, and a code library to support them, jumping ship is unproductive. What I have not changed between PowerPC, V850, AVR, etc. targets is the toolchain – gcc & binutils handle them all.

    Writing makefiles is no big deal, especially if you have the O’Reilly book on hand. (Just don’t forget the tabs. ;-)

    1. Not hard, but if one is going to use a tool that generates code it makes it much easier to tie into everything else if it’s as clean as possible. There could even be said to be efficiency reasons for keeping it clean.

    1. Most binaries with debugging symbols have enough information in them for a reasonable debugger to pick them up and find their source files once you point them to the root of the source tree. The debug symbols gcc adds with -g or -ggdb can be read by ddd, eclipse, or DS-5 and probably a number of others. The trick is to get the debugger to find the source tree, which the makefile does not particularly help with. I’m an old fart though, so I usually use gdb or gdbserver, where you can use the directory command or -d cli option to specify the source search path.

    1. Agreed, you can download the asf libs separately and with the aid of the arm-none-eabi toolchain and custom Makefile, start developing for samd21s or other atmel/microchip parts under Linux. Downloading binaries can be done via Arduino bootloader or jlink which supports also supports Linux.

    1. Hot damn! I just read the blurb, haven’t tried the code yet, but that sounds like _exactly_ what I’ve been looking for. (In _any_ microcontroller family, honestly. For the last fifteen years!)

      Will check out. Maybe even review if it’s cool enough.

      Thanks, thanks for the tip!

      1. I agree that the CubeMX Software is handy for this purpose. But I find it only handy for the purpose of ensuring pin configurations do not overlap with/prevent proper function of attached peripherals during the schematic and board layout process. The code generation is absolutely horrid if you need to maintain your code base and actually understand it. CubeMX for planning and SPL seems like the happy medium. It would be nice if you could control the degree to which CubeMX generates code…

    1. Also realize that the complementary product, STM32 System Workbench, is essentially a packaged up gcc toolchain, openocd, and also Eclipse for C++ preconfigured. You don’t have to use the Eclipse part if you don’t want to, the gcc command-line stuff is accessible as well. Anyway, much easier setup than, say, yagarto of years past.
      The STM32CubeMX is essentially a options configurator (which is pretty wonderful for complex parts with a zillion clocking/pll options) which emits stuff like makefiles and skeleton code. If you’re careful about how you edit that skeleton code, you can round-trip back-and-forth with CubeMX changing things (which I sometimes have to do more frequently than I would care to admit).
      Some of the libraries leave things to be desired (USB), and fair warning, ST sometimes changes the libraries in incompatible ways between versions.
      But overall, it can get up up and running from scratch pretty quickly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s