While this appears to be a backward change, this moves the _register_
definitions (their addresses) and the actually specific to f4/f7
numbering back into the explicit headers. Potentially this could be
pulled out again, but it's not much code.
This then allows the stm32l1 to use all the rest of this code, with the
differences really being just the addresses of the registers.
Never seen any reason for these noisy verbose defines. They're not
helpful, and we've never needed them for doing sequence setting code
anyway. Just drop them.
GD32F1X0 (X can be 3, 5, 7 and 9) is a series of Cortex-M3 MCUs by
GigaDevice, which features pin-to-pin package compatibility with
STM32F030 MCU line. F150 adds USB support to F130, and F170/F190 adds
CAN support.
Currently the code mainly targets GD32F130 and F150 chips. Some register
are different between F130/150 and F170/190, just like the difference
between STM32F1 Performance line and Connectivity line.
From the perspective of registers and memory map, GD32F1X0 seems like a
mixture between STM32F1 and STM32F0 (because it is designed to be
pin-to-pin compatible with F0, but with Cortex-M3 like F1). A bunch of
code are shared between STM32 and GD32, and these code are specially
processed to include the GD32 headers instead of STM32 headers when meet
GD32F1X0.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
gd32/rcc.[ch] are forks of stm32f1/rcc
gd32/flash.[ch] are forks of stm32f0/flash
No attempts at deduplicating this have been done at this stage. We can
see where they move in the future.
While on all current chips, exticr gpio port mux selection is coded on 4 bits,
stm32g0 EXTI_EXTICR register uses 8 bits. Align all exti header to reference
that value (was previously defined for f0 as SYCFG_EXTICR_SKIP)
flash_unlock_acr allows to unlock RUN_PD bit from FLASH_ACR register. Relock is done automatically
when writing 0 to RUN_PD, so no flash_lock_acr method.
It's always stream on the "new" dma controller (unless it's channel....)
Fix a couple of inconsistent prototypes that had carried over from f1
originally. Reported by vampi on irc.
I2C3 is on many parts, but wasn't properly supported with the register
definitions. Declare them centrally, just depending on the memorymap
defining them. On some parts, the rcc bits were defined, but not the
base registers.
Fixes: https://github.com/libopencm3/libopencm3/issues/820
