imxrt-iomuxc does not have a way to express non-zero LPSPI chip selects. We only identify PCS0 pins, along with the data and clock pins. Without a way to identify non-zero LPSPI chip selects in the type system, we cannot use imxrt-iomuxc APIs to configure PCS1, PCS2, and PCS3 pads.

This issue tracks support for an API to express these pins. This issue does not track MCU pin implementations; we'll use subtasks of #14 to track that effort.

(The original issue continues below.)

        iomuxc::lpspi::prepare(&mut pins.p37); // lpspi4 PCS0-1
        iomuxc::lpspi::prepare(&mut pins.p36); // lpspi4 PCS0-2

results in:

92 |         iomuxc::lpspi::prepare(&mut pins.p36); // lpspi4 PCS0
   |         ---------------------- ^^^^^^^^^^^^^ the trait `teensy4_bsp::imxrt_hal::iomuxc::lpspi::Pin` is not implemented for `Pad<1075806596, 1075807092>`

But those are truly are PSC0-1 and PCS0-2 for LPSPI4 (Teensy 4.1).

Is there a better way to use the HAL for a SPI bus that has multiple peripherals and therefore needs multiple PCS lines where each can be enabled when needed?

Many thanks!

The repository's README describes some project history. But, it's not particularly useful for end users. Revise the documentation to describe

• who uses this crate
• why users might want this crate
• what those users need to know to get their jobs done

Additionally, add a contributing guide. The guide should include

• naming conventions (crate features, API guidelines)
• how to build and test the library
• guide for adding new peripheral APIs

See #14 for context.

• LPUART5 is TODO
• Finish implementations for LPUART2, 3, 4, 6, 7, and 8.

#30 introduced 1020 pads, and implementations for a few peripherals. This issue tracks complete pin implementations for the 1020.

• ADC
• CCM
• FlexCAN
• FlexIO
• FlexPWM
• GPIO
• LPI2C
• LPSPI
• LPUART
• SAI
• USDHC

Checks indicate complete support for a peripheral. Unchecked peripherals have incomplete or no support.

We've added Pin implementations on a need-be basis. As a user of this crate, you may notice some peripherals don't have all their pins assigned (like in #12). You may also notice TODOs describing missing implementations. This is expected given the history of this code.

This tracking issue identifies missing Pin implementations that we know about. We welcome contributions that add additional pins. If you find missing implementations, either

• open a PR with the new additions (like #12) and reference this issue; or
• open an issue describing the missing pins, and reference this issue

If you'd like to contribute, pick one of the linked issues. Consult the "External Signals and Pin Multiplexing" section of your MCU's reference manual. The table describes which pads support which peripherals, and how to configure those pads.

1010

• #1

1060

• #16
• #15
• #17

1170

• #27

This issue does not track support for new peripherals. For instance, we know that there's no FLEXIO pin implementations, because we've not defined the FLEXIO pin interface. Open separate issues for these features.

Also, this issue does not track support for new MCU families. Open separate issues / PRs for 1020, 1050, etc. support.

#26 introduced all pads for the 1170. It included very few pin implementations, just enough for prototyping on the IMXRT1170EVK. This issue tracks complete pin implementations for 1170 pads.

• ADC
• CCM
• FlexCAN
• FlexIO
• FlexPWM
• GPIO
• LPI2C
• LPSPI
• LPUART
• SAI
• USDHC

Checks indicate complete support for a peripheral. Unchecked peripherals have incomplete or no support.

Although daisy registers may be required today, #30 shows that daisy registers may be optional tomorrow. Refactor traits and implementations to always use Option<Daisy> associated constants. This lets us extend chip support without incurring breaking changes.

After #30, it seems that only lpi2c::Pins needs this treatment.

The existing pins likely only support some Teensy 4.0 outputs. Ensure that all pins have their implementation.

#26 integrated 1170 pads into imxrt-iomuxc assuming that the pad control (PAD_CTL) register fields would be just like all the PAD_CTL register fields on the 10xx MCUs. You know what that means...

They're different. In fact, there's various PAD_CTL field layouts in the 1170, depending on what pad group you're looking at. Until this is addressed, do not use configure and Config with 1170 pads from imxrt-iomuxc version 0.2. These APIs generate the wrong PAD_CTL values.

This will also affect any pin traits that include PAD_CTL values, like ADC and uSDHC (#27). However, those are not yet implemented for 1170 pads.

None of this affects the 10xx pads. For a 1170 workaround, try using imxrt-ral APIs to specify PAD_CTL values. The SVD appears to match the reference manual for the registers I sampled.

10xx PAD_CTL fields

This is what Config thinks the PAD_CTL looks like.

11xx PAD_CTL fields

I'm noticing three different field layouts across the IOMUXC and IOMUXC_LPSR PAD_CTL registers. I'm ignoring the bits related to domain protection (high nibble of the registers), since that's expected to differ w.r.t. 10xx.

This discussion is specific to the 1170 MCU. I've not considered the 1160 or other 11xx MCUs.

Layout 1: EMC, SD, and DISP_B1 pads (IOMUXC)

No slew rate, speed, or hysteresis. Limited PU/PD config. PDRV is the drive strength; 0 is "high," and 1 is "normal."

Layout 2: LPSR pads (IOMUXC_LPSR)

Slew rate is back. Different way to configure PU/PD. DSE is the drive strength; 0 is "normal," and 1 is "high." It's an inverted PDRV field from the first layout.

Layout 3: AD and DISP_B2 pads (IOMUXC)

Almost the same as the LPSR layout, but with a shifted bit to toggle the open drain.

Other notes

I'm ignoring IOMUXC_SNVS pads, since we're not exporting those through this package. If my study is right, these add two different layouts of 1170 PAD_CTL fields. They also change for the 10xx.

Most prepare calls set an alternate value to fully prepare the pin. But this call is missing in adc::prepare.

The implementation should call alternate with the GPIO alternate value so the pad can operate as an ADC input. Not setting the alternate can lead to pad reconfiguration issues, like this one.

Hard-coding alternate 5 should work. But ideally, we base the alternate on what the GPIO implementation supplies.

Recent versions of clippy aren't impressed with our loud, all-caps type names. We have a breaking 0.2 change pending. As part of that release, I plan on

• reverting this commit
• fixing all clippy naming warnings
  • traits and hand-written code is a definite
  • auto-generated pad definitions is a maybe

The 0.1 to 0.2 breakage today is just a feature name change. So if implemented, this breaking change will have more impact for users.

Is anyone opposed? Do we like today's naming? We could just keep the warning disabled, and maintain the same names. But it's unconventional, and might look out of place in users' code.

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.

See #14 for context.

• I2C2 is TODO
• Define all SCL and SDA pins for I2C1, 3, and 4.

This issue tracks the imxrt-iomuxc traits implementations for the 1010 family. Checkmarks indicate some support for peripherals, but it may be incomplete. TODOs are unchecked.

• #18
• CCM included in #26
• GPIO
• LPI2C
• FlexIO
• #19
• #20
• LPSPI
• LPUART
• SAI
• USDHC

There is no FlexCAN peripheral on these MCUs.

We're unsure if the sai::prepare function will work for SAI1 peripherals with multiple data lines. Specifically, we're not changing the SAI input pad's drive strength. Investigate once there's a driver with multiple data lines.

See discussions in #3 for more context.