There has been lots of reviews on the capabilities of various uCs (microntrollers), comparing them with their price, and so on. Most people are further along in their journey in understanding, so this post is written from the perspective of someone who is feeling their way around. I’d class myself as an intermediate uC programmer: someone who has climbed at least a few rungs on the microcontroller ladder, but I’d probably look hopelessly naive compared to the grizzled war-dogs.
The purpose of this article is not to weigh the pros and cons a nuances of blue pills vs black pills, Arduino this vs Arduino that, etc., but to try to give a sense of what it has felt like to be a developer for various uCs. I’ve had exposure to: Arduino Uno/Nano, ATtiny85, stm8s, stm32 blue pill, ESP8266, ESP32 and Raspberry Pi rp2040 pico. I’ve had a go at bare metal programming for the Raspberry Pi. My prompt for this blog post is my recent purchase of an stm32f411, and whether I want to side with the Pico, or the f411.
ARM for the win. I’m thinking of standardising on a processor architecture, rather than continually flitting about. The great thing about ARM is that it’s like C/C++: it’s absolutely ubiquitous, there are standard toolchains, and it’s guaranteed to work. You just can’t go wrong.
I can see a place for still using the ATtiny85 for when I want to make something small. I have a couple of projects involving Nanos, which I will keep going. One thing I’d say, though, is that we seem to be shifting towards 3V chips, which makes the 5V of the Nano less interesting. The Arduino Uno/Nano is still the best introduction to UCs though.
IDEs suck. The Arduino IDE is the best out there, but that’s not saying much. It’s better than the abomination that is STM32CubeIDE. What is that thing? Something based on Java Eclipse? Whatever, it’s as slow AF. And I can’t make head nor tails out of the graphical configuration tool. It’s like staring at the controls on an airplane cockpit. Everything is there, assuming I know where to look. Which I don’t.
Actually, programming tools is the reason I’ve decided to skip other architectures. PIC processors seem intriguing, but I don’t want to have to install somebody’s bloated proprietary IDE just to compile a file.
My idea of a programming environment is a Makefile, vim, and a compiler that I can install from Debian. That’s the great thing about ARM. I can be sure I can get a well-supported compiler from my distro. I can use the AVR compiler and library for my Atmel chips if I have to. I liked the stm8 as a chip, but the free compiler – sdcc – has some of it’s own ideas about how things should be done. I’d rather it do standard things in standard ways.
Libopencm3 looks good. So, having decided that stm32’s look a good bet, we now move onto the question of what library – if any – we should use. There’s a bewildering array of choices: CMSIS, SPL, HAL, mbed, and a variety of real-time operating systems to choose from.
SPL seems deprecated. HAL just seems too difficult, too bloated, and a cure that’s worse than the disease. mbed seems a bit of a mish-mash, a skyscraper with foundations of shifting sand. Why does it keep saying that features are deprecated?
Having become disillusioned with these tools, I decided to write some code using bare registers and a datasheet. Writing out the data registers manually was perhaps not the greatest idea ever, although it did teach me a lot. A better way would have been to try to figure out how to integrate CMSIS, as it is basically a big library of register definitions.
So I think that if you really want to learn about a (ARM) microcontroller, then your best approach might be to create a blinky light program using no external libraries, and just register definitions. Once you’ve done that, then you can say “hey, I know how basic low-level register manipulation works”, and then try the same exercise again, this time integrating and using CMSIS.
You might like to try creating some SPI libraries. Have a go – it’s perhaps a little more difficult than it looks. It’s tricky to get going from the datasheets, although I did manage with a lot of help from Google.
Which brings me to libopencm3. It’s a nice little abstraction library. It seems small – unlike HAL. There’s no git submodules or any fancy tricks into compiling it. It just uses a Makefile. Imagine that! An honest to goodness Makefile. I don’t have to download a multi-hundred megabyte monstrosity. It compiles all its supported architecture in a oner. It doesn’t take long, either, so I’m happy with the general setup.
It could certainly use more examples and documentation. It does document the whole of the library using doxygen, though, which is useful to browse through. You can even view the source files themselves from the documentation. You can see how the SPI functions are implemented, for example.
The code looks quite clean, too. There’s not layers upon layers upon layers of abstraction. So if you wanted to write your own implementation of SPI, for example, then libopencm3 looks a good bet. But you could just use libopencm3, and have reasonable assurance that it’s at least as good as something you could implement yourself.
So although I am new to libopencm3, I’m finding that it fits in with how my brain works. I want to dig deeper.
Don’t forget the Pico. The Pico doesn’t have any CMSIS definitions, nor support from libopencm3. They have their own SDK. There is some set-up effort required, but it is well-documented. In fact, the whole of their SDK is well-documented. This is why the Pico is eminently worthy of investigation. The Pi Foundation have thought things through, and I’ve made a lot of progress in understanding how the thing works. Their SDK is good, and I don’t really see any reason not to use it. Projects need to be built using cmake, which some might object to. However, I consider it a minor bump considering what else I get for my money.
Conclusion. My current thinking it to operate a dual strategy, switching between the Pico and the STM32 as the mood takes me; favouring libopencm3 for the latter development. I’ll occasionally dip into the Atmel chips as conditions warrant, but I’ll consider it a side issue in favour of the ARM chips. The black pill that I recently purchased has DAC and DSP capabilities, and I’m keen to explore that functionality for some audio work that I’m interested in.
Just my 2 cents. Have fun, and stay safe.