We still need stub .c files as we're using shared common files, so .d
tracking doesn't work. It lets us setup basic introductory text anyway,
and there will be .c files eventually, so acceptable.
The random number generator on the STM32H7 is identical to the v1 RNG
already present in the library. So use that, and make sure that the RCC
knows about the peripheral.
Originally filed at: https://github.com/libopencm3/libopencm3/pull/1244
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
* whitespace changes from review
Originally tracked at https://github.com/libopencm3/libopencm3/pull/958
While it doesn't work for everyone, this is clearly the basic first
steps required for any progress to be made.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Verify all hardware differences between F1 and F4/F7 Ethernet hardware.
Flags registers missing on F1 as well.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Wrong since original commit in 2013.
LCD code can't actually automatically determine clock speed if it's HSE,
as we don't know here whether what HSE is, nor what it's divided by.
For more fun, that old 2014 API doesn't have any way of flagging that it
failed either. Hooray.
We did have
* _HPRE_SYSCLK_DIVN (3 parts)
* _HPRE_DIVN (5 parts)
* _HPRE_DIV_N (4 parts)
Unify all on _HPRE_DIVN. Provide deprecated definitions to not break
everything at once.
Also, standardize on "NODIV" instead of DIVNONE.
These defines were simply a word containing the number, instead of the
number itself. This provides no value, and implies that there's a
limited set of values. The list was _already_ incomplete, so
misleading, _and_ just noise to maintain. Burn it all.
(well, burn it just a little bit, provide deprecated aliases on the old
values so that code keeps compiling)
The order of the UCPD1 and UCPD2 bits as described by the
rcc_periph_clken and rcc_periph_rst enums is swapped with regard to the
datasheet. Swap them.
Fixes: https://github.com/libopencm3/libopencm3/issues/234
uses the new mechanisms introduced to address a similar problem on F7.
Tested on a medium density part (0x429) that returns the same ids as
before, tested on a high density part that now _doesnt_, but that's now
correct :)
Reduced the sea of enums, and renamed config parameters to match other
implementations, cribbing off of the G0 config, as it is closer to the level
of complexity. Updated initialization code to utilize the new values.
Added flash and LDO configuration from RCC init to be more consistent with
STM32 platform initialization.
PLL configuration on the H7 is pretty involved, and takes a number of
configurations to make it work. In order to make peripheral drivers a bit
easier to implement, working with a soft clock tree in the rcc module which
stores the clock settings for each clock as they are setup such that users
can request the clock value from the RCC module for configuration. Added
getter for the clock which allows the user to pass the base address of the
peripheral, and get the peripheral clock value for convenience.
Clock configuration is still missing values for setting up all of the kernel
clocks for the peripherals, but this is in work, and there is a framework to
do so.
Have tested to 400MHz without issue. Peripherals that are explicitly supported
are working and the clock tree values appear to follow correctly.
Added LDO settings to allow setting the scaling to support high frequencies.
In this commit, support for the different base addresses for different
F7 parts is added, but the mechanism is now in place for L1 and others.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
(whitespace fixed, commit msg reworded)
We don't need groupings around each enum, they format nicely into a
section already. Likewise, the doxygen _is_ documentation, so we don't
need extra versions of it in places. Also fix a few warnings generated.
rtc_common_all never existed, and f3 has the same "v2" peripheral used
by ~all parts other than the f1. We don't have any f3 rtc test code,
but the existing code was clearly wrong, and this is at least including
the correct basic defines.
Fixes: https://github.com/libopencm3/libopencm3/issues/1106
Unlike with the doxygen source generation, we can't autoguess which of
the class files are eligible automatically. Instead, make a stub hid
file, (which we can now start adding to, if desired) and include it in
all builds that include other class stubs.
* Conforms mostly to the STM32 GPIO API where possible.
* Supports pin configuration (direction, pull-up/down, etc.) as well
as pinmux configuration.
* Supports set/clear/get operations to the GPIO port/pins.
* Created base doxy header and groups to align with existing formatting.
Updates to a base set of includes to map to the h7 include files which are
mainly based on the f7 versions for simple devices (e.g. SPI, USART, GPIO).
Custom files that have been implemented from the datasheet/ref manual include
the memory map, RCC, PWR definitions, and irq.json file for generation of
nvic files for interrupt mapping.
Additional functionality, especially PLL and tweaks for non-F7 compatible
implementations coming in future commits.
Added documentation tree configuration.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Changed dmaX_streamX to dmaX_strX in a few places for consistency
v2 "single" peripheral with a couple of tweaks :
- added registers to configure two additionnal advanced analog watchdog.
- different adc sampling time time based on channel groups.
- 8 steps adc sequence injection, using chselr/chselrmode.
And a note on the rm explaining that after every configuration change to ADC_CFGR1's
SCANDIR or CHSELRMOD or CHSELR register, user need to check that configuration
is applied before any other modification / adc conversion start.. making adc_set_reqular
a bit painfull to read..
DMAMUX peripheral is a dma request router/trigger, present on g0, wb, h7 and l4+.
Basically it allows to easily map peripheral requests to whatever dma channel we
want to use (similarily to the DMA_CSELR register, but without limitation) but,
it also also adds some clever dma request synchronization and even some dma request
generation logic via internal request generator "channels", allowing some requests
chaining, or triggering reqs from non dma capable peripherals.
nb: g0 only features 1 dmamux bloc, supports 7 irq and 4 generators, l4+ supports 13
dma channels and 3 generators and h7 has two dmamuxes, with support for the 15 dma
channels and 7 generators - so as much CxCR and RGxCR register - but they are bit
to bit compatible - excluding of course the sync/sig and dma requests id mappings.
btw, currently, request generator channels are defined in common header, but maybe
we should define them in device header ? or we dont care (like for dma channels,
only defined in dma_f24 but not for other devices ?).
See ST AN5224 for more information
same same, bit for bit, except not ;) - Channel request mapping now
depends on a new DMAMUX peripheral, and there's no default preset.
So, before enabling dma channel after its configuration, request
must be configured by :
dmamux_set_dma_channel_request(DMAMUX1, DMA_CHANNELx, request_number_from_datasheet);
Updates the main memory map and the makefile.
Adds the SWM050 to devices.data, so that a linker script can be automatically generated.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
I apparently based memorymap.h on previously written header without noticing
that g0 has only one apb despite a big hole in the memory space and addresses
matching usual apb1/apb2 split..
Kevin Stefanik