We don't need groupings around each enum, they format nicely into a
section already. Likewise, the doxygen _is_ documentation, so we don't
need extra versions of it in places. Also fix a few warnings generated.
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
- match the same logic as the f0 api
- use ADC_CFGR1_AWD1CH_VAL macro to mask the channel bits
- don't check if channel is < 18q
- enable the awd in addition to setting the selection to single channel monitoring (in following with the signature and @brief 'enable'
rtc_common_all never existed, and f3 has the same "v2" peripheral used
by ~all parts other than the f1. We don't have any f3 rtc test code,
but the existing code was clearly wrong, and this is at least including
the correct basic defines.
Fixes: https://github.com/libopencm3/libopencm3/issues/1106
A normal git clone doesn't catch these, as it _knows_ that the files are
in the git repo and should be tracked. However, downloading a tarball,
and adding it to a new git repo shows up the problem as important files
are simply not added, and would be dropped by git clean.
Reported-by: https://github.com/libopencm3/libopencm3/issues/1153
Unlike with the doxygen source generation, we can't autoguess which of
the class files are eligible automatically. Instead, make a stub hid
file, (which we can now start adding to, if desired) and include it in
all builds that include other class stubs.
* Conforms mostly to the STM32 GPIO API where possible.
* Supports pin configuration (direction, pull-up/down, etc.) as well
as pinmux configuration.
* Supports set/clear/get operations to the GPIO port/pins.
* Created base doxy header and groups to align with existing formatting.
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.
Original code used the special macros for rcc_periph_clock_enable
instead of the appropraite APB1ENR bit definition.
Switch to the correct, simpler form, using the correct parameter.
When piping to a file, if arm-none-eabi-gcc is not present in the path,
a blank linker script is created with genlink. After sourcing a bash
script to add GCC to the path, the linker script doesn't get rebuilt
due to a fresh timestamp despite failing to generate.
Updates to a base set of includes to map to the h7 include files which are
mainly based on the f7 versions for simple devices (e.g. SPI, USART, GPIO).
Custom files that have been implemented from the datasheet/ref manual include
the memory map, RCC, PWR definitions, and irq.json file for generation of
nvic files for interrupt mapping.
Additional functionality, especially PLL and tweaks for non-F7 compatible
implementations coming in future commits.
Added documentation tree configuration.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Changed dmaX_streamX to dmaX_strX in a few places for consistency
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
Karl Palsson