Support Non-zero Chip Selects for lpspi4

[ameliamariecollins]

Add pins for lpspi4 Pcs[1-3], with their corresponding tags.

This is the first portion of the work needed to support multiple peripherals on a single SPI bus. Changes in this PR only affect imxrt1060-series microcontrollers.

[ameliamariecollins]

(Fixed GPG signing key so commits show as verified.)

[mciantyre]

Looks like a good first start. CI indicates that this doesn't build just yet. You can run the majority of checks locally with cargo clippy --all-features and cargo test --all-features. There's more discussion in the development basics.

[ameliamariecollins]

Noted breaking change in CHANGELOG.md.

[mciantyre]

Looks great, thanks for working through this. Eagerly approving.

At this point, I would squash the Rust source changes into something like 98637d7, and keep the .gitignore commit as-is. That would produce a clean commit history for future study. But if I did that, I would discard your GPG signatures, and (I believe) the commits would appear as "unverified."

If you're particular about maintaining the "verified" stamps, I'm leaving this open for at least 3 days (or longer, let me know) so you can squash and re-sign the commits. Otherwise, I'll squash and fast-forward merge myself.

TL;DR history clean-up solution

I believe this should work. Please double-check my work.

git switch lpspi_non-zero_chip_select
git reset --soft 98637d7
git commit --amend --message "Add non-zero LPSPI PCSx items; 1060 LPSPI4 pins"
git push [your-remote] lpspi_non-zero_chip_select --force-with-lease

[mciantyre]

If you'd like to start prototyping with this right away, here's a quick approach that might work:

1. In your local imxrt-iomuxc repository, change the package's version number in Cargo.toml from 0.3.0 back down to 0.2.2.

2. In your local (Teensy 4) firmware project, add the following to the Cargo.toml package manifest:

   [patch.crates-io.imxrt-iomuxc]
   path = "../../relative/path/to/imxrt-iomuxc" # <-- TODO change me

   path is either a relative path from your local firmware project to your local imxrt-iomuxc repository; or an absolute path to imxrt-iomuxc (untested). Learn more about patches here.

3. Run cargo update in your local firmware project.

4. Build the local firmware project.

Steps 1 tricks Cargo into thinking a breaking release is non-breaking. Step 2 tricks Cargo more; it updates the dependency graph to use your local imxrt-iomuxc whenever it would have used the standard version. The end result is that you have the non-zero LPSPI PCSx implementations available to you.

[ameliamariecollins]

Thank you for the Cargo magic. It worked perfectly.

Now that there are multiple PcsX pins, how do I switch between them? Are there multiple instantiations of an lpspi4 object, one for each peripheral? (I'm hoping this is true instead of its opposite, altering a single instance of lpspi4 to change the pin, leading to jumbles like this one: under RTIC, if a task using a SPI peripheral pre-empted some other lower priority task, it would need to change the PcsX pin, but might not have control over when to restore it if, in turn, it got pre-empted.)

[mciantyre]

Now that there are multiple PcsX pins, how do I switch between them?

Great question. How about we continue this discussion in imxrt-rs/imxrt-hal#131? This sounds like it requires an extension to the LPSPI driver.

Sorry, but I'm not sure I immediately understand the concerns about the single-object-driver and RTIC preemption. If you have time, could you expand on this in imxrt-rs/imxrt-hal#131?