v2 "single" peripheral with a couple of tweaks :
- added registers to configure two additionnal advanced analog watchdog.
- different adc sampling time time based on channel groups.
- 8 steps adc sequence injection, using chselr/chselrmode.
And a note on the rm explaining that after every configuration change to ADC_CFGR1's
SCANDIR or CHSELRMOD or CHSELR register, user need to check that configuration
is applied before any other modification / adc conversion start.. making adc_set_reqular
a bit painfull to read..
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
same same, bit for bit, except not ;) - Channel request mapping now
depends on a new DMAMUX peripheral, and there's no default preset.
So, before enabling dma channel after its configuration, request
must be configured by :
dmamux_set_dma_channel_request(DMAMUX1, DMA_CHANNELx, request_number_from_datasheet);
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.
Regular rng peripheral, with one additional bit : clock error detection
apparently available on l4 chips). Curiously, Clock error detection is
_disabled_ when bit is set, but bit is cleared by default, so peripheral
/ clock error detection behaves like all other chips..
NB: RNG need proper rcc_ccicr_rngsel bits set to work, no clock is set by
default. Note also that on that chip fRNGCLK must be higher than fHCLK/32
doxygen really wants the @defgroup _and_ the @addtogroup to both have
the full name, matching identically, to avoid all warnings.
Standardize on the "CAPS_PERIPH peripheral API" style.
The leading - makes it rather inconsistent with the majority of other
projects around the world. Use the form everyone else uses.
To solve this, properly pass prefix to inner makes as was always
intended.
Fixes: https://github.com/libopencm3/libopencm3/issues/1058
Some families had partially moved to peripheral api, and others were
only documenting common code, but not specific code. Delete dummy .c
files, and check that all specific apis are also being documented, not
just common apis.
Functions that are already documented in the top level common api.h file
won't add any more documentation from later .c files. Keep docs for
part specifics, in the .h files where they're accessible to IDEs and
also the documentation generation, and drop all (including the redundant
ones) from the .c file.
the group defaults to the implicit container based on location, so drop
all the explicit @ingroups, less to maintain. Properly use /**@}*/ to
close all groups too, even though it mostly seems to have worked anyway.
Properly close all groups opened for files.
here, it's a bit of a mess.. G0 flash controller does not really
match exsting feature split. IE it has instruction cache only ..
so, no flash_idcache.c as it. flash_common_f could be used, but
flash_unlock would not take care of option byte ?
prefetch, icache and lock is ok. I had no look at flash programming
or erase yet..
