djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
784909ce16
circuitpython/stmhal/dma.h

104 lines
3.9 KiB
C
Raw Normal View History

stmhal: Factor out DMA initialisation code from spi.c. This is so that the DMA can be shared by multiple peripherals.
2015-06-10 08:06:48 -04:00
/*
all: Use the name MicroPython consistently in comments There were several different spellings of MicroPython present in comments, when there should be only one.
2017-06-30 03:22:17 -04:00
* This file is part of the MicroPython project, http://micropython.org/
stmhal: Factor out DMA initialisation code from spi.c. This is so that the DMA can be shared by multiple peripherals.
2015-06-10 08:06:48 -04:00
*
* The MIT License (MIT)
*
* Copyright (c) 2015 Damien P. George
*
* 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
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* 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.
*/
all: Unify header guard usage. The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h
2017-06-29 17:14:58 -04:00
#ifndef MICROPY_INCLUDED_STMHAL_DMA_H
#define MICROPY_INCLUDED_STMHAL_DMA_H
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
typedef struct _dma_descr_t dma_descr_t;
#if defined(MCU_SERIES_F4) || defined(MCU_SERIES_F7)
extern const dma_descr_t dma_I2C_1_RX;
extern const dma_descr_t dma_SPI_3_RX;
stmhal/i2c: Add support for I2C4 hardware block on F7 MCUs.
2016-11-24 19:21:18 -05:00
extern const dma_descr_t dma_I2C_4_RX;
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
extern const dma_descr_t dma_I2C_3_RX;
extern const dma_descr_t dma_I2C_2_RX;
extern const dma_descr_t dma_SPI_2_RX;
extern const dma_descr_t dma_SPI_2_TX;
extern const dma_descr_t dma_I2C_3_TX;
stmhal/i2c: Add support for I2C4 hardware block on F7 MCUs.
2016-11-24 19:21:18 -05:00
extern const dma_descr_t dma_I2C_4_TX;
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
extern const dma_descr_t dma_DAC_1_TX;
extern const dma_descr_t dma_DAC_2_TX;
extern const dma_descr_t dma_SPI_3_TX;
extern const dma_descr_t dma_I2C_1_TX;
extern const dma_descr_t dma_I2C_2_TX;
stmhal/sdcard: Add support for SDMMC2 on F7 MCUs. By default the SDIO (F4) or SDMMC1 (L4, F7) is used as the SD card peripheral, but if a board config defines MICROPY_HW_SDMMC2_CK and other pins then the SD card driver will use SDMMC2.
2017-03-30 02:55:21 -04:00
extern const dma_descr_t dma_SDMMC_2_RX;
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
extern const dma_descr_t dma_SPI_1_RX;
extern const dma_descr_t dma_SPI_5_RX;
extern const dma_descr_t dma_SDIO_0_RX;
extern const dma_descr_t dma_SPI_4_RX;
extern const dma_descr_t dma_SPI_5_TX;
extern const dma_descr_t dma_SPI_4_TX;
extern const dma_descr_t dma_SPI_6_TX;
extern const dma_descr_t dma_SPI_1_TX;
stmhal/sdcard: Add support for SDMMC2 on F7 MCUs. By default the SDIO (F4) or SDMMC1 (L4, F7) is used as the SD card peripheral, but if a board config defines MICROPY_HW_SDMMC2_CK and other pins then the SD card driver will use SDMMC2.
2017-03-30 02:55:21 -04:00
extern const dma_descr_t dma_SDMMC_2_TX;
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
extern const dma_descr_t dma_SPI_6_RX;
extern const dma_descr_t dma_SDIO_0_TX;
#elif defined(MCU_SERIES_L4)
extern const dma_descr_t dma_ADC_1_RX;
extern const dma_descr_t dma_ADC_2_RX;
extern const dma_descr_t dma_SPI_1_RX;
extern const dma_descr_t dma_I2C_3_TX;
extern const dma_descr_t dma_ADC_3_RX;
extern const dma_descr_t dma_SPI_1_TX;
extern const dma_descr_t dma_I2C_3_RX;
extern const dma_descr_t dma_DAC_1_TX;
extern const dma_descr_t dma_SPI_2_RX;
extern const dma_descr_t dma_I2C_2_TX;
extern const dma_descr_t dma_DAC_2_TX;
extern const dma_descr_t dma_SPI_2_TX;
extern const dma_descr_t dma_I2C_2_RX;
extern const dma_descr_t dma_I2C_1_TX;
extern const dma_descr_t dma_I2C_1_RX;
extern const dma_descr_t dma_SPI_3_RX;
extern const dma_descr_t dma_SPI_3_TX;
stmhal: Correct DMA to allow SD card on L4 MCUs.
2016-06-29 07:26:21 -04:00
extern const dma_descr_t dma_SDIO_0_TX;
extern const dma_descr_t dma_SDIO_0_RX;
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
#endif
stmhal: Turn off DMA clocks when idle for 100 msec Turning on each DMA block increases the current consumption by about 8 mA. This code adds an idle timer for each DMA block and turns off the clocks when no streams are in use for 128 msec. Having a small timeout allows for improved performance when back-to-back transfers are being performed. The 128 msec is basically a guess.
2015-11-15 20:02:43 -05:00
typedef union {
uint16_t enabled; // Used to test if both counters are == 0
uint8_t counter[2];
} dma_idle_count_t;
extern volatile dma_idle_count_t dma_idle;
#define DMA_IDLE_ENABLED() (dma_idle.enabled != 0)
stmhal: On SysTick IRQ, only process one DMA channel at a time. This can be generalised if/when more processing is needed by SysTick. Thanks to @chuckbook for the idea.
2015-11-24 10:40:59 -05:00
#define DMA_SYSTICK_MASK 0x0e
stmhal: Turn off DMA clocks when idle for 100 msec Turning on each DMA block increases the current consumption by about 8 mA. This code adds an idle timer for each DMA block and turns off the clocks when no streams are in use for 128 msec. Having a small timeout allows for improved performance when back-to-back transfers are being performed. The 128 msec is basically a guess.
2015-11-15 20:02:43 -05:00
#define DMA_MSECS_PER_SYSTICK (DMA_SYSTICK_MASK + 1)
#define DMA_IDLE_TICK_MAX (8) // 128 msec
#define DMA_IDLE_TICK(tick) (((tick) & DMA_SYSTICK_MASK) == 0)
stmhal/dma.c: Modify dma_init() to accept init struct as an argument This removes hard-coded DMA init params from dma_init(), instead defining these parameters in a DMA_InitTypeDef struct that gets passed as an argument to dma_init() This makes dma_init more generic so it can be used for I2S and SD Card, which require different initialization parameters.
2015-06-22 09:24:59 -04:00
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
void dma_init(DMA_HandleTypeDef *dma, const dma_descr_t *dma_descr, void *data);
void dma_init_handle(DMA_HandleTypeDef *dma, const dma_descr_t *dma_descr, void *data);
void dma_deinit(const dma_descr_t *dma_descr);
void dma_invalidate_channel(const dma_descr_t *dma_descr);
stmhal: On SysTick IRQ, only process one DMA channel at a time. This can be generalised if/when more processing is needed by SysTick. Thanks to @chuckbook for the idea.
2015-11-24 10:40:59 -05:00
void dma_idle_handler(int controller);
stmhal: L4: Adapt DMA to be able to support STM32L4 MCU series. The main thing is to change the DMA code in a way that the structure DMA_Stream_TypeDef (which is similar to DMA_Channel_TypeDef on stm32l4) is no longer used outside of dma.c, as this structure only exists for the F4 series. Therefore I introduced a new structure (dma_descr_t) which handles all DMA specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.
2016-03-22 06:28:35 -04:00
all: Unify header guard usage. The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h
2017-06-29 17:14:58 -04:00
#endif // MICROPY_INCLUDED_STMHAL_DMA_H
Reference in New Issue Copy Permalink