Ramblings on developing stm32 vs raspberry pi pico #rp2040

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.


About mcturra2000

Computer programmer living in Scotland.
This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Ramblings on developing stm32 vs raspberry pi pico #rp2040

  1. Alessandro Ranellucci says:

    Great write-up with many interesting thoughts. Regarding the alternative approaches to IDEs, have you tried arduino-cli? It’s a command line tool which can be installed from Debian packages and called from your Makefile like you’re describing, but provides the same functionality of the IDE thus hides the low-level complexity of calling a compiler directly

    • mcturra2000 says:

      I have tried arduino-cli. There’s a bit of a learning curve to it, but I think it’s worth it if the project gets a little more complicated. Your post made me actually realise something. I decided to try out the official STM32 package (rather than the deprecated one by Dan). It uses the STMCubeProgrammer to upload the sketch, which also involves setting paths. Urrgh! But I now realise that if I had used the cli version, then I could just specify a Makefile rule that uses the standard st-flash, which would be way easier.

      I also seemed to have managed to install an RP2040 board for the Arduino, although I don’t remember doing that offhand.

      So I should probably revisit the Arduino software, as it will hopefully provide a uniform API. I know, for example, that the API for the STM8 is a little different. And I’m curious as to how timers would work, as the seems to RP2040 work on alarms instead of timers. It seems that the Pi has adopted a completely unorthodox approach. Unless I’m mistaken, which I very well could be.

  2. James Hughes says:

    Please note that the Pico, RP2040 and the entire Pi HW and SW range are produced by the Trading subsidiary of the Foundation. Foundation has no input to that development, it’s all Trading. So you should refer to Trading not Foundation, when talking about development of the Pi range.

  3. Pingback: More thoughts on #RP2040 vs #STM32 | Mark Carter's blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s