FLASH_BASE was already defined for some and PERIPH_BASE for all but one,
but this makes these available for all families. Note that the value is
identical for all familes (I doublechecked the more exotic ones such
STM32H7), but it is still useful to have these defines to make code more
readable and so that libopencm3 users can write portable code without
having to check that these are identical on all STM32 families.
Added some descriptions for missing parameters, (hopefully) clarified
some along the way. Fixed all can related warnings in doxygen logs.
Added doxgen tags where meaningful comments had been provided. Dropped
redundant comment separators.
Add stm32h7 support for FDCAN peripheral. Source level compatibility is
provided with stm32g4. Additional features of stm32h7 such as
configurable buffers are supported. Implementation offers feature parity
with stm32g4 implementation.
Add stm32g4 support for FDCAN peripheral. Normal / FDCAN operation
supported, bitrate switching and filtering supported via API.
Timestamping and transmit event buffer support in API are TBD.
Originally tracked as: https://github.com/libopencm3/libopencm3/pull/1317
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Worked in nuances for differences between versions of STM32H7 devices, such as
handling of ODEN, explicit SCUEN bit, and different VOS mappings. This has
been validated on the STM32H7A3 and STM32H743 MCUs.
Move the STM32F4 QuadSPI peripheral defines to the common folder as the
F4 and H7 variants of the IP share almost all the same bits. For those
bits that are separate put them into their own headers.
The usart_common_fifos uses a very nice style of docs in the headers, so
inline help works in some editors, without having to have the source of
the library available as well. However, it means that the group
definition with the name doesn't appear until later, and then the title
is ignored. Move the description to the header definition instead.
Old API required users to manually construct bit maps frm opaquely named
defines, with little help. It also was a pure OR operation, with no way
to ever clear bits.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
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.