1010 pads defined backwards, and have extra pads

[mciantyre]

The build script that generates IOMUXC pads expects that the register address increments when the pad number increments. The register block below depicts the idea. Notice how EMC_03 has a lower address than EMC_04. The pattern holds on 1015, 1020, 1050, and 1060 i.MX RT variants.

// From imxrt-ral, feature = "imxrt1062"
#[repr(C)]
pub struct RegisterBlock {
    pub SW_MUX_CTL_PAD_GPIO_EMC_00: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_EMC_01: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_EMC_02: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_EMC_03: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_EMC_04: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_EMC_05: RWRegister<u32>,
    // ...
}

On the other hand, the 1010 has a different pattern. When the address increments, the pad number decrements. Notice how AD_13 has a lower address than AD_12. Comparing reference manuals and SVDs reveals the pattern.

// From imxrt-ral, feature = "imxrt1011"
#[repr(C)]
pub struct RegisterBlock {
    pub SW_MUX_CTL_PAD_GPIO_AD_14: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_AD_13: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_AD_12: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_AD_11: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_AD_10: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_AD_09: RWRegister<u32>,
    pub SW_MUX_CTL_PAD_GPIO_AD_08: RWRegister<u32>,
    // ...
}

The build script generates the pads backwards, as if they followed the pattern of all the other i.MX RT families. In effect, the 1010 pads refer to the wrong registers.

---

Additionally, we generate 16 GPIO_AD, GPIO_SD, and GPIO pads. However, there's only 15 GPIO_AD and GPIO_SD pads, and 14 GPIO pads. The extra pads alias the registers from the other pad groups. When addressing the above, reduce the number of generated pads.

https://github.com/imxrt-rs/imxrt-iomuxc/blob/a3b694c471ab654dc2c78659959ef351d4306eff/build.rs#L20-L22

[mciantyre]

The current release doesn't include the 1010 pads, so this only affects the repository's contents.

~Might be as simple as a reverse() somewhere in the pad generation script.~ Not that easy, since the pad implementation assumes a positive address increment from the base. We might only be able to get away with build script changes if we define types like

// Before:
type GPIO_AD_14 = Pad<GPIO_AD, U14>;
// After:
type GPIO_AD_14 = Pad<GPIO_AD, U0>;

but that looks strange.

[mciantyre]

I'm also checking some discrepancies with the GPIO implementations:

• Section 12.5.1 of the 1010 reference manual indicates that the three GPIO peripherals are numbered GPIO1, GPIO2, and GPIO5. We're generating GPIO3, not GPIO5.
• According to table 10-1, there's only one GPIO5 pin.
• GPIO1 includes all GPIO_* and GPIO_AD_* pads. We're only assigning GPIO1 functions to GPIO_AD_*, and assigning GPIO3 functions to GPIO_*. (GPIO1 is called "GPIOMUX" in table 10-1 for some reason, but the SVDs use "GPIO1" as expected.)

https://github.com/imxrt-rs/imxrt-iomuxc/blob/d7a78adc253d5f17c4aeb4f7556967b6defc4196/build.rs#L25-L35