Comment by inferiorhuman
1 day ago
STM is popular because their lineup is cheap, offers a lot of features, and the documentation is readily available. The flip side is that their errata is lengthy, the Rust HAL is complex to support lots of different designs under the same product names, the documentation from STM is poorly organized and spread out over a zillion different documents, and Mac compatibility needs a gigantic asterisk. You can also get a BlackPill (get the F411 version with 8MB flash) off of AliExpress for $0.99 from WeAct's official store. Unlike STM's own dev boards (Nucleo) you'll need a separate debug probe. Nucleos that'll give you a lot of breathing room can be had for $10-15.
RP is also cheap and has that pretty sweet programmable GPIO and documentation that everyone seems to love. Adafruit has an RP2040 Feather for $12, RP2350 for $15, or with an ESP32-C6 (RISC-V) for $15. NXP has chips with similarly programmable GPIO but they're not well supported by Rust. The RP's PIO stuff is bonkers and potentially very interesting if you wanted to make random protocol dongles. VGA out? Why not?
Nordic stuff looks pretty sweet (and their Bluetooth support seems well loved) but is generally a bit expensive. Dev boards are available from micro:bit and Adafruit, among others.
I've been working on a HAL for an older Atmel SoC and absolutely loved the documentation. But Atmel stuff is expensive. Quality of the Chinese clones is iffy. I set myself back a bit by bricking my one board but am hoping to have a beta release in a month or so.
More recent Atmel/Microchip stuff (D21, D51, E51) has a HAL that the Embassy folks seem to have overlooked. You can get them on Adafruit boards at varying price points.
Or just pick something unsupported and start writing a HAL. It's a great way to get up close and personal with how everything fits together.
The one thing I wouldn't do is get some high end thing to start with. Teensy's (NXP i.MXRT) pack a lot of punch but even their native Arduino libs don't really let you exploit the power. STM's H7 series as well, they're way too complex to use as a learning tool even if they are fairly cheap.
> The flip side is that their errata is lengthy
Just like security bugs, lengthy errata doesn't mean anything. A popular MCU will have bigger errata sheet because it gets more eyes on it.
>documentation from STM is poorly organized and spread out over a zillion different documents
The spreading out over multiple documents is good organization. You don't want to combine your datasheet, reference manual and appnotes into one.
> lengthy errata doesn't mean anything
In STM32G0 for example, there is "SPIv1" peripheral which has very critical implementation bugs which can get SPI to completely stuck until reset by RCC.
There is very brief mention in STM errata about this, I had to dig up forums and dance up with SWD around this.
Which G0 part is this? Can you point me to one of these forum posts?
2 replies →
Yeah, no. From all outward appearances STM stuff is basically rushed to market, fix the bugs later. We're talking basic shit like xyz clock input or watchdog straight up doesn't work. More advanced stuff like one of their USB controllers straight up doesn't enumerate with ARM Macs — still not in the errata or marketing materials BTW although the workaround may end up beating you with some other bugs. Or the one family that they had to completely rework the USB peripheral while subtly changing the part numbers. Or yeah no.
> The spreading out over multiple documents is good organization.
No, it's really not. It's things like reading up on a peripheral in the reference manual and then trying to figure out which pins you can use with it. Some vendors will put that in the section with each peripheral, most will include a table within the RM, and STM splits it up into multiple documents — per variant within a family because the families are often loosely related.
None of this stuff is offered up in printed form, they could at least hyperlink it (whether intra- or inter- document).
It's not that surprising really. You've gotta cut costs somewhere.
>rushed to market, fix the bugs later
I've yet to see a MCU vendor ship without bugs. At least with ST, the MCU is very cheap.
>USB controllers straight up doesn't enumerate with ARM Macs
I've seen USB devices struggling to enumerate on Mac/IOS devices before. This feels more like an Apple bug to me considering how they work very well on Linux, Windows and Android.
2 replies →