In a previous post, I shared my thoughts on what I thought are my two favourite mcus: the Raspberry Pi Pico, and the STM32. The STM32F411 seems a particularly popular choice. I have a blackpill, and I got a Nucleo F411 through the post today. So I have been having a little play with that. So, in my mind, it’s a shoot-out between which one will win my heart: the rp2040 or the stm32.
Here’s what I said in June:
- ARM leads
- STM32CubeIDE is bloated, slow, and the graphical configuration tool is confusing
- I favoured libopencm3 for STM, due to its simplicity
- I’d probably flip-flop between trying ideas on the stm32 and the rp2040
Having gained a bit more experience, my preferences have shifted.
I now “like” the stm32 MX. Sure it generates a lot of crud, but I’ve begun to embrace the crud and just ignore it. The MX will warn you of things like conflicts, and I can select the peripheral I’m interested in and just accept what it gives me, absent some juggling.
I’m taking a liking the HAL, too. And, by extension, the CubeIDE too, despite that I still haven’t changed my mind that Java is a pox. libopencm3 isn’t especially well-documented, and configuration is more painful than the HAL.
HAL is more powerful than RP2040 API. This is where STM32 is really starting to curry favour with me. The RP2040 takes a more blocking-oriented approach. This keeps things simple, but it is a drawback when you want to push the envelope.
Using the HAL, I have been able to set up PWM timing and SPI using DMA. On fact, I’ve gotten 3 SPI devices on the go: a SPI master as a “loopback” controller, a SPI slave, which I want to learn how to use for an audio project, and another SPI master to control a seven-segment display.
Although I had some fiddle with pin conflicts and with the way the Chip Select works, I thought that I got to grips with things relatively quickly. The MX tool was a great help here.
So, as you can tell, I think STM32 is in the lead at this stage. I had learned a lot about the RP2040 since it came out, but trying out the Cube helped a lot.
I’ve gained a little more knowledge on mbed, and gotten more into the groove of its workflow. It’s good for simple projects, but it does seem to be lacking when you want to use DMA, Interrupts, etc. and you care about performance. I’ve seen some posts where people have incorporated HAL into mbed, but in my view, I don’t think that’s a great win. Might just as well just use the HAL.
As an aside, I’ve recently downloaded software that implements a Zettelkasten (literally “slip box”). It’s a note-taking system, invented before the days of wikis. I’m hoping that it will help me remember all the stuff I need to develop software. The Zettelkasten was developed by Niklas Luhmann, a German sociologist. The Zettelkasten comprises a series of index-cards and a system of indexing. The cards, which contain “atomic” pieces of information, are then related to other cards in a web weaved by the indexing system. This video will give you a general overview.
I may post some blog posts on information I am building up. I have found a lot of blog posts are too long or irrelevant for my purposes. I think a lot of people could benefit from smaller, more focussed, posts.
That’s for the future, mind.