#1

Hey folks, I’m starting to get into STM32 development professionally, and as a result have a side interest in starting to do more programming for myself on the side as well. At work we use the Eclipse IDE and are transitioning to use CLion/CMake. I thought I’d start a thread here on people using alternative build/debug environments for this platform on Mac/Linux and see what setups work for people.

To start with, who here uses something other than Eclipse, on a platform other than Windows, for STM32 development and are you happy with it / has it been a fairly smooth journey?

And if you use Eclipse on Mac/Linux, have you found any great tricks/plugins/tips to help make that a bit smoother? We’re having crashes on a regular basis and I find that Eclipse is just slow and generally annoying as a whole - especially when run in a VM (the STM chip I have access to through work is not supported by the Mac build yet, so I can’t run it on my home systems natively).

Last but not least, and I may be slightly tangential to my own topic here (and am happy to create two topics if it makes more sense), has anyone found a really excellent development kit or eval board for audio development or is everyone also rolling their own hardware at the same time? I’d love some recommendations for reasonably affordable STM32 dev boards for audio work - and SPI based codec daughterboards if you use one! There are so many choices I’m sort of drowning in them. :slight_smile:

3 Likes
#2

I’ve used plain Makefiles for Linux and it’s always been quite simple. Both ChibiOS and ST’s HAL.

1 Like
#3

I don’t have all the details in front of me (since I’m away from my primary dev machine) but a handful of things come to mind.

There is heavy use of the STM32 line within the eurorack space and many modules have open source firmware which is buildable on Mac/Linux (sometimes Windows). Generally these projects all use readily available non proprietary toolchains. Some projects might be worth a look are:

  • 4ms SMR
  • Mutable Instruments (several) - although there is a mixture of STM32 and AVR firmware in this tree which makes it a bit hardware to tease out an example
  • crow - not the most simple example but potentially interesting

At the end of the day most of these projects (and all of my random hacking) tends to boil down to:

  • arm-none-eabi-gcc - (various versions) for compiling (such as gcc 4.9.3)
  • make
  • openocd + st-util - to allow gdb to interface with the hardware.
  • emacs - as both editor and for doing source level debugging via gdb

The NUCLEO series dev boards from ST to be a relatively inexpensive place to start exploring. For example the NUCLEO-F429ZI (incidentally the F4xx chips are used in a lot of eurorack modules)

The nice thing about the NUCLEO series is that each board has an embedded hardware debugger (ST-LINK) which makes is easy to upload firmware and more importantly allow for using something like gdb to debug ones firmware.

Finally this may be of some interest but could be bit rotten by now. Several years back I tried to distill a minimal starter for projects on the F429ZI dev board: https://github.com/ngwese/stmbase. One oddity in that setup was I used waf instead of make.

…and I guess I should add that for a majority of my firmware hacking I’ve been fine using macOS. If there is a particularly critical tool which doesn’t run on macOS then I resort to setting up a headless Linux VM using vagrant

3 Likes
#4

My anecdotal STM32 experience is limited to firmware development in Windows using IAR back in 2011, but a cursory googling seems to confirm that most paths do indeed (unfortunately) involve Eclipse.

Debugging is a big deal IMO. IAR supported a JTAG debugger, which worked moderately well for setting breakpoints in the GUI and inspecting memory.

Pure gdb still trips me up when I have to use it though… maybe Eclipse would actually be better in this case?

#5

Does Eclipse have its own independent debugger implementation (that would surprise me)? I would expect Eclipse like most of other IDE/editors which support integrated debugging are effectively shells on top of gdb or lldb or whatever under the hood - looking at the Eclipse docs it would appear to support debugging via gdb.

Getting the basics working with gdb in combination with openocd unlocks a lot a lot of options because many different editors (vim, emacs, vscode, etc) have support/plugins for gdb which allow for doing source level debugging and variable introspection directly in the editor. The gdb + openocd combo does a nice job of abstracting away the differences between using a JTAG interface or ST-LINK interface to drive the hardware.

As an aside the ST-LINK interface embedded on their NUCLEO boards can be used to program external devices as well - I recently used this feature to update the bootloader on a pre-production crow module.

2 Likes
#6

Oh that’s worth the cost of admission for sure

I’d imagine it’s gdb, but presumably you can use the GUI to set breakpoints and whatnot?

These days I’m mostly used to using lldb inside of Xcode

1 Like
#7

It integrates the IDE with GDB. So far I’ve never had to actually type a word into the GDB interface to do anything, including managing breakpoints, reading memory/registers, etc. There are GUI integrations for all of this. You can hover over variables in the local scope of the breakpoint and see their types/values, explore structs, etc. It’s quite nice.

Precisely this - the STM32MP157xx boards we’re using have ST-LINK onboard which is very handy as well, though I do have access to ST’s JTAG/ST-LINK external debugger as well should I need it.

Thanks for the tips on the NUCLEO series, I’ll take a closer look at them.

For embedded ARM development? I’d love to hear how you set that up!

I can’t stand emacs (though no shade on you masochists who do!), and our team pretty much prefers to use one tool so we don’t spend too much time on idiosyncratic bugfixing/troubleshooting, but right now we’re trying to head in the direction of the CMake-oriented CLion (a JetBrains tool the rest of the team are intimately familiar with and apparently lightning fast in). Once of the tasks I’m trying to do is migrate the Makefile-based build chain to CMake, which I’ve actually apparently accomplished as of this afternoon - the .elf built successfully, but now I can’t figure out how to convince OpenOCD to find the remote module and send the .elf to it for loading. These MP1 series boards are a totally different beast from the usual STM32 series, since you load the MCU code through the Linux intermediary running on the A7 cores. But that’s neither here nor there…

It seems like should I decide to go down the NUCLEO/STM32Fxx series route, there’s some good experience here to get me set up quickly and that I shouldn’t need to worry about missing out on good IDE integration for debugging!

Regarding arm-none-eabi-gcc/g++/gdb/ld on the mac, you got those through Brew, I guess?

Not familiar with ChibiOS… doing a lot of FreeRTOS stuff at the moment. The HAL and I are becoming, well, maybe not friends but at least tight coworkers.

#8

I recently bought this book “Beginning STM32”. I think it targets readers that have used arduino, and want to try going deeper with the “blue pill”, which is a really cheap stm32 development board. I like it, it walks you through setting up the compiler/debugger/etc on a mac, linux, and windows machine. In addition it uses open source software rather than any proprietary stuff you might need to pay for!

My goal is to get introduced to the platform with this book, then start looking at some of those open sourced eurorack modules mentioned above, maybe i’ll finally understand some of this stuff : )

https://www.apress.com/gp/book/9781484236239

2 Likes
#9

I don’t think the standard set of brew packages includes cross compilers but a quick search turned this up:

The gcc 4.9.3 page I linked above includes prebuilt tar archives for several platforms including macOS. …or if you’d prefer something more associated with the more official looking ARM developer network there are newer builds of gcc available here:

1 Like
#10

No no, sorry, I meant that in the context of debugger usage… for general debugging, I’m mostly using lldb in Xcode for iOS development for my day job.

I suspect you could relatively easily configure a project to run a cross-compiler as the Build stage, but don’t know how easy (or possible) it would be to bind the debugger to ST-LINK

#11

I’d be curious to hear more about your ChibiOS experience. What types of projects have you used it on? Are any them open source? If so I’d love to see how they were setup.

#12

I’ve mainly tried to make various extensions to my mechanical keyboard firmware that’s based on a project called “TMK” which uses ChibiOS. I made a “small” controller board with an STM32F042, and also an adaptor board that plugged into one of the cheap STM32F7 dev boards with the touch screen, since I wanted to do something stupid like add a serial console and/or calculator/Forth-interpreter/something built into the keyboard itself.

It’s nice because I could write some things that ran side by side with the keyboard stuff without really having to worry about interactions too much. I found it easy to learn what was going on and things generally work as they were said to. I was able to move my project between a few boards that I made with different ST chips and that’s been easy. I made some progress bringing in the uGFX graphics library (also good if you can accept the licensing/price) and getting some text on the screen etc. It wasn’t quite as simple desktop development, but even for a small brianed javascripter like me it worked and I felt like I could keep things organized with different processes and mailboxes such.

All the really ambitious stuff didn’t really make it too far past the concept stage, though, and now that I think about it the last time I really sat down with it was the day before my son was born and he’s about to turn 2, haha… but the basic keyboard firmware itself for my small custom board is here:

1 Like
#13

Cool, I’ve ordered a Nucleo F466RE (ST-Link 2-1) and a Nucleo G431KB (ST-Link 3) for fiddling around with. Either one is fast enough to make a synth, since the Micromonsta is based on the F405 and it does just fine, and the main difference is the G431 is TINY (teensy-size) and doesn’t have a lot of pins, versus the F466 which is the midsize Nucleo-64 and should be able to handle most of the inputs I want to deal with. I’ve got different plans for each and will probably be using the G431’s onboard 12-bit ADCs while sticking a nice Cirrus Logic chip off the F466’s I2S port. I’m sort of using the Micromonsta as the inspiration for the fundamental structure, so that I can get on with the project quickly, and since it’s an extremely minimal and elegant circuit design, it makes prototyping easier too.

#14

https://leanpub.com/mastering-stm32 may be of interest. Well written, and all built around running your own CLI toolchain on any platform - ie, should be OSX compatible just fine. I certainly kicked the tyres briefly.

4 Likes
#15

I like that book (Mastering STM32) as well, really helpful and step by step.

I think the biggest thing that helped me get a proper development setup going was to realize that ST’s documentation is not very good or intuitive to beginners, so you need a resource like that book to guide you.