Updates the DMAC peripheral to use the clock::v2 API
#932
Conversation
… API for `thumbv7` targets. * Renames the `dmac::DmacController::init` to `dmac::DmacController::new` for all targets for consistency with other peripherals * `dmac::DmacController::new` now requires the `AhbClk<Dmac>` for `thumbv7` targets instead of `&mut Pm`. * `dmac::DmacController::free` also now returns the `AhbClk<Dmac>` for `thumbv7` targets. * Addresses some other `cargo doc` warnings in the `dmac` module.
… API for `thumbv7` targets. * Updates the examples in the `dmac` module documentation to reflect the API changes. * Updates all applicable Tier 1 BSP examples, while others are broken, requiring additional peripheral migrations before they can be fixed.
|
Apart from the discussion question, I'm happy for this to be merged into our Clock V2 branch, then we can fix the examples once the other peripherals are migrated |
|
A merge is good with me. I don't think we need to track the broken examples in the branch as we go. I have a script to go build all the Tier 1 BSPs so they will be easy to assess the broken examples at any point, plus we can refer back to the PRs to know when requisite peripherals have been merged. |
|
Exactly! The examples will be fixed as we go :) |
| with_num_channels!(define_channels_struct_future); | ||
|
|
||
| /// Initialized DMA Controller | ||
| #[hal_macro_helper] |
There was a problem hiding this comment.
We should probably decide if in the HAL in general, it makes more sense to use this macro to feature gate D5x/D21 clocking in the same peripheral structure, or, better to do it like in other peripherals, where D21 and D5x have completely different structures (Look at the ADC for example)
There was a problem hiding this comment.
Taking a look, it looks like the ADC is different enough to justify this, but I worry that many peripherals could potential have a lot of duplicated code if this is done. This is the whole reason why many of the peripherals don't make sense to migrate until the thumbv6 clock v2 API is done, see note 5 in the Migration Guidelines of #912. As disclaimer, I have not thought very deeply about how much code duplication might be able to be avoided by taking this approach with more similar peripherals.
EDIT: Additionally the general differences between the structs, namely the thumbv7 version needing to own an AhbClk, for example while the thumbv6 version does not, will likely go away for a lot of peripherals once the thumbv6 clock v2 API is done since then they will both need to own these clock proofs.
2 participants
Summary
As part of the
clock::v2effort tracked in Issue #912, this PR updates thedmacto use theclock::v2API by requiring ownership of itsAhbClkforthumbv7targets.See the commit message for details.
The following Tier 1 BSP examples were also updated to include the change:
samd11_bare/i2cfeather_m0/async_dmacfeather_m0/async_i2cfeather_m0/async_spifeather_m0/async_uartfeather_m0/dmacfeather_m0/i2cfeather_m0/spifeather_m0/uart_dma_blockingfeather_m0/uart_dma_nonblockingfeather_m4/dmacmetro_m0/i2cmetro_m0/spimetro_m4/async_dmacThe following Tier 1 BSP examples are now broken and cannot be fixed until the noted peripherals are also migrated and merged (see the notes about this in Issue #912):
feather_m4/i2c(sercom::i2c::Config)feather_m4/spi(sercom::spi::Config)feather_m4/uart_dma_blocking(sercom::uart::Config)feather_m4/uart_dma_nonblocking(sercom::uart::Config)metro_m4/async_i2c(sercom::i2c::Config)metro_m4/async_spi(sercom::spi::Config)metro_m4/async_uart(sercom::uart::Config)metro_m4/i2c(sercom::i2c::Config)metro_m4/spi(sercom::spi::Config)Checklist
#[allow]certain lints where reasonable, but ideally justify those with a short comment.