2010-10-20 09:53:43 +02:00
|
|
|
/******************************************************************************
|
|
|
|
* The MIT License
|
|
|
|
*
|
|
|
|
* Copyright (c) 2010 Michael Hope.
|
2012-04-26 23:33:56 +02:00
|
|
|
* Copyright (c) 2012 LeafLabs, LLC.
|
2010-10-20 09:53:43 +02:00
|
|
|
*
|
2011-06-07 20:44:39 +02:00
|
|
|
* Permission is hereby granted, free of charge, to any person
|
|
|
|
* obtaining a copy of this software and associated documentation
|
|
|
|
* files (the "Software"), to deal in the Software without
|
|
|
|
* restriction, including without limitation the rights to use, copy,
|
|
|
|
* modify, merge, publish, distribute, sublicense, and/or sell copies
|
|
|
|
* of the Software, and to permit persons to whom the Software is
|
2010-10-20 09:53:43 +02:00
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
2011-06-07 20:44:39 +02:00
|
|
|
* The above copyright notice and this permission notice shall be
|
|
|
|
* included in all copies or substantial portions of the Software.
|
2010-10-20 09:53:43 +02:00
|
|
|
*
|
2011-06-07 20:44:39 +02:00
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
2010-10-20 09:53:43 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
/**
|
2012-04-26 23:33:56 +02:00
|
|
|
* @file libmaple/dma.c
|
2011-04-08 04:23:01 +02:00
|
|
|
* @author Marti Bolivar <mbolivar@leaflabs.com>;
|
|
|
|
* Original implementation by Michael Hope
|
2012-04-26 23:33:56 +02:00
|
|
|
* @brief Portable DMA routines.
|
2010-10-20 09:53:43 +02:00
|
|
|
*/
|
|
|
|
|
Move public headers to include directories; related cleanups.
Move libmaple/*.h to (new) libmaple/include/libmaple/. The new
accepted way to include a libmaple header foo.h is with:
#include <libmaple/foo.h>
This is more polite in terms of the include namespace. It also allows
us to e.g. implement the Arduino SPI library at all (which has header
SPI.h; providing it was previously impossible on case-insensitive
filesystems due to libmaple's spi.h).
Similarly for Wirish.
The old include style (#include "header.h") is now deprecated.
libmaple/*.h:
- Change include guard #defines from _FOO_H_ to _LIBMAPLE_FOO_H_.
- Add license headers where they're missing
- Add conditional extern "C" { ... } blocks where they're missing
(they aren't always necessary, but we might was well do it against
the future, while we're at it.).
- Change includes from #include "foo.h" to #include <libmaple/foo.h>.
- Move includes after extern "C".
- Remove extra trailing newlines
Note that this doesn't include the headers under libmaple/usb/ or
libmaple/usb/usb_lib. These will get fixed later.
libmaple/*.c:
- Change includes from #include "foo.h" to #include <libmaple/foo.h>.
Makefile:
- Add I$(LIBMAPLE_PATH)/include/libmaple to GLOBAL_FLAGS. This allows
for users (including Wirish) to migrate their code, but should go
away ASAP, since it slows down compilation.
Wirish:
- Move wirish/**/*.h to (new) wirish/include/wirish/. This ignores
the USB headers, which, as usual, are getting handled after
everything else.
- Similarly generify wirish/boards/ structure. For each supported
board "foo", move wirish/boards/foo.h and wirish/boards/foo.cpp to
wirish/boards/foo/include/board/board.h and
wirish/boards/foo/board.cpp, respectively. Also remove the #ifdef
hacks around the .cpp files.
- wirish/rules.mk: put wirish/boards/foo/include in the include path
(and add wirish/boards/foo/board.cpp to the list of sources to be
compiled). This allows saying:
#include <board/board.h>
instead of the hack currently in place. We can allow the user to
override this setting later to make adding custom board definitions
easier.
- Disable -Werror in libmaple/rules.mk, as the current USB warnings
don't let the olimex_stm32_h103 board compile. We can re-enable
-Werror once we've moved the board-specific bits out of libmaple
proper.
libraries, examples:
- Update includes accordingly.
- Miscellaneous cosmetic fixups.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
2011-11-15 18:45:43 +01:00
|
|
|
#include <libmaple/dma.h>
|
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>
2012-06-12 23:01:12 +02:00
|
|
|
#include "dma_private.h"
|
|
|
|
#include "stm32_private.h"
|
2010-12-30 03:30:42 +01:00
|
|
|
|
2011-04-08 04:23:01 +02:00
|
|
|
/*
|
|
|
|
* Convenience routines
|
2010-10-20 09:53:43 +02:00
|
|
|
*/
|
2011-04-08 04:23:01 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @brief Initialize a DMA device.
|
|
|
|
* @param dev Device to initialize.
|
|
|
|
*/
|
|
|
|
void dma_init(dma_dev *dev) {
|
|
|
|
rcc_clk_enable(dev->clk_id);
|
2010-10-20 09:53:43 +02:00
|
|
|
}
|
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>
2012-06-12 23:01:12 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Private API
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum dma_atype _dma_addr_type(__io void *addr) {
|
|
|
|
switch (stm32_block_purpose((void*)addr)) {
|
|
|
|
/* Notice we're treating the code block as memory here. That's
|
|
|
|
* correct for addresses in Flash and in [0x0, 0x7FFFFFF]
|
|
|
|
* (provided that those addresses are aliased to Flash, SRAM, or
|
|
|
|
* FSMC, depending on BOOT[01] and possibly SYSCFG_MEMRMP). It's
|
|
|
|
* not correct for other addresses in the code block, but those
|
|
|
|
* will (hopefully) just fail-fast with transfer or bus errors. If
|
|
|
|
* lots of people get confused, it might be worth being more
|
|
|
|
* careful here. */
|
|
|
|
case STM32_BLOCK_CODE: /* Fall through */
|
|
|
|
case STM32_BLOCK_SRAM: /* ... */
|
|
|
|
case STM32_BLOCK_FSMC_1_2: /* ... */
|
|
|
|
case STM32_BLOCK_FSMC_3_4:
|
|
|
|
return DMA_ATYPE_MEM;
|
|
|
|
case STM32_BLOCK_PERIPH:
|
|
|
|
return DMA_ATYPE_PER;
|
|
|
|
case STM32_BLOCK_FSMC_REG: /* Fall through */
|
|
|
|
/* Is this right? I can't think of a reason to DMA into or out
|
|
|
|
* of the FSMC registers. [mbolivar] */
|
|
|
|
case STM32_BLOCK_UNUSED: /* ... */
|
|
|
|
case STM32_BLOCK_CORTEX_INTERNAL: /* ... */
|
|
|
|
return DMA_ATYPE_OTHER;
|
|
|
|
default:
|
|
|
|
ASSERT(0); /* Can't happen */
|
|
|
|
return DMA_ATYPE_OTHER;
|
|
|
|
}
|
|
|
|
}
|