bad Karl, you can't just _start_ using pragma on common files, and
expect it to keep working. Just finish, convert them fully to pragma.
pros: no more weird @cond boilerplate mess and trailing #endifs. easier
to follow
cons: no warning for people who deliberately try and include things in
bad orders.
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.
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
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.
