It has its warts, but I had the opposite experience in general. Bringing up peripherals on ST has been easier than all other vendors I’ve worked with (TI, renesas and the older PICs) TI was the worst code I dealt with.
Anyone complaining about STCube has never used anything worse.
My nomination for worst code generator would be MPLab Harmony. I was unfortunate enough to be one of the first victims of the PIC32MZ line, which didn’t have a middleware library, or non-harmony code examples. It was autogenerated code, or read the data sheet and figure out every peripheral yourself. The code generator was so broken even the most basic modifications to get example code running on a custom board would result in non-compilable code. The experience was so frustrating I just respun the board with a different micro.
I’ll never touch any MCU that uses MPLabX again. Bonus points to Microchip for destroying atmel studio in favour of MPLab, now I have yet another family of microcontrollers I will not touch.
One thing I can say about STCube is the code it generates works, and you can always use it as a jumping off point for tweaking the generators code for your exact use case.
One genuine complaint is that the catch all interrupt handling is often too slow actually use, so you end up overwriting the default handlers, or becoming very proficient with DMA.
Another very important thing is to never intertwine your code with the autogenerated code. Keep the application code and the hardware code seperate, and have an actual “HAL” layer in your code. It’s an easy way to prevent your code from getting nuked when you reconfigure, and if you’re not happy with the autogenerated code just sub in your own functions. Best of both worlds.
Vendor tools like this exist to lock in developers and teams who can't, or won't build their own environments. There's a short on-ramp for embedded programmers who aren't necessarily software experts but the price is they dig themselves even deeper into an undesirable situation in the long term.
Except that ST has open-sourced their toolchain, and their libraries [0]. I can write C or assembly code on my Linux laptop and get it on my ST devices without anything proprietary from ST.
If nothing else the vendor-specific crappy toolchains do support the vendor’s HW well, so that’s something they need to do so that devs don’t have to start their projects with implementing the low-level support by themself.
Very good? Zephyr generally wraps the hardware SDKs for the things built into the microcontroller. And then their own portable drivers for any outside peripherals, like I2C/SPI/Onewire/etc.
I haven't found STM32Cube to horrible, I've certainly have seen worse. Its works for getting the hardware up and running quickly, and then refactoring away from the generated code. The underlying libraries aren't too bad.
Yeah it's fine, for a while it was refusing to start for me on archlinux but after deleting some library as per the suggestion of one guy on their forums it's working pretty good.
Shops that actually make their living building and shipping quality and competitive embedded stuff, mostly used IAR in my experience.
Default free tools are great for students, hobbyists or selling low volume widgets without warranty to other hobbyists, but if your livelihood depends on it, you pay for IAR, Keil or Lauterbach tools, no questions asked.
The stability, technical support and timely bug fixes, compiler documentation (especially along the undefined edge-cases of the C language), testing, debug and trace capabilities, are worth their weight in gold.
I have learned to hate IAR Embedded Workbench in the two years that I've been forced to use it. It will just randomly refuse to give me a function/method list or claim it doesn't know where a value is defined. I'm not much of a fan of Keil products either.
I would use VScode for everything if I could. But for the life of me, I can't get debugging working in VS Code, using the IAR plugins and a j-Trace/j-Link. Works fine with ST-Link though, go figure.
Can't. Our development process requires using validated tools and we would have to validate a new version. A fix for this would not be worth the validation cost.
You need hot-swappable barf bags to read the output from their damn code generators. Despite being a code generator >90% of the output is dead code hidden inside a giant ifdef maze.
Instruction set is ARM, sure, but to drive peripherals you need to use their horrible C code or write the driver stack yourself by reading hundreds of pages of datasheets.
You can also use third party libraries. I have written projects using ChibiOS and libopencm3 and their driver model was actually OK to use, although for most peripherals you still need the datasheet to understand the exact capabilities of the device.
