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);
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.
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.
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>
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.
The breaking changes here changes in header location, and changes in driver
name passed down to the usb stack.
Changes affect: stm32f102/f103, stm32l1, and some f3 parts
* instead of the confusingly generic "usb" use the name "st_usbfs" for the USB
Full speed peripheral ST provides in a variety of their stm32 products.
Include directives should change as:
#include <libopencm3/stm32/usb.h> => <libopencm3/stm32/st_usbfs.h>
* instead of the confusingly specific "f103" name for the driver, use
"st_usbfs_v1" [BREAKING_CHANGE]
Instead of:
usbd_init(&stm32f103_usb_driver, .....) ==>
usbd_init(&st_usbfs_v1_usb_driver, .....) ==>
The purpose of these changes is to reduce some confusion around naming, but
primarily to prepare for the "v2" peripheral available on stm32f0/l0 and some
f3 devices.
Work by Frantisek Burian, Kuldeep Singh Dhaka, Robin Kreis, fenugrec and zyp
on irc, and all those forgotten.
-ggdb3 make slightly bigger .elf files, but allows gdb to understand
macros, which libopenocm3 uses somewhat extensively. Make this the
default, and pull it up to the common base makefile, so it can be easily
substituted.
On linux, the output of CP rule was try to write to / which is - of course, forbidden for write.
This solution adds to each part of lib correct pointer to the root of lib where the libs should be written.
Bug found by Kuldeep Singh Dhaka.
This unifies stm32f1, l1, and f4 convenience functions for adc. The code
should be useable for f2 and f37x as well, but that needs hardware for testing,
and there was no existing implementation. This is the reason for the
"adc_common_v1.c" name, as trying to put all the different families into the
common file name has become too cumbersome.
All of the deprecated routines have been dropped, they've been marked
deprecated for a very long time now, and porting them seemed unnecessary.
This has been tested on f1, l1 and f4 discovery boards, and is based on some
existing l1/f1 unification code from
https://github.com/karlp/libopencm3/tree/rme_l1_master
The common code wasn't being included in L1 builds, even though the headers now
included the correct definitions.
This combines the two f0 and f3 spi files, which previously differed only in
the number of spi peripherals defined.
Files were renamed to the full "l1f124" style, not because I like it, but
because it's the convention we have, so it's best to apply it rigourously.
Tested on L1 and F100 boards, compile tested only for others, but the examples
repository all compiles too. (Though the lack of SPI examples for all
platforms was how this broke in the first place)
We currently default to "-mfloat-abi=hard -mfpu=fpv4-sp-d16" for M4F cores, and
and variations of "-mfloat-abi=soft" for the others. Keep the M4F default, and
move others to no FP flags for consistency, but allow overriding these flags
via the FP_FLAGS environment variable.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Because most changes are internal to a function in exti.c I am leaving
the macro checks in there, otherwise we would end up with a bunch of
code duplication if we used the dispatch system used otherwise
throughout the stm32 part of the library. I bet it could be split up
into more granular functions resulting in more generic code that we
could run through the dispatch system. But I am leaving that as an
excersize for later.
F2 and F4 have a common section to deal with the options register (TIM2 and TIM5 only)
L1 has been made common with timer_common_all as its options register has very different settings to F2/F4. Code is in the L1/timer.c L1/timer.h files
Note that F3 and F05 timers should fit into this scheme, with F3 having additional features.
Bundled with this is L1/pwr.h to change a documentation setting
Also all the Doxyfiles have added "ENABLE_PREPROCESSING = NO" to fix a problem introduced by commit 118.
Add the register definitions and some of the most basic helper functions
for the new style BCD RTC module found on the F2, F4, L1, F3 and F0.
This tries to keep as close to HACKING_COMMON_DOC as possible, while
maintaining sane names.
Code added for L1 to support the PWR Control block didn't properly
follow the HACKING_COMMON_DOC guidelines. The naming was wrong, and
some headers were missing. This commit has no functional changes, it
only addresses the style and structure problems.
Updated the documentation so that it appears in all families
Also added it to the L1 area, but is untested. An addition to the memorymap
allows commonality and a #ifdef added to the spi_common_all code to
exclude the case of SPI3 for L1 and F0 as SPI3 doesn't exist in those.
An rcc dispatch header was added to remove same code from the spi header.
This has only been tested functionally with basic timers, and basic operations.
Advanced timer support has been #ifdefed to compile, but this probably needs more testing.
Despite the L1 being a low power device, my initial focus is on making
it basically compatible with existing devices.
To that end, provide clock setup helper routines that configure it for maximum performance,
allowing some similar clock speeds to F1 devices to help with testing. This requires adding
the power chipset routines to set the voltage range.
Clock setup style is similar to the F4 code, which seems nicer than the overflow of different
routines used on the F1 code.
NOTE: Both the F4 existing pwr code, and this code don't actually include the f1 core power
code, even though it should be compatible
