jmagnuson / dma_memcpy Goto Github PK

Mutual exclusion (i.e. sync_bool_compare_and_swap) should be used for reserving access to the DMA engine.

The atomic functions used to broker DMA access were designed for compatibility with GCC's atomic builtins, but currently the library fails when attempting to build with anything other than TI's CCS compiler (where intrinsics being used, such as __ldrex, et al. are only defined).

The most basic fix would be to prefix the atomic functions in arm_atomic.h with __ to match GCC's, and then put a compiler-driven preprocessor switch around the header include inside dma_memcpy.c.

Currently dma_memcpy returns an error for buffer lengths greater than 1024 bytes. This is because of limitations in the TM4C uDMA peripheral.

A potential replacement for failure is to handle the buffer in 1024 byte chunks, either doing a simple loop and pointer increment in dma_memcpy, or re-initializing each new transfer in the uDMAIntHandler.

Currently the target architecture only has one SW DMA channel, so it would make more sense to move the channel defines into the library itself, allowing the API to look more like an actual memcpy call.

Furthermore, to better match memcpy:

• a callback argument should be a special use-case requiring a separate function definition
• dma_memcpy should block by default, requiring another function definition that could not-block and pass a callback pointer

I.e.:

dma_memcpy(uint32_t *dst, uint32_t *src, size_t len, uint32_t chan, void *cb);

would become something like:

dma_memcpy(uint32_t *dst, uint32_t *src, size_t len);
dma_memcpy_nowait(uint32_t *dst, uint32_t *src, size_t len, void *cb);

This may increase the complexity of the lib implementation (which might make it harder to port), but the simplification on the application side should outweigh those concerns.