Bobbin CLI is a command line tool to make it easy to build, deploy, test and debug embedded devices using a unified CLI.
I've written a blog post, Bobbin CLI: Getting to Blinky describing the motivations for this tool and what it does. The short version is that it's a tool designed so that you can do this:
$ bobbin run
Compiling blue-pill v0.1.0 (file:///home/bobbin/bobbin-hello/blue-pill)
Finished dev [optimized + debuginfo] target(s) in 0.13 secs
text data bss dec hex filename
152 0 4 156 9c target/thumbv7em-none-eabihf/debug/blue-pill
Loading target/thumbv7em-none-eabihf/debug/blue-pill.hex
Complete Successfully flashed device
Loader Load Complete
Console Opening Console
Hello World 1
Hello World 2
Hello World 3
^C
$
with a wide range of development boards and debug probes.
Currently Bobbin CLI works with
ST-Link/V2 and ST-Link/V2-1 (STM32 Discovery and Nucleo development boards, including optional SWO trace output)
J-Link (Standalone debug probes and included in many development boards)
DAPLINK / CMSIS-DAP (Used in many development bards)
Blackmagic Probe (popular open source debug probe)
TI ICDI
Bossa (Firmware uploader for Arduino-compatible boards including the Arduino Zero and Feather-M0)
Teensy Loader (Firmware uploader for Teensy boards)
DFU-UTIL (USB DFU firmware uploader)
Only macOS and Linux are supported as hosts at the moment, but there's work being done to make it run on Windows.
My original motivation for this was to scratch an itch - building an CI infrastructure capable of supporting dozens of connected embedded devices per host. But just as important is making it easy for someone new to embedded Rust programming to go from plugging in a dev board to having a running program.
The long term goal is to make it easier to go from a clean Rust installation to a working embedded toolchain than it is to download and install the Arduino IDE.
Bobbin CLI should build and run fine on RPi3, but I expect that Rust compilation performance would be a bit slow for anything but toy projects. I'm hoping at some point to support some kind of remote compilation / deployment mechanism to address this, allowing you to do a build on a fast server and then automatically ship the binary to a deployment server.
I have also heard of using OpenOCD and Raspberry Pi GPIOs load and program devices directly via SWD.
That's an interesting question - I've wanted to do bare metal on RPi3 for a while but haven't had the time to try it out. This was a good excuse to spend a bit of time looking at what's involved.
The answer is "probably, but it's complicated".
As far as I can tell, the Raspberry Pi does expose JTAG pins, and it should be possible to configure OpenOCD with a debug probe that can connect to it as a target and launch it using Bobbin CLI. If you simply want to attach to a running Pi and debug it, this requires some GPIO configuration on the Pi side to set the pins to JTAG mode first.
If you want the Pi to boot into your bare metal code, that's a bit more involved because the Pi only boots from the SD card (the GPU actually boots first, reads from the SD card, sets up the ARM CPUs, then starts them up).
Assuming you don't want to manually update and replace the SD card every time you make a change, you need to put a bootloader on the SD card that will load your binary using some other method. https://github.com/dwelch67/raspberrypi has a bootloader that will load a binary from the UART using xmodem, and there's at least one bootloader that will load over Ethernet: https://github.com/Nvreformat/Etherboot
Bobbin CLI doesn't currently support either approach, but I am planning on adding the ability to support firmware upload via serial port using both Xmodem and the STM32 serial bootloader protocol. I think that would do the trick.