MicroZig: Unified abstraction layer and HAL for Zig on several microcontrollers

Re:MicroZig: Unified abstraction layer and HAL for Zig on se... by staunton on Thursday February 29, 2024 @02:23AM (#39547112)

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;

[ Parent | on HN ]

Re:MicroZig: Unified abstraction layer and HAL for Zig on se... by AceJohnny2 on Thursday February 29, 2024 @02:34AM (#39547157)

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)

[ Parent | on HN ]

Re:MicroZig: Unified abstraction layer and HAL for Zig on se... by the__alchemist on Thursday February 29, 2024 @10:51AM (#39550976)

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.

[ Parent | on HN ]