This will be effectively a copy of my previous post, but targeted at OS X. The gist is, get a toolchain, debug connector, and open-source firmware library set up to use the STM32F4DISCOVERY dev board from ST as quickly as possible on OS X. Unfortunately, it’s not QUITE as easy as on Ubuntu. Fortunately, it’s not a lot worse.

Prerequisites

The first thing to take care of is getting the necessary OS X tools to get going. These include Homebrew and the Command Line Tools for Xcode. We’ll start with the latter.

1. Head to https://developer.apple.com/downloads/index.action. You’ll need to log in with an Apple ID.
2. Do a search on the left for ‘command line tools’ and pick the newest one.
3. Click the download link on the right. Note, it’s pretty beefy, just over 110MB.
4. Open the new disk image you’ve got and double-click the .mpkg therein.
5. Click next a bunch until the tools are installed.

This will take care of installing the appropriate desktop compilers, as well as an appropriately new version of git.

Next up is installing Homebrew. This couldn’t be simpler. Open up a terminal:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

(Thanks for the update, Graeme!)
Enter your admin password when prompted, and click through until you’re done. Just to be safe:

$ brew doctor
Your system is ready to brew.

 Install the toolchain

Conveniently, the PX4 Autopilot Project has created a Homebrew formula to make installation super easy, not that it really does all that much you couldn’t have done by hand. We’ll use the 4.7 GCC branch:

brew install https://raw.github.com/PX4/homebrew-px4/master/gcc-arm-none-eabi-48.rb

(Thanks for the updated, Graeme!)
Boom. Toolchain ready to go, on your $PATH. Easy as pie.

Install stlink

Again, we’ll use Texane’s stlink to talk to the STLinkV2 debugger on the board.

brew install automake autoconf libusb libusb-compat pkg-config
sudo easy_install pyyaml

cd
mkdir Development && cd Development
mkdir embedded && cd embedded
mkdir tools && cd tools
git clone https://github.com/texane/stlink.git
cd stlink/
./autogen.sh
./configure
make

 Install the firmware lib and examples

(NOTE: The rest of this is basically copied verbatim from the last article.)This isn’t strictly within the scope of setting up a dev environment, although I guess one could make the argument. The main point of including it is to get you (me) up and running with some example code to play with ASAP. ST distributes the STM32F4DISCOVERY with a firmware library that’s pretty useful and complete, but I haven’t really looked much into the licensing, and anyway it’s very much oriented towards the commercial toolchains and really development environments ST supports out of the box (Keil MDK-ARM, IAR EWARM, Atollic TrueStudio, and Altium TASKING VX). I found it was quicker simply to use libopencm3, the new kid free-as-in-speech-and-beer ARM firmware library. Conveniently, it includes a bunch of good examples too.

cd ~/Development/embedded/
git clone https://github.com/libopencm3/libopencm3-examples.git
cd libopencm3-examples
git submodule init
git submodule update
make

Testing everything

We should now have all the examples, as well as libopencm3 itself in a subdirectory, so let’s go try to build one and load it to our dev board.

cd examples/stm32/f4/stm32f4-discovery/miniblink/
make

Everything went alright? Great! OK actually I lied, when we ran make before that actually built all the examples as well. Anyway, it was required to compile the library componets before making the examples, so now if you modify miniblink.c you can easily remake it. Anyway, we’ve now got a .elf to load. You should plug in your dev board now. In a new terminal, start stlink:

cd ~/Development/embedded/tools/stlink/
./st-util

It ought to connect to the on-board ST-LinkV2, listening for a debug connection on local port 4242. In the previous terminal where you made the miniblink example:

arm-none-eabi-gdb

from the (gdb) prompt:

(gdb) target extended-remote :4242
(gdb) load miniblink.elf
(gdb) continue

This should start blinking the green LED on the dev board. Now, edit miniblink.c, remake, and get going on more fun stuff! (HINT: The green LED corresponds to GPIO12. The orange, red, and blue LEDs are GPIO13, GPIO14, and GPIO15, respectively. They all happen to be on port GPIOD).