Giters

imxrt-rs / imxrt-iomuxc

Pin definitions, configurations, and multiplexing API

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Complete pin impls

mciantyre opened this issue · comments

commented

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

1060

1170

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.

commented

What should be complete

  • All GPIO implementations should exist for all pads. They're auto-generated.
  • ADC for 1060.
  • LPI2C, LPSPI, and LPUART for 1010 (imxrt-rs/imxrt-hal#88).
commented

Bonus points for a tool that can consume SVD files and output human-readable and -maintainable Rust code. Here's some recommendations and informal requirements:

  • Try extracting the pin implementations from the SVD. Any SVD-based approach should ensure that it works with all of the SVDs maintained in the imxrt-ral repository.
  • It should be straightfoward to add new pin traits to the automation. This lets us generate pin implementations for traits that don't exist right now. We have a variety of traits we would already need to support, so we have a good starting point for this.
  • If the output is checked into a VCS, it should support stable re-generation; re-generating all implementations when nothing else changed should produce the same output.
  • If the pads are generated at build time using build.rs, the database that provides the definitions should be small (with "small" not yet defined). Please no large packages, or packages that take a while to download from crates.io.
  • Any approach must also support git and path dependencies, along with the usual crates.io distribution. It's important to maintain this support for development.