Use a single @defgroup for the "root" of a common heirarchy, and only
addtogroup for additions. This prevents an alphabetically "first" entry
from being used as the documentation for the entire group.
We need per device header includes to make the per target documentation
generation work properly. The dispatch headers are to dispatch to the
_target_ not directly to the final implementation, remember, the final
required headers for each may be multiple files, plus extra definitions!
STM32G4 uses v2 ADC but has EXTSEL and ALIGN fields modified, rather
than making a v3 ADC for these minor changes, the definitions have been
moved to the chip specific headers, so that the common code can work for
G4 onwards.
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.
Provide gpio examples for both f1 and "everyone else" gpio blocks
Originally filed at: https://github.com/libopencm3/libopencm3/pull/1243
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
(Merged old and new into two new examples)
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>
Python2 is end-of-life [1] since the 1st of January 2020.
Some distributions (most notably: Debian and its derivatives) will stop
providing a `python` executable in order to encourage users to specify
the interpreter language of local scripts explicitly. Users of such
environments will be forced to work around this in one of these ways:
* create a virtual environment or
* manipulate the shebangs of the scripts or
* install the python2 package (as long as it is provided by distributions)
All currently maintained distribution releases provide python3.
In the near future distributions will need to remove python2, since it
is not maintained anymore.
PEP-394 [2] recommends to reference a specific python version
(python2 or python3), if the script is not expected to run in a virtual
environment.
Closes: #1265
[1] https://www.python.org/dev/peps/pep-0373/#update-april-2014
[2] https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers
Amended-by: Karl Palsson <karlp@tweak.net.au>
* moved lpc43xx scripts to explicitly call python2, they have not been
ported, and are effectively unmaintained, but switching them to
python3 unconditionally would be unhelpful.
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.
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.
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)
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