Fixes: https://github.com/libopencm3/libopencm3/issues/234
uses the new mechanisms introduced to address a similar problem on F7.
Tested on a medium density part (0x429) that returns the same ids as
before, tested on a high density part that now _doesnt_, but that's now
correct :)
In this commit, support for the different base addresses for different
F7 parts is added, but the mechanism is now in place for L1 and others.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
(whitespace fixed, commit msg reworded)
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.
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.
The leading - makes it rather inconsistent with the majority of other
projects around the world. Use the form everyone else uses.
To solve this, properly pass prefix to inner makes as was always
intended.
Fixes: https://github.com/libopencm3/libopencm3/issues/1058
Drops all the l1 copies of this code, and automatically gains all the
following apis that weren't even available before:
void adc_set_clk_prescale(uint32_t prescaler);
void adc_set_resolution(uint32_t adc, uint32_t resolution);
void adc_enable_overrun_interrupt(uint32_t adc);
void adc_disable_overrun_interrupt(uint32_t adc);
bool adc_get_overrun_flag(uint32_t adc);
void adc_clear_overrun_flag(uint32_t adc);
bool adc_awd(uint32_t adc);
void adc_eoc_after_each(uint32_t adc);
void adc_eoc_after_group(uint32_t adc);
void adc_set_dma_continue(uint32_t adc);
void adc_set_dma_terminate(uint32_t adc);
They were originally used to make sure that the doxygen was generated
correctly, but that style is no longer necessary.
There may be more peripherals that can be "cleaned" like this, but let's
do them one step at a time, as we work on that area.
Turns out, there's lots of common code for flash. Pull up prefetch
on/off to start with, as there's only a single bit name different.
Pull up the definitions of common API functions too, starting with
flash_set_ws. Even if the implementations are different, things that
meant to be the same, should be defined centrally.
Only applied to STM32 doc trees at present.
Instead of declaring a group for "STM32blah" in the doc-blah.h files,
and then trying to put all the common+specific peripheral code into
those groups, (which is what led to the stub doxygen holder empty .c
files) Just use a standard name like "Peripheral APIS" and place
everything into that.
Demonstrated by converting ADC and USART peripherals, which is
definitely not complete, but it shows how to make things less magical,
and less prone to copy/paste errors. Now, you can copy/paste and it
will do the right thing, because everyone uses the same group names.
This is also how to unify the mix of "STM32blah->Periphblah" and _also_
the dangling "periph_file" modules in doxygen, it merges them together
properly, as they're intended to be really.
On some targets these weren't even being referenced, on others they
were, in all cases they were empty and contributed no value.
They _actually_ served to declare groupings for doxygen, but we can do
that in a different manner, without having to have dummy files around.
split spi stuff in three part:
- v1 : basic spi peripheral
- v1_frf : v1 spi with frf mode additional bit in spi_cr2 / spi_sr
- v2 : spi with variable datasize, fifo and other fancy stuff.
v1 maps to f1 chips
v1_frf to f2, f4 and l0,l1
v2 to f0, f3 and l4
This breaks spi_master_init API for v2 devices : function prototype from
common spi header used to be abused, with DFF bit reused for CRCL bit.
New v2 spi_master_init does not handle anymore CRCL bits, as it does not
usually mess with other crc configuration.
Instead of every "simple" target having their own duplicate file with
all the section mappings, just provide a single, simple,
"cortex-m-generic.ld" that works with our startup code and any simple
rom/ram system. This also drops the pointless copying of files all over
the place. Using -L flags properly is sufficient, and the standard file
is now in the root of the library already.
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.
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>
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: eb18cc19cb392a69f8675c42776c644d1003ed89
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: cf5fb002f6016242fb23b81fcbe98ee022bb84e9
When changing the system clock, you must take care to not exceed the
legal ranges based on voltage and flash wait states.
Existing code made it possible to provide a valid clock structure, that
would run out of bounds temporarily. Some boards would crash with
various Usage faults / Bus errors due to this.
Start providing async routines for all blocking routines, to make it
easier to use libopencm3 in some RTOS environments. This is not in
anyway intended to be complete, this just covers a single blocking
routine, rcc_wait_for_osc_ready. Documentation added to the top level,
and provided for all stm32 families.
Original implementation only checked whether the user had _selected_ the
clock, not whether it had actually switched to the clock or not. For
almost all cases, this made this function either a no-op, if you _had_
selected the clock, or a blocking loop if you hadn't selected it ahead
of time.
Fixes github issue #687
As done by esden for the F4, remove typedefs and add prefixes to clock enums
This extends this to all stm32 families.
Let's not hide the fact that these variables are structs/enums.
We are filling up the namespace badly enough, we should be prefixing as
much as we can with the module names at least. As users we already run
often enough in namespace colisions we don't have to make it worse.
* CLOCK_3V3_xxx enums renamed to RCC_CLOCK_3V3_xxx
* clock enums (PLL, HSI, HSE ...) prefixed with RCC_
* scale enum of pwr module prefixed with PWR_
Renamed every instance of variable CFLAGS in target specific Makefiles
to TGT_CFLAGS to free up CFLAGS for user defined compiler flags.
Added information in README.md about existence and usage of CFLAGS
environment variable in build process.
