According to RM0351 and RM0394 flash needs to be programmed by double words.
Also fix flash_program() which was wrong anyways.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
48Mhz has no purpose other than to be a naiive method of haivng working
USB. 120MHz never had any purpose, other than to match the f2 code it
was copied from. Drop them both. Remaining configs are all max speeds
for various F4 parts. Lower speeds are all custom
Fixes: 96d094af13 mk/genlink-config: provide LIBNAME in devices autogeneration
The initial fix had fixed the examples repo, but broke the tests and the
template repo. Restore the suffix properly.
This makes the generic rules workk happily regardless of whether the
linkerscript generation is being used or not.
Notably, in the examples repo, use of the linker script autogeneration
was retriggering library builds as LIBNAME was unset and therefore the
libraries lib<blank>.a couldn't be found.
Some families had partially moved to peripheral api, and others were
only documenting common code, but not specific code. Delete dummy .c
files, and check that all specific apis are also being documented, not
just common apis.
Functions that are already documented in the top level common api.h file
won't add any more documentation from later .c files. Keep docs for
part specifics, in the .h files where they're accessible to IDEs and
also the documentation generation, and drop all (including the redundant
ones) from the .c file.
the group defaults to the implicit container based on location, so drop
all the explicit @ingroups, less to maintain. Properly use /**@}*/ to
close all groups too, even though it mostly seems to have worked anyway.
Properly close all groups opened for files.
Make the names match the reference manuals properly, and add missing
names. Still a long way to go to unify across all families, but this is
at least closer.
here, it's a bit of a mess.. G0 flash controller does not really
match exsting feature split. IE it has instruction cache only ..
so, no flash_idcache.c as it. flash_common_f could be used, but
flash_unlock would not take care of option byte ?
prefetch, icache and lock is ok. I had no look at flash programming
or erase yet..
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);
Sampling time and sequence length, along with the vbat channel are
specific to the f4/f7, and can't be shared with the l1 and friends.
Pull them out to their own common file.
While this appears to be a backward change, this moves the _register_
definitions (their addresses) and the actually specific to f4/f7
numbering back into the explicit headers. Potentially this could be
pulled out again, but it's not much code.
This then allows the stm32l1 to use all the rest of this code, with the
differences really being just the addresses of the registers.
Never seen any reason for these noisy verbose defines. They're not
helpful, and we've never needed them for doing sequence setting code
anyway. Just drop them.
