Use the usart-common base plus the usart-v2 code, instead of private
implementations. Less code, more common apis across targets.
Of note is the trick to make F0 look like it has an APB2 bus. It's the
only stm32 that doesn't have a documented APB2 bus, but still has
peripherals enabled via an "APB2" register, and they match how other
targets have an APB2. Simply make APB2 an alias of APB1, as it's only
used for clock speed detection.
This function was using apb1 for quite a few families instead of apb2.
This only mattered for L1 and F3, and for USART1/USART6, and only if
apb1 speed != apb2 speed.
Instead of using families explicitly, just check for the peripherals
themselves. On F0,F1,F2,F3,F4,F7,H7,L0,L1,L4, usart1/6 are _always_ in
the rcc_apb2 register and the other uarts are all on apb1.
(F0 doesn't actually _have_ apb2, but it's still called the apb2
register)
The ADVANCED_TIMERS define/check was added in 523943a as part of adding L1
support. The runtime checks against TIM1/TIM8 already existed. Since L1
doesn't have TIM1/TIM8, those names are undefined, resulting in a compilation
error until ifdeffed out.
Since I throw out all TIM1/TIM8 checks, there's no references to those names
left, thus no need to keep the ifdef either.
As for the registers themselves, l1/timer.h pulls in common/timer_common_all.h
which defines macros for the superset of all timers, so e.g. TIM_BDTR() is
still available regardless of whether or not the particular chip we're building
for has any timers with a BDTR register.
Very new gcc versions add a warning on switch cases that fall through.
While there's an option that accepts any comment as explaining it, it's
easier in our case to just use one of the "blessed" comments. We can't
use the [[]] attributes for standards code, and the gcc specific
attributes are worse than the comments. This has no functional change
whatsoever.
Clearly staging branch testers weren't testing.
Also, clearly the separation of RST_ bits and RCC_ bits is a complicated
annoyance.
Fixes: d9615a2eb728 update to modern include apis
Added the CAN1 compatibility aliases as has been done for adc and dac to
make code reuse easier. Only for the magic enums, the raw bit
definitions remain as per the ref mans
Originally suggested as https://github.com/libopencm3/libopencm3/pull/802
Use EP0 OUT flow control to NAK OUT packets when we're not yet expecting
any. This prevents the status OUT event from arriving while the control
state machine is still expecting the data IN completion event.
rcc_osc_bypass_enable and rcc_osc_bypass_disable have been copy/pasted
around for the last time! There's a compile bit to check for L0/L1, but
otherwise this is just code duplication for no gain.
For both v1 and v2, provide routines to help do arbitrary length
write/read transfers.
Tested with multiple byte writes and reads, for both 100khz and 400khz,
with repeated starts and stop/starts. However, only tested (presently)
with a single i2c target device, a Sensiron SHT21 sensor. Extended
testing against eeproms and alternative devices would be useful
Use REBASE(OTG_FIFO(endpoint)) to access the FIFO.
For the receive FIFO do not use the endpoint. There
is only one receive FIFO so giving the endpoint is
a no-op.
Get rid of REBASE_FIFO macro.
When reading a portion of the packet that is not divisible by 4 and
not equal to rxbcnt the count could get off, since 4 bytes are read
from the fifo in the last step but rxbcnt was only updated by the
number of bytes the caller requested.
We fix this by always subtracting four bytes (the number of bytes
read from the fifo) when we read a word from the fifo. Care has
to be taken in the last step so that rxbcnt doesn't underflow (it
is an unsigned number).
Note that reading in several small chunks not divisible by 4 doesn't
work as the extra bytes read in the last step are always discarded.
After a SETUP packet on a control endpoint the transmit FIFO
should usually be empty. If something bad happened, e.g. PC
and device got out of sync, we want to clear the fifo.
This should fix#668.
This is to interrupt for setup sequences on IN packet before
checking for OUT packet received. This fixes the problem that
usb_control_out stalls because we are not yet in STATUS_OUT phase.
Related to #668.
If you're interested in slightly underclocking or midrange speeds,
you're into custom environments. Drop all the "helpers" for these odd
speeds. This is not the max speed for any existing f0 part.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
The following four new functions enable clocking SoC from HSE crystal:
rcc_clock_setup_in_hse_8mhz_out_{8,16,32,48}mhz
These functions start HSE as external clock and feed its output to PLL
if higher frequency is needed.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
-> Dropped 8,16,32Mhz functions as superfluous.
- add brief descriptions for HSI clock functions
- use rcc_set_pll_source to set PLL source in RCC_CFGR
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
According to reference manuals both l0 and l4 have "v2" i2c peripheral.
This patch adds i2c support to l0 and l4 using previously unified "v2" i2c
headers and implementation.
No real hardware has been tested so far. Only compilation tests for both
libopencm3 and libopencm3-examples for all stm32 families.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
