aboutsummaryrefslogtreecommitdiffstats
path: root/libmaple/stm32f2
diff options
context:
space:
mode:
authorMarti Bolivar <mbolivar@leaflabs.com>2012-06-12 17:01:12 -0400
committerMarti Bolivar <mbolivar@leaflabs.com>2012-06-15 17:41:34 -0400
commite51c60e03661cc924420eba757e15044016b7c1f (patch)
tree35a92aba834eabfaf5a4f204804b79d8134d0053 /libmaple/stm32f2
parente935e86a6f6a10fae3b646fc6aadfaf89bd76496 (diff)
downloadlibrambutan-e51c60e03661cc924420eba757e15044016b7c1f.tar.gz
librambutan-e51c60e03661cc924420eba757e15044016b7c1f.zip
DMA: prep for F2 with new "tube" API.
To prepare for STM32F2/F4 DMA support, introduce a new libmaple DMA API, and move some code around to make priority level and interrupt handling more generic. The new API is based on a new set of types (dma_tube, struct dma_tube_reg_map, enum dma_request_src, enum dma_cfg_flags, and struct dma_tube_config). The central abstraction is the dma_tube type. STM32F2/F4 use DMA streams to control dataflow, and STM32F1 uses channels. dma_tube stands for whichever is appropriate for the current target. Dealing with tubes allows for configuring and using DMA with opaque tube values in the same source, instead of (as with ST's firmware) requiring two separate codebases. The new API is also more user-friendly, as it doesn't require knowing which DMA address registers to set and which configuration register flags go along with them. It now suffices to specify the source and destination for the DMA transfer, along with their sizes. This avoids confusion (e.g. for memory-to-memory transfers, data flows from the peripheral address register to the memory register, which might be surprising on F2, which has two memory address registers). The old API (based on enum dma_mode_flags and dma_setup_transfer()) is still available on F1, but deprecate it. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Diffstat (limited to 'libmaple/stm32f2')
0 files changed, 0 insertions, 0 deletions