Posted by bryceschober on 2017-05-16 18:11

I did some evaluation myself, and they both solutions have big warts.

Things that I don’t like about Keil:

• Obviously, it costs a lot of money
• Its GUI is really rather old and cluttered
• Its c++ compiler is only up to c++03, which is really rather ancient
• Its debugger is supposed to be super-awesome, but in my time so far, I haven’t really missed its extra features that I know of

Things that I don’t like about SW4STM32:

• Eclipse’s GUI is complicated and cluttered, though in a different way than Keil
• The ST-LINK debugger integration is pretty fragile, and lots of things can go wrong with it. Not sure if the story is better when using a different debug adapter.
• STM32CubeMX and SW4STM32 emit different “dialects” of XML, so if you’re committing everything to a shared source repository and working with others, in multiple rounds of configuring with STM32CubeMX, you get a lot of commit-difference noise.
• The higher-level STM32Cube middleware is pretty mediocre in quality and hard-wired. The low-level interfaces can now be used in recent STM32Cube versions, but then you’re doing a lot of heavy lifting yourself.
• The “OpenSTM32 community” isn’t really that open at all: No open-sourcing of components and registration required for all downloads & documentation.

In the end, using modern C++ was a high enough priority, and we intended to build a lot of our own middleware, that we’re sticking with SW4STM32 for now. I’m still interested in trying out the GnuARMEclipse distribution that has some better plugin support, and isn’t specific to the STM32, but the installation process is a huge pain, with a billion different components to download and install and configure.

If you have the money, don’t care about modern C++, and you want to be able to use quality middleware, I’d go with a mid-grade Keil with middleware included. I intend to reevaluate Keil myself, when they support the newer clang-based ARM compiler v6 with modern C++ support.