The SPI br parameter has always been the 3 bit fpclk divider field, and
was never a target or explicit bit rate. Correct the comments, and drop
the duplicate commentary that wasn't included in the doxygen output
anyway.
Fixes: a7a3770d Add initial SPI code
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
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
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>
The f1, f2, f4, l1 chip families have a similar "v1" i2c peripheral on board.
More recent f0, f3, l0, l3 chip families share another "v2" version of i2c.
This patch unifies headers and implementation for two types of i2c peripherals:
- rename: i2c_common_all.[ch] to i2c_common_v1.[ch]
- remove i2c_common_f24.h: extra I2C blocks are defined in specific headers
- use f3 i2c code as a basis for common "v2" i2c implementation
- add f0 i2c support: use "v2" i2c implementation
Tests:
- tested on a custom f0 board
- compile-tested both libopencm3 and libopencm3-examples for all stm32
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Add three more RTC clock helper functions:
- rcc_set_rtc_clock_source
RTC on stm32/f0 can be clocked from the following three
sources: LSI, LSE (32.768Hz), HSE/32.
- rcc_enable_rtc_clock
- rcc_disable_rtc_clock
enable/disable clocking RTC module using selected clock source
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Add clock config for the 25MHz crystal found on the discovery board.
Verified to work on the STM32F7-Disco.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Modified namespaces and types->structs to avoid namespace pollution as
was fixed for other families in:
3a7cbec7: stm32l/stm32f: name space standardization [BREAKING]
