Of course I wouldn't vibe code in a serious production project, but I'd
  still use an AI agent, except I'd make sure I understand every line it
  puts out.

Thanks.

  Rust assumes a runtime, the standard library assumes a stack exists, a heap
  exists, and that main() is called by an OS;

Source: I'm writing Rust without a runtime without a heap and without a main function. You can too.

Companies like STM, RP, and TI are at the other end. STM got super popular because they're cheap and the documentation is incredibly easy to get at. I think RP is following suit.

Renesas puts out some documentation, but it's really rough. Anything that has even a whiff of crypto is completely undocumented. They're also squatting on a few Rust crates where Espressif actually hired a Rust developer to work on their Rust HAL. The most comical thing is that while they version their reference manual they don't seem to update it and instead issue a ton of broad errata that apply to multiple manuals.

Before the acquisition Atmel's documentation was well written and organized.

NXP just seems antithetical to an open platform. Then again Arduino went with Renesas, and they're… not great.

Otherwise it's the openness that would pique my interest. SWD headers, yes 100%. But also the documentation. No half-assed SVDs, buggy closed source flash algorithms (Microchip), wholly undocumented peripherals (looking at you Renesas), stuff like that.

Edit: I see you're comparing it to the 3.2 but I suspect most folks are going to be comparing your offering to the 4.x.

  Why do you say it doesn't solve loads of things? 

  Um if I ask an LLM about a fake band it literally say I couldn't find any
  songs by the fake band did you type is correctly and it's about a millions
  times more likely to guess correctly

  I've yet to see a MCU vendor ship without bugs. At least with ST,
  the MCU is very cheap.

  This feels more like an Apple bug to me considering how they work very
  well on Linux, Windows and Android.

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.

Also worth noting that the discrete STLink V3 dongles also use the F7 for USB stuff.

Also also worth noting that not all of the Embassy examples are set up to work with Nucleo boards. It's an odd choice but it is what it is.

  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.

> 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.

https://www.youtube.com/watch?v=DaWkfSmIgRs

  IMO one of the big reasons Arduino stayed firmly hobbyist tier is because
  it was almost entirely stuck in a single-threaded blocking mindset and'
  everything kind of fell apart as soon as you had to do two things at once.

Conversely Embassy suffers from being immature with some traits that haven't really been fleshed out sufficiently.