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.

  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.

Sure, some do, but some are coming around and some were never there. Which is why it's important for a company like Adafruit to pick a manufacturer that is towards the open end of the spectrum. Unfortunately NXP isn't that manufacturer even if their silicon is more powerful.

Levis stuff has been made overseas for decades now. It's only with the more recent shift towards using cotton blends in nearly of their jeans that the longevity has suffered.

Nah, it's a spectrum. Companies like NXP and Infineon are at one end. NXP wants a ton of personal information to access even the most basic docs on some of its chips, sometimes even an NDA. Infineon won't even acknowledge you for the most part.

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.

Mostly I'm just leery of software defined peripherals being at the mercy of whatever community springs up around them, nothing specific. In terms of a Metro then yeah, something to slot in where the Due was absolutely with high speed USB, 10/100 ethernet, CAN FD, and all that jazz that wouldn't work on a $10 board. A SAMV70 successor to the Due?

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.

Right, but you're not really competing on processor speed. You're competing on maturity of peripherals where the RP doesn't really match up PIO or not.

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.

Which is still a far worse experience than if Cloudflare's services weren't needed.

  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

Doubt it. Of all the issues I run into with Siri none could be solved by throwing AI slop at it. Case in point: if I ask Siri to play an album and it can't match the album name it just plays some random shit instead of erroring out.

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…

Cortex-A includes a watchdog so yeah.

Considering the USB errata for the F7, I assume they didn't.

  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.

Of note neither the debugger nor user USB port on that board work with ARM Macs (guess how I found that out). You can connect it to a hub as a workaround but that may lead to data corruption (per the 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.

This would've been years ago. Both MacOS and iOS were insanely buggy (Tiger era). I think the lack of momentum is due to the fact that CardDAV is pretty darn simple, and CalDAV is… idk. Complex yet mature?

Also Xous which is completely independent of Embassy but applicable if you're looking for preemptive multitasking:

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

Embassy provides some traits, but it's pretty much expected you'll be using traits from embedded-hal (both 0.2 and 1.0).

  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.

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.

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.

I wrote a standalone CardDAV server ages ago and the biggest frustration for me was just how buggy the clients were. At some point I stopped self-hosting and moved on.

Until the humans are required to (or just plain want to) use LLMs to review the code.

With the original Arduino Due there was some fun undocumented behavior with the MCU (an Atmel Cortex-M3) where it would do random things at boot unless you installed a 10k resistor. From booting off of flash or ROM at random to clocks not coming up correctly.

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.

So I think you and the person you responded two are talking about two different things: developing software with and without a HAL.

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.

As a hobbyist who's written and is working on a couple of async HALs my take is that Rust is well suited to embedded work but yeah there are hurdles. It's immature so while things like Embassy are a joy to work with, they're missing a lot of (sometimes seemingly basic) features.

  Necessarily, LLM output that works isn't gibberish.

  they have a data bank the size of the internet so they can
  pull hints that sometimes surprise even experienced devs.

  it might turn out the balance is something like 25% handmade - 75% LLM made.

Ah, I see you have a JD from OpenAI.

I don't run personal sites worth millions of dollars. I do, however, use sites like Sourcehut, DigiKey, Github, Mouser, Farnell, etc, etc, etc. that have opted to put everything behind bullshit captchas because of the DDoS (nee AI) bots.