API design around capture/compare mode register

[gbip]

Hello,

On the stm32f1xx the timers can be configured as capture/compare. The register ccmr1 has different meaning depending on the mode of the timer (input or output).

Currently, only the output is exposed by this crate

pub struct RegisterBlock {
    // ...
    #[doc = "0x18 - capture/compare mode register 1 (output mode)"]
    pub ccmr1_output: CCMR1_OUTPUT,
    #[doc = "0x1c - capture/compare mode register 2 (output mode)"]
    pub ccmr2_output: CCMR2_OUTPUT,
    #[doc = "0x20 - capture/compare enable register"]
    pub ccer: CCER,
    #[doc = "0x34 - capture/compare register 1"]
    pub ccr1: CCR,
    #[doc = "0x38 - capture/compare register 1"]
    pub ccr2: CCR,
    #[doc = "0x3c - capture/compare register 1"]
    pub ccr3: CCR,
    #[doc = "0x40 - capture/compare register 1"]
    pub ccr4: CCR,
    //...
}

I am willing to try exposing both, but we have to design an API around that.
First of all, is this crate the good place to implement this feature, or does it belong in an HAL ?

Here are a few ideas for the API :

• a function that moves a CCMRX_OUTPUT into a CCMRX_INPUT and vice-versa
• a function that moves a Timer from capture/compare output mode into input mode (and the opposite), setting the appropriate bytes in order to set-up the input (or output) mode
• have register in both modes coexist and let the user choose which mode he is using

What do you think ?

[burrbull]

@wez has already made good solution

I don't know why he hasn't still created PR to svd2rust.

[wez]

Heh, I forgot that I had that branch is why!

[gbip]

Great then !
Would you mind making a PR ?

[luctius]

Is there any update on this?

[adamgreig]

This is now solved in rust-embedded/svd2rust#318, so once svd2rust has another release and then stm32-rs has a release, the fields will work better.