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.
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.
Sorry, I was digging on that too much time ago and haven't saved any links.
AFAIR, there is permanent busy state in certain conditions when functioning in SPI slave mode, unablility to reset TXFIFO/RXFIFO and some edge case with DMA and TXE/BSY when DMA failed and you don't know how many bytes are in RxFIFO.
Someone's in the Embassy matrix channel currently trying to figure out why the SPI driver is preventing the USB peripheral from enumerating on their G0…
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.
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.
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.
I've yet to see a MCU vendor ship without bugs. At least with ST,
the MCU is very cheap.
Moving the goalposts much? You went from "lengthy errata doesn't mean anything" to "at least it's cheap", which was my point entirely. The STM32 lineup is cheap with a bunch of features, has readily available documentation, and that appeals to a lot of people.
This feels more like an Apple bug to me considering how they work very
well on Linux, Windows and Android.
Yep, that's the typical STM fanboi response and part of why I'm not so gung ho on STM products. It just feels… cultish and obnoxious.
Meanwhile I've been using Macs on and off since before USB came around and this is the first USB device I've found that glitches out like that. Given that Apple uses off the shelf USB silicon (TI) and the complaints about STM's older USB FS peripherals I came across I'd fully believe it's an STM problem.
What is entirely STM's fault is that they still market the F7 based devices (ST Link, Nucleo, etc) as being Mac compatible. They've also skipped out on putting that fun little wart into the F7 errata.
I sympathize to some extent but really if popular products work for everybody else but not Mac, that sure seems like Apple ought to make it work even if technically it's not their fault, and I note that you've offered no evidence either way on whose fault this is.
Apple's products being shit in some ways isn't even a weird outlier, the company knows its loyal fans have nowhere else to go.
Nordic nrf series of chips are ubiquitous, cheap, really well documented and have very good support for the Bluetooth side of things in embassy.
If you don't need any of the wireless radio stuff, I think the raspberry pi microcontroller family is also ridiculously well supported in rust and it's possible to get one of the newer raspberry pi microcontroller is complete with ethernet and several megs of flash for not even 10 bucks.
probe-rs is amazing. In ARM land it works with pretty much any CMSIS compliant gear, and yeah you get debugging and logging on pretty much anything as a result.
I wish they had smaller modules with wifi (pico w is too large for many of my usecases). That's the only reason I keep using ESP-C*. It's getting better but the esp-rs tooling has a lot of very rough edges.
Same. Non-Espressif manufacturers have been sleeping on Wi-Fi capability. Nordic now has a chip, but I haven't tried it. I have been using an Esp running Esp-Hosted, connected to the main MCU over SPI.
It is a little bit complicated to start and understand how the series ESP-S* works, but as soon you do, everything gets better. It does have Wi-Fi and Bluetooth capabilities and also can be very small. A good example are the Adafruit Qt Py series. I am currently working with the Adafruit Qt Py (ESP-S2) and I am in love to that board. This one, doesn’t have Bluetooth, but the S3 does.
Because of the Xtensa, you need to use a special fork of Rust maintained by Espressif, but worth a try.
Just got my first esp32-c6 and really excited to start playing with it. The p4 looks like a beast and want to try that out eventually as well. Feels good to be back hacking on embedded again.
The way you wrote this and your previous comment above led me to believe your account is new. I checked it, 74 days at time of writing. I get the impression you haven't read the guidelines here. I like this place as it is generally civil discourse and have no qualms being the person that points you to the "In Comments" section of the guidelines.
I downvoted you due to the way you're communicating in this thread. Be kind, rewind. Review the guidelines here perhaps since your account is only a little over a year old.
I found this article useful and insightful. I don't have a bot problem at present I have an adjacent problem and found this context useful for an ongoing investigation.
Alas I work for a very large company who has a bunch of teams that makes prototypes for us to use.
However, a secondhand Quest 3 with unity in MR is the cheapest way to get started. It gives you SLAM/world frame of reference, which almost no other system does (apart from hololens)
Counterpoint: things like the Valve Index for VR simply don't behave well in this environment no matter how much I've worked on getting it there.
I'm not a novice either, $dayjob has me working on the lowest levels of Linux on a daily basis. I did linux from scratch on a Pentium 2 when I was 12. All that to say yes I happen to agree but edge cases are out there. The blanket statement doesn't apply for all use cases
IMO this is the real blindspot: it's VR support, not Photoshop, or MS Office, or CAD tools (all of which I've got running fine via Wine). I'm guessing the intersection between VR users and Wine users must be really small and I suspect it's because of this that support is so lacking.
Soulseek is likely the one you're remembering. I remember talking to people with similar collections of music. Hotline was my primary passion for quite some time but soulseek had a longer run of utility in my childhood on the nascent web.
What is logic here against the subjective internal experience you're responding to. Do I have to hold an axiom true to believe the person describing their internal experience is specifically as Chomsky proved in the language of logic?
I'm actually glad you posted this because it reminded me of a quote from Wittgenstein's page on Wikipedia [1]
> According to Wittgenstein, philosophical problems arise when language is forced from its proper home into a metaphysical environment, where all the familiar and necessary landmarks and contextual clues are removed. He describes this metaphysical environment as like being on frictionless ice: where the conditions are apparently perfect for a philosophically and logically perfect language, all philosophical problems can be solved without the muddying effects of everyday contexts; but where, precisely because of the lack of friction, language can in fact do no work at all.[259] Wittgenstein argues that philosophers must leave the frictionless ice and return to the "rough ground" of ordinary language in use. Much of the Investigations consists of examples of how the first false steps can be avoided, so that philosophical problems are dissolved, rather than solved: "The clarity we are aiming at is indeed complete clarity. But this simply means that the philosophical problems should completely disappear."
I try to tell all new programmers that ask me for advice that keeping abreast of the words of tools that are available for use is a big part of the work and shouldn't be left out. If I quit my daily / weekly trawl of what's out there, I'd surely start to atrophy.
Oh. Sounds like you're referring to Agile and Standup with capital letters. In my experience people talk about agile-with-a-capital-A and standup-with-a-capital-S and those two don't really match what actually happens in the real world, at least in my experience.
