inferiorhuman
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.
What is interesting is that HN seems to have reached a crescendo of AI fanboi posts. Yet if you step outside the bubble the Microsoft and Nvidia CEOs are begging people to actually like AI, Dell's come out and said that people don't want AI, and forums are littered with people complaining about negative consequences of AI. Go figure.
Rust assumes a runtime, the standard library assumes a stack exists, a heap
exists, and that main() is called by an OS;
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.
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.
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.
I swear I was doing just fine with it booting reliably until I decided to try flashing it over the SWD interface. But wouldn't you know it, soldering a resistor fixed it. Mostly.
The hope that they'll run out of relevant material is slim.
The rise in ARM brought about quite a bit of standardization. You're no longer bound to vendor specific compilers and toolchains. Insofar as you're willing to essentially reimplement large swaths of the HAL you're able to BYO dev environment. Of course all of this is also subject to the quality of the CMSIS packs and documentation put out by vendors.
This is true with Rust as well, and in this capacity Rust is quite mature and well supported for Cortex-M stuff (and to a slightly lesser extent Xtensa and RISC-V). The tools to create thin wrappers around the registers (so called Peripheral Access Crates — PACs) are pretty well fleshed out at this point.
If you're looking for a equivalent to first party HAL to leverage (e.g. CubeMX, Atmel Studio), Rust is significantly less mature here if only because of its age. In Rust land there are multiple different HAL frameworks to work with and it's likely you'd need to use a combination of them. Embassy (a combination of an async framework and HAL components) is pretty slick if it does what you need.