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>
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]
It was never complete, even for F1 family code, and went on to be even
less complete for f0 and f3. The usefulness of a library function to
check for both the irq being enabled _and_ the status flag is highly
questionable, and caused known user confusion.
The existing, much simpler, and fully functional usart_get_flag() is
a good replacement in almost all sane use cases.
Fixes https://github.com/libopencm3/libopencm3/issues/734
Simplified blocking API, with an async routine if you really need it.
Follows as best as I can understand the reference manual, but testing
those conditions will be difficult.
Tested with a Lora radio application that used three GPIO lines to send
different interrupts from the radio module to the L052. Tested with a
Jeenode Zero Rev1
While the NOLOAD variant sometimes worked with some toolchains, the
version in the generator scripts could never work, as neither the
startup code, nor gdb know how to load those sections properly.
Originally added in: eb18cc19cb
The original scripts allowed you to place variables in eeprom space for
reading only. However, the last toolchain that generated working code
with this linker script was the gcc-arm-none-eabi-4_9-2014q4 release.
Subsequent releases treat the directives differently, and can lose track
of where variables are. One known symptom is constants getting bad
addresses, so for instance, "printf("asdfad")" will end up passing the
wrong address of the string constant into the eventual _write() call.
This commit removes the problematic directives until a more fully
correct system can be found that more properly follows the linker
script rules.
Attempts to helpfully unlock PECR when required in unlock_progmem and
unlock_option_bytes actually cause a bus error due to repeated unlocks,
as per ref manual and tedious experience. The better tested eeprom helper
routines unlock/lock in chunks, but that's not applicable for flash
writing.
Fixes: cf5fb002f6
Went awol merging something :(
(Yes, dwc_otg is theoretically shared with efm and co, but at present
it's still pretty much the stm32 version)
Fixes: 422d708384
Karl Palsson