DMA-enabled embedded-hal blocking implementations

[jbeaurivage]

Context

SPI timing and performance issues

In #657, @Felix-El has pointed out that the blocking SPI implementations were somewhat fragile and prone to race conditions. @ianrrees also had some similar comments in #751. Essentially, our SPI transfers are done word by word, which might:

• Introduce buffer overflow errors if the SPI is ran at a too high frequency
• Break invariants of some timing-dependent protocols build on top of SPI, such as LCD displays and addressable LEDs.

SPI transfers using DMA

Currently, the HAL has minimal support for making SPI transfers using DMA. It exposes the send_with_dma and receive_with_dma methods. However these:

1. Are non-blocking
2. Take exclusively 'static buffers in order to satisfy memory safety invariants (namely, due to point 1)
3. Most importantly, can not be used to build embedded-hal::spi::SpiBus trait implementations.

The same points are also true for our UART and I2C drivers.

Proposal

In this PR, I suggest a new implementation to make DMA-enabled SPI transfers. It provides blocking, safe implementations that don't need to take 'static buffers. The API to use DMA is as simple as configuring 2 DMA channels, then calling Spi::with_dma_channels, and all subsequent transfers will use DMA.

What I propose is that we encourage users who have strict timing or performance requirements, or need very high frequency transfers, to use the DMA implementations. The word-by-word implementation can therefore remain simple, without the need for us to expend lots of energy trying to optimize it for performance. Users with loose timings or lower frequencies can still use it with reduced configuration complexity (which is really not a lot).

The rationale is that we can probably optimize the word-by-word implementation a bit, but we'll soon hit an upper limit, which we can only exceed using DMA anyways. DMA transfers are also impervious to preemption by higher priority interrupts.

I want to add the same mechanisms for I2C and UART, since most of the effort is already done and reusable there.

What's included

• DMA-enabled blocking SpiBus implementation
• Mark the various send_with_dma and receive_with_dma methods as deprecated. They should be removed either in this PR or in a subsequent release -- perhaps at the same time as the ehal 0.2 stuff. Keep the UART send_with_dma and receive_with_dma nonblocking methods, as they can be used on a split UART to do some interesting things.
• Configurable NOP word for SPI transfers Turns out this was already implemented
• DMA-enabled blocking I2c implementation
• DMA-enabled blocking Uart implementation

SPI-specific improvements

• Disable receiver when the only capability is TX - reduces changes of unnecessary overflow errors. Reference: Spi implementation relies on fragile timing #657 (see comment).
• Provide SpiBus implementations for RX-only and TX-only SPIs (DMA and non-DMA), which panic when unsupported operations are attempted. References: Neopixel examples are problematic #752, Spi implementation enhancements #751 (see comment).

What's not included

• embedded-hal-nb DMA implementations. These would either require the user to pass 'static buffers everywhere, or require all DMA-enabled methods to be unsafe. Both options are incompatible with the traits embedded-hal-nb provides. For non-blocking concurrent code, I would strongly suggest users look at async instead (Async API #635).

• There have also been reports of fragile timing and performance in our blocking embedded-hal v0.2 implementations. I'm not particularly interested in updating those. In fact, I would like to remove embedded-hal v0.2 from atsamd-hal entirely (perhaps in another PR).

Breaking changes

• Bumps MSRV to Rust 1.77.2

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.

Notes for reviewers:

• This PR is built on top of fix: Changes to the dmac public API #764, which should be merged first.

• Please merge this PR using rebase (and not squash) to conserve changelog history.

Closes #657.

[sajattack]

couple comment typos I trust you'll resolve but LGTM

[jbeaurivage]

Thanks for reviewing @sajattack.

There's just one last thing I'm wondering about before I want to close this for good.

In the ehal 0.2 SPI implementation, we (obviously) wait for a DRE every time we want to send a word on the bus, but we never wait for a TXC, even at the end of a transaction.

The new implementation does wait for a TXC after each transaction. I believe that may be unnecessary, according to embedded-hal's SpiBus spec, and potentially even harmful - I suspect it may be a contributor to the timing issues we've been experiencing with SPI. After rereading the spec, turns out flushing should only be necessary when deasserting CS or deinitializing the peripheral - the user should flush manually.

I think I'll remove those bus flushes and test out a bit more before committing to merging this.

[jbeaurivage]

I've decided to leave the bus flushes alone for now. Seems like removing them introduces some subtle timing bugs, and sometimes even panics. I want to investigate further before touching this, perhaps in a later PR.