by making it vaguer. These days, there's extra timers that support the
BDTR register, so the simple "advanced" timer description is no longer
sufficiently clear. You have to check your particular reference manual.
Fixes: https://github.com/libopencm3/libopencm3/issues/1378
Fix the bug that the iwdg counter is not refreshed after the configurationis complete, if this counter is not refreshed after the configuration is completed, the first iwdg counting period will be as long as 26 seconds.
Fixes: https://github.com/libopencm3/libopencm3/pull/1333
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Fix incorrect way of acknowledging FIFO processing. Old code ORed old
value of register with index of FIFO buffer just processed, which
generated invalid value for acknowledge. This caused FIFO to repeatedly
returning same content. Both fdcan_receive() and fdcan_release_fifo were
affected.
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>
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>
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!
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.
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>
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)
According to L4/L0/G0 RM, in case of clock error, interrupt flag must
be cleared, and CECS flag should be cleared as soon as clock meets
requirement.
Reviewed-on: https://github.com/libopencm3/libopencm3/pull/1062
If noise source error occurs, flag must be cleared and data register
must be discarded (at least 12 reads to flush pipeline on G0). Other
device mention start/restart of chip, so, do both (better safe than
sorry).
Reviewed-on: https://github.com/libopencm3/libopencm3/pull/1062
The original rcc_peripheral_enable_clock aren't explicitly deprecated,
as they do let you enable multiple periphs in one call. But they're
error prone, from user feedback, so update the docs to ensure people
know what the other options are.
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
Add basically what's needed to have some minimal but usefull subset of
function for a timer: irqs, compare, period, out polarity, enable/disable
and start.
