[AceJohnny2]

> After nearly 20 years writing embedded code I'm really (really really really) tired of C. The embedded systems community really needs to embrace better tools.

Hear hear, brother!

I get particularly frustrated about the second point, and I've made it my career goal to get my teams to update their tools and processes. For example, when I joined my current team, they didn't compile debug symbols and didn't know how to use a debugger on our system! Hell, in 2024 I still have colleagues who prefer to use a .dis and .map file than leverage the debug symbols... "What is this "mixed code and disassembly" display you speak of"

[staunton]

I know people who insist on putting register addresses (in hex) in their code rather than make a variable because "it's easier to debug by comparing to the user guide. If it was a variable, you would have to look up its value every time". It looks somewhat like this:

   *(int*)(0xf003) |= 39;

[the__alchemist]

So, my favorite pattern in Rust for this is to use a u8, (or u16 etc)-repr Enum for register addresses and values. So, you'd do something like, assuming a direct register API vice a wrapper:

  write_register(Reg::Config as u8, value)

Where `value` may be constructed from variables or, wait for it... Might be a binary literal because it's easier to compare to the datasheet if it's a one-off vice a general API. If it's a general API, it is probably handled with a config struct etc, where each field is a u8-repr enum.

Code like this should IMO always have a reference to the relevant DS table in comments, and probably an explanation of why you're setting the bits that way.

[AceJohnny2]

Oh deer god.

We've never been that bad, but we are still using macros for registers instead of block structure pointers, which we have access to...

(although I'll grant that structures can be risky due to undefined packing rules)