The previous implementation of copy_from_pm assumed the destination buffer
was aligned on a 16-bit boundary. On M0/M0+ cores (stm32F0*, stm32L0*)
this causes a hard fault.
This implementation is from Kuldeep Dhaka's tree; it does a 16-bit copy
only if the destination buffer is aligned, otherwise a bytewise copy.
Fixes GH issues #401, #461
The f107 ethernet peripheral is the same as in f4, and was pulled out
into lib/ethernet/mac_stm32fxx7.c in 52758bb8fd
This drops the duplicate code.
Fixes Github issue #694
The TSVREFE bit is defined to only be present on ADC1, so drop the
pointless adc argument. This has the added benefit of making the
API consistent with all other STM32 adc parts.
Use same names as adv-v2 peripheral uses. F1 is the only v1 peripheral
adc that has calibration modes at all.
Old:
adc_calibration(ADC1); // blocking call
New (blocking):
adc_calibrate(ADC1);
New (asynch):
adc_calibrate_async(ADC1);
// do stuff
adc_is_calibrating(ADC1); // false when calibration finished
Old routines are preserved but marked deprecated for now.
Extract the calibration code from the f0, and share it with the other
adc-v2 peripheral users (f0,l0,f3,l4)
Uses the same naming set of is/async naming conventions requested by the
RTOS guys instead of having blocking only calls.
Old code:
adc_calibrate_start(ADC);
adc_calibrate_wait_finish(ADC);
New code (blocking):
adc_calibrate(ADC);
New code (asynch):
adc_calibrate_async(ADC);
// do stuff
adc_is_calibrating(ADC); // will be false when it's finished.
Old code for f0 is still available, but marked deprecated.
Fixes: 57c2b00a69
There was an issue with the pllp value calculation where the masking was done
in the wrong place. The pllp value was always equivalent to 2 (the bits were
always set to 0b00) which could result in an undesired system clock frequency.
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.
These functions have existed since the initial commit, fallout from
copying an existing file and then trying to implement functions as
needed. F3 ADC doesn't have corresponding functions for some of these,
and this dead code should never have landed. Dropping it for clarity,
and also to stop confusing doxygen.
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.
Thoughts: should this be a "sam0" family rather than samd? (Much like Atmel's
own software package lumps all the cortex-m0+ devices in one family)
This was enough to get a basic blinky working at least.
This is not strictly required, as this part is supported by the
devices.data linker script generator tool. However, as we're still in
migration for that tool, and this is the first time we're getting proper
lm3s(qemu) support, keep it for now.
this is the part on the f072 discovery board. The devices.data file is
expected to be already lowercased, while the user provided DEVICE= variable is
then lowercased.
Added lpc43xx to devices.data
For now all lpc43 chips resolve to their cortex-m4 variant. How m0 should
be handled is to be determined later.
devices.data: add some vf6xx and lm4f support. fix typos
devices.data: added missing lpc13 family group
devices.data: fix lm4f with info from examples
devices.data: add some vf610 info
devices.data: add some entries for examples
As discussed with karlp on irc the devices.data file should not contain
gcc specific command line options.
For that reason the command line options for gcc are now generated from
the variables CPU and FPU by the rules in the mk directory.
This breaks the genlink tests.
genlink: simplified devices.data
devices.data already had the information about the family name.
By using the first field (by the pattern used to match it) as family name information that data doesn't
have to be provided explicitly. The same data is used to generate the
CPPFLAGS, such as -DSTM32F1
The architectures block of the devices.data file was redundant.
genlink-config.mk uses family and subfamily to figure out which libopencm3
variant actually exists.