I really like F3 and F4 discovery boards. You can re-flash dedicated stm32f1 with blackmagic probe (instead of ST-Link) and bridge UART to it to get really awesome development board.
After this is done you'll get /dev/ttyACM0 and ACM1 for GDB interface and UART bridge. From GDB you can connect to it directly with 'target extended-remote /dev/ttyACM0' (no need for OpenOCD middleware).
It implements GDB stub directly so you don't need to run OpenOCD to be able to attach to it from GDB.
Also UART bridge is nice but this might be supported newer in ST-Link too. I haven't used STLink for a while - flashing all the stuff with blackmagic right away.
I'm curious about the uses of the UART bridge. I've only used small chips with few pins to spare, so I've always used RTT or semihosting for logging. Is there an advantage to doing that using the UART instead? Or is the UART bridge for something else entirely?
The STM32 board includes an STLink programmer which you can use via OpenOCD. The EFM32 board includes a J-Link programmer and the IDE comes with the JLink command line tools. You may be able to use it via OpenOCD too, but I haven't tried that.
I prefer the EFM32 peripheral library (efmlib) to what's available for the STM32, which is either the old clunky Standard Peripheral Library or some new thing that's closely tied to their awful IDE.
If you use the EFM32 and the JLink software you can log using RTT (https://www.segger.com/jlink-rtt-viewer.html), which is much faster than using semihosting, which is the most straightforward option with the STM32.
The STM32 board has the advantage that you can set it up as a programmer by removing a jumper, whereas to set the EFM32 board as a programmer you have to load the horrible IDE and click buttons.
It's generally fairly easy to compile code for these chips using the arm embedded gcc toolchain:
The only tricky part is finding (or writing) a suitable '.ld' file. You can usually find one by poking around the files included with the IDE or with the peripheral libraries. In principle you can just write it yourself, if you know enough about ARM architecture, but that's above my pay grade.
Anyway, take all the advice above with a pinch of salt -- I'm no expert on this stuff. But sometimes the perspective of a relative newbie can be useful too.
I learned using the Silab's Zero Gecko starter kit that you linked to. As someone whose only other microcontroller experience was a few simple led projects with an arduino, I found the gecko family's tools and docs incredibly helpful and intuitive. It really helped me learned all the ins and outs of the Cortex M, such that I was able to build my own hardware programmer/debugger after a few weeks of tinkering.
The newer ST's HAL library is not that bad, and is definitely not tied to their IDE. The STM32CubeMX has pretty decent pin and peripheral configuration tool (definitely better than spreadsheet) which generates project skeleton. After that, you can use SW4STM32 (eclipse packaged with arm-none-eabi-gcc) or commercial IDEs. You can also use plain old make if that's what you prefer.
There are also other fully open options for STM32- libopencm3 (just HAL) or ChibiOS (an RTOS with HAL).
>The newer ST's HAL library is not that bad, and is definitely not tied to their IDE.
Fair enough. I'm sure the library itself isn't literally tied to the IDE, but it's not easy to find as a separate download, and there is little example code available online for the HAL library.
> libopencm3
It's a nice project, but I prefer to use vendor-supplied libs unless there's a good reason not to. Efmlib has a permissive license and seems pretty nice from my relatively limited experience of it.
>You can also use plain old make if that's what you prefer.
This is the thing. I really want to be able to easily set up a project just using GNU make and the regular arm gcc toolchain. I've found it easier to do that on the whole with the EFM32.
