This is a placeholder for upcoming tool that is in development

svd2pac

Tool to generate Peripheral Access Crates from SVD files

Why another PAC generator ?

This tool has a very different approach compared to svd2rust and it is inspired by chiptool.

Motivation

• Register access is unsafe because sometimes also the order of writing register bitfields is important. (discussion on this topic available here https://github.com/rust-embedded/svd2rust/issues/714).
• No ownership because owned registers are an obstacle to writing low level drivers (LLD). Anyway writing LLDs requires a lot of unsafe code and ownership makes it more complex to access registers from interrupts and other threads. LLDs shall present safe APIs because only they can implement all logic for a safe usage of peripherals.
• Support tracing of register accesses and additionally mocking of registers on non-embedded devices through external libraries. This allows the exectuion unit tests for code that uses the generated libraries on non-embedded devices.

chiptool features implemented by svd2pac

• No owned data structure -> unsafe api that can be used from any interrupts or thread.
• Register values are represented by structs. No write to register when updating a bitfield.
• Enumerated values are represented with a struct + associated constants.
• Essentially same API to access registers that chiptool uses.
• Logging of register accesses.

Major differences to chiptool

• Support for modify atomic assembly instruction (only Aurix).
• Bitfields are structs with setters and getters. This prevents naming conflicts with bitfield names like set_xxx.
• Bitfield setters consume the register struct and support a fluent api. Lower coding in closure.
• Support for the "Cluster" tag in SVD files.
• Support also for 8,16,64 bit size registers.
• Avoid long type and bitfield names (chiptool concatenates identifiers) by generating modules for registers and svd clusters.
• No support for SVD transformation.