[cogman10]

I don't think that's what GP was saying at all.

The issue they bring up in more that hardware manufactures will have things like

    #define BLINKY_LIGHT_ADDR 0xDEADBEEF

in a standard set of headers distributed with their toolkit. That magic address is where you write to turn a light on or off.

Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that.

This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"

[bsder]

It's worse than that.

Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented.

"Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.

[steveklabnik]

That’s a fun example, because while you’re right, that may also be changing. Android’s new Bluetooth stack is in Rust, in my understanding. We’ll see if more vendors provide even more stuff in Rust in the future!

[cogman10]

Ah, good point. That would be rather tricky to solve.