support dma chunk sizes other than 4092

[liebman]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

This PR will allow dma "chunk sizes" other than the default 4092.

Description

This is needed to support DMA to/from psram on the esp32s3 where it requires that the size and address pointer fields in each DmaDescriptor are required to be "block" aligned where the block alignment is selectable from the set of 16, 32, or 64 bytes. (support for DMA to/from psram will be a seperate PR)

• the dma_buffer type macros were refactored to remove code duplication and to add _chunk_size variants.
• the DmaDescripterChain was changed to support specifing the chunk size.

Testing

tests were added for all of the dma_ macros
added an additional mem2mem test using a different CHUNK_SIZE

[liebman]

@bjoernQ In my previous PR I fixed a HIL test issue by Insuring that the test dropped the Mem2Mem struct and in the drop explicitly reset the "memory to memory" bit. Thinking on this I think we should utilize the RegisterAccess::init() function to initialize all bits that are known cause undefined behavior. Thoughts? (could be done in a separate PR)

[bjoernQ]

@bjoernQ In my previous PR I fixed a HIL test issue by Insuring that the test dropped the Mem2Mem struct and in the drop explicitly reset the "memory to memory" bit. Thinking on this I think we should utilize the RegisterAccess::init() function to initialize all bits that are known cause undefined behavior. Thoughts? (could be done in a separate PR)

Sounds good to me! Better to not hope for defaults being always set

[liebman]

Sounds good to me! Better to not hope for defaults being always set

Added.

[bjoernQ]

LGTM

[JurajSadel]

LGTM, thanks!