iomuxc: fix feature naming discrepancies

The "x" suffix is inconsistent with the NXP product naming scheme.
Since it diverges, it's not clear what chips are supported for the
"imxrt101x" feature.

The commit updates the imxrt-iomuxc crate to use product naming
conventions. The feature flag migration follows

- "imxrt106x" => "imxrt1060"
- "imxrt101x" => "imxrt1010"

This change is reflected in the filesystem, and in all documentation
and code updates.

imxrt-iomuxc/Cargo.toml

@@ -19,8 +19,8 @@ typenum = "1.12.0"
 imxrt-iomuxc-build = { version = "0.1.0", path = "imxrt-iomuxc-build" }
 
 [features]
-imxrt106x = []
-imxrt101x = []
+imxrt1060 = []
+imxrt1010 = []
 
 [package.metadata.docs.rs]
 all-features = true

imxrt-iomuxc/README.md

@@ -21,7 +21,7 @@ i.MX RT pad definitions and pin configuration.
   to treat pads as resources. Without any feature flags, the `imxrt-iomuxc` provides
   the general pin configuration interface. There are no processor-specific APIs in
   the default build.
-- `imxrt-iomuxc` feature flags, like `imxrt106x`, enable processor-specific pad
+- `imxrt-iomuxc` feature flags, like `imxrt1060`, enable processor-specific pad
   definitions and pin implementations.
 - `imxrt-iomuxc-build` provides **build-time** support for defining pads. It's
   used to simply generate all of the pads. It also implements simple, common
@@ -42,8 +42,8 @@ their code for different i.MX RT variants enable more feature flags.
 ## Comparison to Variant-Specific IOMUXC Crates
 
 A previous approach separated the `imxrt-iomuxc` interface and implementations
-across crates. Rather than having an `imxrt106x` feature in a single `imxrt-iomuxc`
-crate, we had separate crates, named like `imxrt106x-iomuxc`, that implemented the
+across crates. Rather than having an `imxrt1060` feature in a single `imxrt-iomuxc`
+crate, we had separate crates, named like `imxrt1060-iomuxc`, that implemented the
 `imxrt-iomuxc` interfaces. We decided to use feature flags after realizing it was
 not only easier to maintain, but also equivalent to the multi-crate approach. This
 section compares the maintenance and equivalence of the two approaches.
@@ -70,38 +70,38 @@ A single crate with feature flags is equivalent to an interface crate and separa
 implementation crates. Consider a user who wants to use the IOMUXC pin configuration
 interfaces. That user would depend on `imxrt-iomuxc`, regardless of the approach.
 
-Now, consider a user who wants to use their code on an i.MX RT 106x processor variant.
-Under the old approach, that user would include the `imxrt106x-iomuxc` crate, which
+Now, consider a user who wants to use their code on an i.MX RT 1060 processor variant.
+Under the old approach, that user would include the `imxrt1060-iomuxc` crate, which
 includes the `imxrt-iomuxc` crate:
 
 ```toml
 [dependencies]
-imxrt106x-iomuxc = "0.1"
+imxrt1060-iomuxc = "0.1"
 # imxrt-iomuxc = "0.1" - implicit dependency
 ```
 
-When using feature flags, the user enables the `imxrt106x` feature:
+When using feature flags, the user enables the `imxrt1060` feature:
 
 ```toml
 [dependencies]
-imxrt-iomuxc = { version = "0.1", features = ["imxrt106x"] }
+imxrt-iomuxc = { version = "0.1", features = ["imxrt1060"] }
 ```
 
 Both approaches result in the same changes to the dependency graph: the graph now includes code
-for i.MX RT 106x processor pads.
+for i.MX RT 1060 processor pads.
 
 Since features are additive,  users who want to support more processors enable more feature flags.
 This would have translated to the user explicitly including more crates:
 
 ```toml
 [dependencies]
-imxrt-iomuxc = { version = "0.1", features = ["imxrt102x", "imxrt106x"] }
+imxrt-iomuxc = { version = "0.1", features = ["imxrt102x", "imxrt1060"] }
 
 # Equivalent:
 
 [dependencies]
 imxrt102x-iomuxc = "0.1"
-imxrt106x-iomuxc = "0.1"
+imxrt1060-iomuxc = "0.1"
 # imxrt-iomuxc = "0.1" - implicit dependency
 ```
 

imxrt-iomuxc/build.rs

@@ -4,17 +4,17 @@ use std::{env, fs, io, path::PathBuf};
 fn main() -> io::Result<()> {
     let out_dir = PathBuf::from(env::var("OUT_DIR").unwrap());
 
-    #[cfg(feature = "imxrt101x")]
-    imxrt101x(fs::File::create(out_dir.join("imxrt101x.rs"))?)?;
+    #[cfg(feature = "imxrt1010")]
+    imxrt1010(fs::File::create(out_dir.join("imxrt1010.rs"))?)?;
 
-    #[cfg(feature = "imxrt106x")]
-    imxrt106x(fs::File::create(out_dir.join("imxrt106x.rs"))?)?;
+    #[cfg(feature = "imxrt1060")]
+    imxrt1060(fs::File::create(out_dir.join("imxrt1060.rs"))?)?;
 
     Ok(())
 }
 
-#[cfg(feature = "imxrt101x")]
-fn imxrt101x<W: io::Write>(mut pads_rs: W) -> io::Result<()> {
+#[cfg(feature = "imxrt1010")]
+fn imxrt1010<W: io::Write>(mut pads_rs: W) -> io::Result<()> {
     use imxrt_iomuxc_build as build;
 
     let ad = build::PadRange::new("AD", 0..16);
@@ -36,8 +36,8 @@ fn imxrt101x<W: io::Write>(mut pads_rs: W) -> io::Result<()> {
     Ok(())
 }
 
-#[cfg(feature = "imxrt106x")]
-fn imxrt106x<W: io::Write>(mut pads_rs: W) -> io::Result<()> {
+#[cfg(feature = "imxrt1060")]
+fn imxrt1060<W: io::Write>(mut pads_rs: W) -> io::Result<()> {
     use imxrt_iomuxc_build as build;
 
     let emc = build::PadRange::new("EMC", 0..42);

imxrt-iomuxc/src/imxrt101x/mod.rs → imxrt-iomuxc/src/imxrt1010/mod.rs

@@ -1,6 +1,6 @@
-//! Pads for the i.MX RT 101x processor family
+//! Pads for the i.MX RT 1010 processor family
 //!
-//! The module exports all of the i.MX RT 101x processor's pads. Pads that can support peripheral
+//! The module exports all of the i.MX RT 1010 processor's pads. Pads that can support peripheral
 //! functions are tagged with `imxrt-iomuxc` traits.
 //!
 //! # Example
@@ -36,8 +36,8 @@
 //!     # UART
 //! }
 //!
-//! # let sd_12 = unsafe { imxrt_iomuxc::imxrt101x::sd::SD_12::new() };
-//! # let sd_11 = unsafe { imxrt_iomuxc::imxrt101x::sd::SD_11::new() };
+//! # let sd_12 = unsafe { imxrt_iomuxc::imxrt1010::sd::SD_12::new() };
+//! # let sd_11 = unsafe { imxrt_iomuxc::imxrt1010::sd::SD_11::new() };
 //! // SD_12 and SD_11 are a suitable pair of UART pins
 //! uart_new(sd_12, sd_11, 115_200);
 //! ```
@@ -59,8 +59,8 @@
 //! #     }
 //! #     UART
 //! # }
-//! # let ad_10 = unsafe { imxrt_iomuxc::imxrt101x::ad::AD_10::new() };
-//! # let ad_11 = unsafe { imxrt_iomuxc::imxrt101x::ad::AD_11::new() };
+//! # let ad_10 = unsafe { imxrt_iomuxc::imxrt1010::ad::AD_10::new() };
+//! # let ad_11 = unsafe { imxrt_iomuxc::imxrt1010::ad::AD_11::new() };
 //! // Neither pad is a valid UART pin
 //! uart_new(ad_10, ad_11, 115_200);
 //! ```
@@ -82,8 +82,8 @@
 //! #     }
 //! #     UART
 //! # }
-//! # let gpio_09 = unsafe { imxrt_iomuxc::imxrt101x::gpio::GPIO_09::new() };
-//! # let gpio_13 = unsafe { imxrt_iomuxc::imxrt101x::gpio::GPIO_13::new() };
+//! # let gpio_09 = unsafe { imxrt_iomuxc::imxrt1010::gpio::GPIO_09::new() };
+//! # let gpio_13 = unsafe { imxrt_iomuxc::imxrt1010::gpio::GPIO_13::new() };
 //! // GPIO_10 is a UART1 TX pin, and GPIO_13 is a UART2 RX pin
 //! uart_new(gpio_10, gpio_13, 115_200);
 //! ```
@@ -92,7 +92,7 @@ mod i2c;
 mod spi;
 mod uart;
 
-include!(concat!(env!("OUT_DIR"), "/imxrt101x.rs"));
+include!(concat!(env!("OUT_DIR"), "/imxrt1010.rs"));
 pub use pads::*;
 
 mod bases {

imxrt-iomuxc/src/imxrt106x/mod.rs → imxrt-iomuxc/src/imxrt1060/mod.rs

@@ -1,6 +1,6 @@
-//! Pads for the i.MX RT 106x processor family
+//! Pads for the i.MX RT 1060 processor family
 //!
-//! The module exports all of the i.MX RT 106x processor's pads. Pads that can support peripheral
+//! The module exports all of the i.MX RT 1060 processor's pads. Pads that can support peripheral
 //! functions are tagged with `imxrt-iomuxc` traits.
 //!
 //! # Example
@@ -36,8 +36,8 @@
 //!     # UART
 //! }
 //!
-//! # let ad_b0_13 = unsafe { imxrt_iomuxc::imxrt106x::ad_b0::AD_B0_13::new() };
-//! # let ad_b0_12 = unsafe { imxrt_iomuxc::imxrt106x::ad_b0::AD_B0_12::new() };
+//! # let ad_b0_13 = unsafe { imxrt_iomuxc::imxrt1060::ad_b0::AD_B0_13::new() };
+//! # let ad_b0_12 = unsafe { imxrt_iomuxc::imxrt1060::ad_b0::AD_B0_12::new() };
 //! // AD_B0_13 and AD_B0_12 are a suitable pair of UART pins
 //! uart_new(ad_b0_12, ad_b0_13, 115_200);
 //! ```
@@ -59,8 +59,8 @@
 //! #     }
 //! #     UART
 //! # }
-//! # let ad_b0_10 = unsafe { imxrt_iomuxc::imxrt106x::ad_b0::AD_B0_10::new() };
-//! # let ad_b0_11 = unsafe { imxrt_iomuxc::imxrt106x::ad_b0::AD_B0_11::new() };
+//! # let ad_b0_10 = unsafe { imxrt_iomuxc::imxrt1060::ad_b0::AD_B0_10::new() };
+//! # let ad_b0_11 = unsafe { imxrt_iomuxc::imxrt1060::ad_b0::AD_B0_11::new() };
 //! // Neither pad is a valid UART pin
 //! uart_new(ad_b0_10, ad_b0_11, 115_200);
 //! ```
@@ -82,8 +82,8 @@
 //! #     }
 //! #     UART
 //! # }
-//! # let ad_b0_13 = unsafe { imxrt_iomuxc::imxrt106x::ad_b0::AD_B0_13::new() };
-//! # let ad_b1_02 = unsafe { imxrt_iomuxc::imxrt106x::ad_b0::AD_B1_02::new() };
+//! # let ad_b0_13 = unsafe { imxrt_iomuxc::imxrt1060::ad_b0::AD_B0_13::new() };
+//! # let ad_b1_02 = unsafe { imxrt_iomuxc::imxrt1060::ad_b0::AD_B1_02::new() };
 //! // AD_B1_02 is a UART2 TX pin, but AD_B0_13 is a UART1 RX pin
 //! uart_new(ad_b1_02, ad_b0_13, 115_200);
 //! ```
@@ -94,7 +94,7 @@ mod pwm;
 mod spi;
 mod uart;
 
-include!(concat!(env!("OUT_DIR"), "/imxrt106x.rs"));
+include!(concat!(env!("OUT_DIR"), "/imxrt1060.rs"));
 pub use pads::*;
 
 mod bases {

imxrt-iomuxc/src/lib.rs

@@ -11,8 +11,8 @@
 //! the processor's pads for HAL users. The approach lets users treat pads as resources
 //! which will be consumed and used by processor peripherals.
 //!
-//! Processor pads may be enabled using feature flags. For example, the `imxrt106x` feature
-//! flag exposes an `imxrt106x` module that defines all i.MX RT 106x processor pads.
+//! Processor pads may be enabled using feature flags. For example, the `imxrt1060` feature
+//! flag exposes an `imxrt1060` module that defines all i.MX RT 1060 processor pads.
 //!
 //! # Design Guidance
 //!
@@ -109,8 +109,8 @@ pub use config::{
 ///     // Re-export common modules and types
 ///     pub use imxrt_iomuxc::prelude::*;
 ///     // Conditionally re-export chip-specific pads
-///     #[cfg(feature = "imxrt106x")]
-///     pub use imxrt_iomuxc::imxrt106x::*;
+///     #[cfg(feature = "imxrt1060")]
+///     pub use imxrt_iomuxc::imxrt1060::*;
 /// }
 /// ```
 pub mod prelude {
@@ -190,13 +190,13 @@ macro_rules! define_base {
 // Listing the processor modules here, since they may depend on the
 // above `define_base!()` macro...
 //
-#[cfg(feature = "imxrt101x")]
-#[cfg_attr(docsrs, doc(cfg(feature = "imxrt101x")))]
-pub mod imxrt101x;
+#[cfg(feature = "imxrt1010")]
+#[cfg_attr(docsrs, doc(cfg(feature = "imxrt1010")))]
+pub mod imxrt1010;
 
-#[cfg(feature = "imxrt106x")]
-#[cfg_attr(docsrs, doc(cfg(feature = "imxrt106x")))]
-pub mod imxrt106x;
+#[cfg(feature = "imxrt1060")]
+#[cfg_attr(docsrs, doc(cfg(feature = "imxrt1060")))]
+pub mod imxrt1060;
 
 /// An IOMUXC-capable pad which can support I/O multiplexing
 ///

imxrt-iomuxc/tests/prelude.rs

@@ -5,8 +5,8 @@
 #![allow(unused)]
 
 mod iomuxc {
-    #[cfg(feature = "imxrt106x")]
-    pub use imxrt_iomuxc::imxrt106x::*;
+    #[cfg(feature = "imxrt1060")]
+    pub use imxrt_iomuxc::imxrt1060::*;
     pub use imxrt_iomuxc::prelude::*;
 }
 
@@ -16,9 +16,9 @@ fn use_prelude() {
     use iomuxc::{consts, gpio, i2c, pwm, spi, uart, Daisy, ErasedPad, Pad, WrongPadError};
 }
 
-/// Ensure that the imxrt106x modules are re-exported
-#[cfg(feature = "imxrt106x")]
+/// Ensure that the imxrt1060 modules are re-exported
+#[cfg(feature = "imxrt1060")]
 #[test]
-fn use_imxrt106x() {
+fn use_imxrt1060() {
     use iomuxc::{ad_b0, ad_b1, b0, b1, emc, sd_b0, sd_b1, ErasedPads, Pads};
 }