suspect-devices/circuitpython/ports/stm32/dma.c, branch mainCircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=main2019-10-13T15:08:52+00:00remove ports/stm322019-10-13T15:08:52+00:00Dan Halberthalbert@halwitz.org2019-10-13T15:08:52+00:00urn:sha1:fc033bd954a46156d6902392f8ae21ac2872bb1cstm32: Add support for STM32F0 MCUs.2018-05-28T11:49:49+00:00Damien Georgedamien.p.george@gmail.com2018-05-28T08:10:53+00:00urn:sha1:ea7e747979c2f27eb90f9a6ba292c500eb288dd4stm32/dma: Fix duplicate typedef of struct, it's typedef'd in dma.h.2018-05-04T05:35:43+00:00Damien Georgedamien.p.george@gmail.com2018-05-04T05:35:43+00:00urn:sha1:b614dc73b085c803f465f1c920553e13f52aee00stm32/irq: Define IRQ priorities directly as encoded hardware values.2018-05-02T04:41:02+00:00Damien Georgedamien.p.george@gmail.com2018-05-02T04:41:02+00:00urn:sha1:a03e6c1e05203bb71ebee50af2a41de404b05078
For a given IRQn (eg UART) there's no need to carry around both a PRI and
SUBPRI value (eg IRQ_PRI_UART, IRQ_SUBPRI_UART). Instead, the IRQ_PRI_UART
value has been changed in this patch to be the encoded hardware value,
using NVIC_EncodePriority. This way the NVIC_SetPriority function can be
used directly, instead of going through HAL_NVIC_SetPriority which must do
extra processing to encode the PRI+SUBPRI.
For a priority grouping of 4 (4 bits for preempt priority, 0 bits for the
sub-priority), which is used in the stm32 port, the IRQ_PRI_xxx constants
remain unchanged in their value.
This patch also "fixes" the use of raise_irq_pri() which should be passed
the encoded value (but as mentioned above the unencoded value is the same
as the encoded value for priority grouping 4, so there was no bug from this
error).
stm32/dma: Always deinit/reinit DMA channels on L4 MCUs.2018-05-02T03:41:23+00:00Peter D. Graypeter@conalgo.com2018-04-13T13:14:44+00:00urn:sha1:266446624fc055e988782577286fe91efbda438e
The problem is the existing code which tries to optimise the
reinitialisation of the DMA breaks the abstraction of the HAL. For the
STM32L4 the HAL's DMA setup code maintains two private vars (ChannelIndex,
DmaBaseAddress) and updates a hardware register (CCR).
In HAL_DMA_Init(), the CCR is updated to set the direction of the DMA.
This is a problem because, when using the SD Card interface, the same DMA
channel is used in both directions, so the direction bit in the CCR must
follow that.
A quick and effective fix for the L4 is to simply call HAL_DMA_DeInit() and
HAL_DMA_Init() every time.
stm32/dac: Add support for H7 MCUs.2018-04-10T04:21:26+00:00iabdalkaderi.abdalkader@gmail.com2018-04-05T23:04:08+00:00urn:sha1:90bb98e83daf714f22eb3f8af6ae57ec4078ee32
Includes a fix for H7 DAC DMA requests.
stm32/dma: Remove H7 SDMMC DMA descriptors.2018-03-28T02:23:40+00:00iabdalkaderi.abdalkader@gmail.com2018-03-22T01:49:59+00:00urn:sha1:9b9896b44d3784896ac8ca64bc1746956c122f6a
The H7 SD peripheral has direct connection to MDMA instead.
stm32: Use STM32xx macros instead of MCU_SERIES_xx to select MCU type.2018-03-16T23:42:50+00:00Damien Georgedamien.p.george@gmail.com2018-03-16T23:42:50+00:00urn:sha1:e37b8ba5a55c99dbd1e69eb1c99651307b22fd3e
The CMSIS files for the STM32 range provide macros to distinguish between
the different MCU series: STM32F4, STM32F7, STM32H7, STM32L4, etc. Prefer
to use these instead of custom ones.
stm32/dma: Add DMA support for H7 MCUs.2018-03-09T04:12:19+00:00iabdalkaderi.abdalkader@gmail.com2018-02-23T18:18:52+00:00urn:sha1:0e51e4d13986e7dc65eb6186253cc1812d966647stm32: Update HAL macro and constant names to use newer versions.2018-02-13T04:37:35+00:00Damien Georgedamien.p.george@gmail.com2018-02-13T04:37:35+00:00urn:sha1:3eb0694b97c6a8f0e93b874549aac40d8b78b0e5
Newer versions of the HAL use names which are cleaner and more
self-consistent amongst the HAL itself. This patch switches to use those
names in most places so it is easier to update the HAL in the future.