guidelines for register blocks, registers, structs...

[orangecms]

There are lots of crates for handling various kinds of binary structures:

• https://docs.rs/bilge/latest/bilge/
• https://docs.rs/bitflags/latest/bitflags/
• https://docs.rs/bit_field/latest/bit_field/
• https://docs.rs/bitfield/latest/bitfield/
• https://docs.rs/tock-registers/latest/tock_registers/

In addition, Kaitai has partial Rust support.

We often need to parse/write vendor specific payload headers (xtask/), access special access registers (RISC-V CSRs, Intel MSRs), or deal with peripheral blocks. The latter is covered by Rust Embedded HAL/PAC semantics. That code is not as modular though, while in reality, different SoCs often share the same peripherals from the same supplier (Cadence Denali and Synopsis Designware) and/or the same or related cores (T-Head and SiFive on RISC-V, Arm based ones, etc).

We should provide guidelines and a way to go to keep our code consistent.
This if anything is the central point of a firmware monorepo, making up a framework.

[orangecms]

• deku crate 👀
• device-driver crate; has smth like bit fields, but wait, there is more; author says it's fancy
• bitvec crate

should we bother the Rust compiler team? :)