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.
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.
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.
Sampling time and sequence length, along with the vbat channel are
specific to the f4/f7, and can't be shared with the l1 and friends.
Pull them out to their own common file.
In adc_calibrate_async() we should only set the ADCAL bit and leave the rest alone.
While in the past there were only "rs" bits in this register, this is no
longer the case.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Make exti_get_flag_status and exti_reset_request use EXTI_RPR and EXTI_FPR if present instead of EXTI_PR.
This is less precise than offered by the RPR/FPR registers, but makes
for a consistent experience in the common API.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
EXTICR on stm32g0 is in exti registers range. Previous chips used to have that
gpio port exti mux configuration accessible via AFIO_EXTICR or SYSCFG_EXTICR.
Also, the new chip now use 8 bits coded value instead of previously 4 for the
extcr mux selection value (see AFIO/SYSCFG/EXTI_EXTICR_FIELDSIZE)
Let's define two helpers: EXTICR_SELECTION_REG (to get proper AFIO/SYSCFG/
EXTI_EXTICR register) and EXTICR_SELECTION_FIELDSIZE (to get proper AFIO/SYSCFG/
EXTI_EXTICR_FIELDSIZE value), and use it them exti_select_source to determine
exticr mux selection bits shift and mask.
flash_unlock_acr allows to unlock RUN_PD bit from FLASH_ACR register. Relock is done automatically
when writing 0 to RUN_PD, so no flash_lock_acr method.
See https://github.com/libopencm3/libopencm3/issues/873
Commentary describing this patch originally by zyp:
```
After looking further into it, I've concluded that my preliminary
analysis looks correct. The problem is that setting CNAK before
the SETUP complete event is received causes a race condition. The
SETUP callback is called when the SETUP packet event is received,
which means that setting CNAK from the callback is too early.
Originally the problem was that CNAK was set by ep_read() which is
called by the callback. #672 solved this by moving CNAK out of
ep_read() and calling it after the SETUP complete event is received
instead.
The regression by #785 is caused by the introduction of flow control
calls into the SETUP callback. They also set CNAK.
To solve this properly, I propose changing the event handling code
to only call the SETUP callback after the SETUP complete event is
received. Unfortunately, this implies that the callback can't call
ep_read() itself anymore, because the packet has to be read out of
the FIFO before the SETUP complete event arrives. This implies a
change of the API between the hardware drivers and _usbd_control_setup().
```
L1 (st_usbfs) works and passes tests as before change
F4 (dwc_otg_fs) works and now passes tests. (yay)
LM4f still compiles, and has had the same style of implementation as
st_usbfs, however has not been tested on any hardware.
Fixes https://github.com/libopencm3/libopencm3/issues/476
Sets USB_COUNTn_RX reg fields : bits <14:10> are NUM_BLOCK; bit 15 is BL_SIZE.
- When (size <= 62), BL_SIZE must be 0 and NUM_BLOCK set to (size / 2).
- When (size > 62), BL_SIZE must be 1 and NUM_BLOCK=((size / 32) - 1).
Previous code improperly set NUM_BLOCK and assumed the requested size was set.
Now, we use the next largest legal buffer size. Examples:
size BL_SIZE NUM_BLOCK => Actual bufsize
0 0 0 ??? (illegal !)
1 0 1 2
63 1 1 64
Algo is valid for F102, F103 and F0 devices (USB_FS peripheral).
In addition, the new usb_set_ep_rx_bufsize() function returns the actual
size set.
Tested-by: Karl Palsson <karlp@tweak.net.au>
LPUART1 needs BRR to be 256 times the normal value.
Doing this with 64 bit math would work, but that pulls in quite a lot of
code for every platform, even if they don't have LPUART.
A little bit of maths, thanks to zyp on irc, lets us keep it in 32bit,
provided people don't try and use > 16MBaud on LPUARTs
Originally tracked via https://github.com/libopencm3/libopencm3/pull/888
This shows what is _actually_ different for f7. A couple of option
bits, and a renaming of bit 7 of the status register, from Program
Sequence Error to Erase Sequence Error.
We keep the separate implementation of wait_for_last_operation, to meet
the "suggestions" of the reference manual to insert a DSB instruction.
Keeping the renamed bit/functions also requires us to keep separate
implementations of the flag clearing functions
F3's flash interface is actually quite different, don't try and force
sharing code that isn't really related. The "PGERR" is a very different
bit than the parallelism error that f2/4/7 have.
Comments were not consistent, and this serves no purpose. There's no
reason to explicitly lock the flash first before unlocking. These bits
are simply set when the keys are written.
