I was interested in getting external interrupts working on my black pill.
I found the easiest and most reliable way to get it going was using ST’s CubeIDE and MX utils. It’s probably the best way of getting a piece of hardware going in the first instance. It’s “automagical” nature is both a blessing and a curse. The code it generates is rather impenetrable, and there’s so much of it! I have recently put together a little bit of debugging code so that I can dump out some of the typedefs. I can then see what registers are likely to have been significant for configuring the peripherals.
The Cube is also somewhat hostile to git.
For something rather more compact, there’s libopencm3. I’m a fan of minimalism, so libopencm3 is more in tune with my way of thinking. My real criticism of libopencm3 is that it’s not really a HAL. There’s some wrapping, of course, but every mcu is different, so configuration of peripherals varies.
This presents a couple of problems: firstly it’s not especially portable between mcus, so it is missing a big selling point. Secondly, the differences can loom large. It is easy to miss a critical configuration parameter.
Since there’s no consistency, it is difficult to make examples that work on one mcu work on another. The lack of documentation, examples and recipes makes libopencm3 difficult to use. It’s not like the Arduino API, where everything is much more likely to work.
This leads us back to CMSIS. It is brutal in its simplicity. Nothing is hidden. Transparency is a good thing: there is no “mystery meat” lurking under the layer of pastry. Configuration can be rather hard going. libopencm3 is likely to be well-tested, though, so it has that advantage.
I’m actually toying with the idea of writing a templating system using the m4 macro processor. The plan is that this will generate CMSIS code for the mcu in question. So, it’s a similar idea to the Cube, but much more lightweight. And it’s more designed to augment, rather than replace. It’d be more of a cheatsheet than anything else. “Ah, so that’s the way you do it.” And them, of course, you could copy and paste the relevant bits, rather than leaving you to figure things out line by painful line.
Completely changing topics …
My dad brought down the xmas decorations today. It includes a little xmas tree lit up by LEDs flashed randomly by an STM8S.
Pity the poor STM8, that much unloved mcu by makers. It’s a shame, really, because they’re actually really nice chips. I like the form factor: smaller than an Arduino, but with a plentiful supply of pins. The ATtiny85 are nice chips, too, but sometimes you need more pins.
In some respects, the STM8 could have been an Arduino-killer. They’re nice simple, cheap, chips. I have compiled projects for them using the free sdcc compiler. It works well enough, I guess, but it has, shall we say, some “unorthodox” ideas. Although there’s nothing in the way of what you would call a “dealbreaker”, let me put it this way: I wish STM8 was supported by the GCC toolchain.
STM8 does have the advantage over the STM32 in that it is vastly simpler to set up and use. Sure, it only has one SPI and I2C, but it does support UART, and has quite a selection of timers. It has much to commend it.
It does raise the question as to why the Arduino became to be so popular amongst makers, whereas perfectly fine chips like STM8 did not. We could posit all sorts of rationales and clever arguments about why Arduino took the maker market by storm. But I think the reason that they did was mind-numbingly simple: it’s because they tried. They integrated everything together into a solution. There’s a compiler ready to go. And an IDE (I didn’t say “good” IDE) where you can type your programs in, and a button that you can press so that you can upload your code. Actually, the Raspberry Pi Pico isn’t quite there in that regard.
Just my random thoughts.