fix(spi): allow using both tx+rx DMA even if capability is not Duplex

[ritikmishra]

Summary

Previously, the SPI API would only allow using both TX and RX DMA channels if both the DI and DO pads were connected. However, even if there is no DO pad present, it is still useful to use a TX DMA in order to write bytes into the data register + drive SCK (in order to receive data from a SPI slave).

We are using at ATSAME54N19A to read voltages from an ADS7043 ADC. The ADS7043 ADC will automatically send the measurement over MISO once clock pulses are detected on SCK, meaning that using MOSI is not necessary.

Checklist

• All new or modified code is well documented, especially public items
• No new warnings or clippy suggestions have been introduced - CI will deny clippy warnings by default! You may #[allow] certain lints where reasonable, but ideally justify those with a short comment.

If Adding a new Board

• Board CI added to crates.json
• Board is properly following "Tier 2" conventions, unless otherwise decided to be "Tier 1"

If Adding a new cargo feature to the HAL

• Feature is added to the test matrix for applicable boards / PACs in crates.json

Note

The crate changelogs should no longer be manually updated! Changelogs are now automatically generated. Instead:

• If your PR is contained to a single crate, or a single feature:
  • Nothing else to do; your PR will likely be squashed down to a single commit.
  • Please consider using conventional commmit phrasing in the PR title.
• If your PR brings in large, sweeping changes across multiple crates:
  • Organize your commits such that each commit only touches a single crate, or a single feature across multiple crates. Please don't create commits that span multiple features over multiple crates.
  • Use conventional commmits for your commit messages.

[jbeaurivage]

Hey @ritikmishra, thanks for bringing this up. You're right that this is a gap, which seems to be only present in the async+DMA implementation. In fact, we got it right in the blocking+DMA impl:

impl<C, D> Spi<C, D>
where
    C: ValidConfig,
    D: Receive,
    C::OpMode: MasterMode,
{
    /// Attach RX and TX DMA channels to this [`Spi`]. Its
    /// [`SpiBus`](crate::ehal::spi::SpiBus) implementation will use DMA to
    /// carry out its transactions. In Master mode, since even read SPI
    /// transaction necessarily involve a write, [`Rx`]-only must take two
    /// DMA channels, just the same as if it were [`Duplex`].
    #[cfg(feature = "dma")]
    pub fn with_dma_channels<R, T>(self, rx: R, tx: T) -> Spi<C, D, R, T>
    where
        R: crate::dmac::AnyChannel<Status = crate::dmac::Ready>,
        T: crate::dmac::AnyChannel<Status = crate::dmac::Ready>,
    {
        Spi {
            capability: self.capability,
            config: self.config,
            _rx_channel: rx,
            _tx_channel: tx,
        }
    }
}

To sum up:

• In master mode:
  • RX: requires 2 channels
  • TX: requires 1 channel
• In slave mode:
  • RX: requires 1 channel
  • TX: requires 1 channel

[jbeaurivage]

I've made the required changes in this PR. Please let me know if you have questions or comments, otherwise please just merge it and I'll merge #883!

[ritikmishra]

@jbeaurivage i merged your pr on my fork!

• Relax rules for when DMA channels can be added/removed to/from Spi/SpiFuture ritikmishra/atsamd#1