diff options
author | Marti Bolivar <mbolivar@leaflabs.com> | 2012-06-12 17:01:12 -0400 |
---|---|---|
committer | Marti Bolivar <mbolivar@leaflabs.com> | 2012-06-15 17:41:34 -0400 |
commit | e51c60e03661cc924420eba757e15044016b7c1f (patch) | |
tree | 35a92aba834eabfaf5a4f204804b79d8134d0053 /libmaple/rcc.c | |
parent | e935e86a6f6a10fae3b646fc6aadfaf89bd76496 (diff) | |
download | librambutan-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/rcc.c')
0 files changed, 0 insertions, 0 deletions