Allows for abstraction for code that's dependent on knowing the source clock
for a peripheral. Implemented a few core peripherals that tend to have clock
tree differences between platforms (USART, timers, I2C, SPI).
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
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 already had the hooks for ccmram and ram1 and ram2 and ram3 and xsram
for "other" ram sections, but there was no method, out of the box, for
placing a function in "normal" ram. The "easy" method of labelling a
function as ".data.someramfunc" causes warnings because code isn't meant
to have a name like ".data*" so we must explicitly add a new code
section.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Add support for a section(s) ".noinit*" that will be allocated in ram,
but not cleared or initialized. This can be used for passing variables
between a bootloader and an app for instance, or even just between
restarts of your application.
Without any assigned usages of the section, there is zero change in ram
usage. The align does nothing when the prior section was already
aligned.
We were never going to be capable of supporting every single part
variant with their own files, so stop trying. We've been supporting the
linker script generator for a long time now, so move on from these old
static files.
Breaking: if you were using one of these, and don't wish to use the
linker script generator, you should simply declare a stub linker script,
and include the generic section definitions file, and provide this in
your own application.
Old:
LDSCRIPT = $(OPENCM3_DIR)/lib/stm32/l1/stm32l15xxb.ld
New (linker script generator):
DEVICE=stm32l151cb
New (manual):
* Add file mymemorymap.ld, with contents similar too:
```
MEMORY
{
rom (rx) : ORIGIN = 0x08000000, LENGTH = 256K
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 48K
}
/* Include the common ld script. */
INCLUDE cortex-m-generic.ld
```
LDSCRIPT=mymemorymap.ld
See ld/README for more information on using the linker script generator
Replaced & with &&
Wait for all three bits to be set - SB, MSL, and BUSY.
Old code worked by chance, use booleans to correctly convey intent.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
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)
