| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | Set DCNTR before starting DMA transfer. | Manuel Odendahl | 2013-01-17 | 1 | -0/+1 |
| | | | | | | | | I am not sure why this would work for most DMA transfers but I ran into trouble when doing SDIO DMA. Signed-off-by: Manuel Odendahl <wesen@ruinwesen.com> | ||||
| * | Implement DMA tube API on STM32F1. | Marti Bolivar | 2012-06-15 | 1 | -4/+58 |
| | | | | | Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com> | ||||
| * | DMA: prep for F2 with new "tube" API. | Marti Bolivar | 2012-06-15 | 1 | -197/+184 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> | ||||
| * | stm32f1: Resurrect DMA support. (sets up breaking change) | Marti Bolivar | 2012-05-03 | 1 | -0/+371 |
| Breaking change set up: struct dma_handler_config is no longer part of the public API in <libmaple/dma.h>. User code which was touching these was always mistaken; it should be using dma_attach_interrupt() or dma_detach_interrupt() instead. Other than that, just move the nonportable bits in <libmaple/dma.h> and libmaple/dma.c to the appropriate places under libmaple/stm32f1/. (Ouch. This is almost everything.) Patch the (new) STM32F1 <series/dma.h> here and there to make everything compile; this is mostly limited to forward-declaring struct dma_dev and providing a hack _dma_dev_regs() declaration so inline functions in the series header can still access a device's registers. Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com> | |||||
 |
index : librambutan | |
| [no description] |
| aboutsummaryrefslogtreecommitdiffstats |