As a companion to Bobbin CLI, I've put together a repository that has bare-bones Blinky code for most of the devices that I have available - 22 in all at this time.
For now, these are all boards based on ARM Cortex-M MCUs, but I expect to include boards based on other chips over time. There are currently examples using various STM32 MCUs, Kinetis KL26Z and K64F, TI TM4C129, NXP S32K, EFM32, SAMD21, nRF51, and even Ambiq Apollo.
Arduino Zero, Adafruit Feather M0 and Teensy are also included, as well as the cheap $2.00 Blue Pill STM32 boards.
This is not a repository that you will want to use for doing real development, unless if you want to teach yourself how these chips work at the datasheet level. It's real purpose is to provide end-to-end validation of a toolchain install, including the firmware on the development board.
Sometimes you simply want a program that makes your board blink so that you know that everything is working.
I've also started to do some low-level stuff with Cortex-M MCUs and Rust, although I'm starting a tiny step further up by using the svd2rust bindings and the cortex-m-rt framwork by @japaric to get rid of a lot of manual boilerplate code which you'll need as soon as you leave the endless-blinking-loop territory.
Yes, programming in this style is pretty tedious, and it's not practical to go too much further with this approach. This exists mainly so that I have a library of known good binaries for diagnosing people's toolchain installations and occasionally for getting certain development boards out of reboot hell.
Still, it's a fun way to get familiar with a new MCU, and a valuable exercise for a programmer new to embedded programming to go through. It forces you to learn how read a datasheet / reference manual, perform basic bit manipulation and use a debugger.
It's good for someone coming from a more traditional background to understand right away that embedded programming is all about reading and writing bits in memory. Once they're comfortable with that concept, you can start moving back up the stack.
The opposite, I'd say: It's rather easy but very error prone.
Having done this low-level poking for many years and trying to profit from the benefits of Rust I'd actually prefer if there was a simple but safer way to do low-level stuff. svd2rust brings you almost there with the biggest disadvantage being that you need a different crate for every single MCU family directly followed by the next disadvantage that API is ever so slightly different and the automated documentation is pretty much completely unusable.
Still, your work is quite admirable and very useful to test your outstanding Bobbin CLI tooling. So definitely a tip to the hat from me.