Add DMAC trigger source enumerations for SAMD21

[ianrrees]

The names/values/descriptions are copied from the SAMD21 datasheet DS40001882F; I've noticed the same issue exists on the other Microchip parts supported by https://github.com/atsamd-rs/atsamd - should I do the same for those?

[aethaniel]

Thanks @ianrrees for your contribution, we will try to integrate those changes at the best in our documentation flow.

[dsettu]

@ianrrees , Thank you. This value group is presently not used by our Harmony 3 code generation tool.
May I know how you intend to use this value group?. thanks.

[ianrrees]

@aethaniel, thanks for that! I'll add the similar SAMD11 and SAMD5x changes to this PR later today.

@dsettu, @aethaniel can loop you in to the email thread, but essentially I'm working on a firmware for SAMD21 written in Rust, using https://github.com/atsamd-rs/atsamd . For the supported Microchip parts, the Rust low level Peripheral Access Crate (usually just PAC) is generated from Microchip's SVD files (with a set of patches applied to them), and I understand those SVDs to be derived from the ATDFs. The end goal is for firmware to use only valid enum values for the DMA trigger source (in particular I'm using DMA with the I2S peripheral). This allows the Rust compiler to generate compile time errors for invalid usage, so the Hardware Abstraction Layer doesn't need to have runtime checks that the trigger source is being set to a valid value.

[dsettu]

@ianrrees , Thank you. I understood your need.
Do you have option of parsing ATDF?, if not we will feed this back to respective team to add this information at source.

We have DMA Trigger value as part of the respective peripheral instance. Is it something that you can parse and generate enum type to list of DMA_ID available in ATDF.

This will helpful to generate part specific enumeration. For example, if the part number does not SERCOM2, it will avoid generating enumeration for it.

[ianrrees]

Thanks for that pointer @dsettu, I had wondered how Harmony worked without that information. Switching from using SVD to ATDF may be possible, but I guess would be quite a big change. Is the tool that converts from ATDF to SVD available publicly?

[dsettu]

@ianrrees , We use the bit-field macro to write the value as shown below. We generate hardcoded value based on trigger source selection in Harmony 3.
DMAC_REGS->DMAC_CHCTRLB = DMAC_CHCTRLB_TRIGACT(2)

@aethaniel can comment on the ATDF to SVD conversion.

[ianrrees]

@dsettu , yes, that's like what we would do with the Rust library, if the TRIGSRC enumeration were populated in the SVD file. I guess the easiest way to resolve this is not to duplicate the information in the ATDF as I do in this PR, but instead update the tool used for generating the SVDs from the ATDF files so that it populates TRIGSRC?

[dsettu]

@ianrrees , I submitted request to get this value group added for samd11, samd21, samd51 and same5x family. You may proceed with the fix provided in this PR. Next release is planned in CQ1'21.