Only one point of attention:
STM_MODE_ANALOG_ADC_CONTROL is a specific mode that is only supported on L4.
So STM_MODE_ANALOG_ADC_CONTROL was moved to index 13 (last entry)
of gpio_mode table so that all the other modes are common and only the last
one is specific.
Let's make the code more common for gpios.
The only difference between STM32 families is that BRR register may
not be available. In case BRR is not available, we use the 16 left bits
of BSRR instead. We could always use BSRR, but BRR saves one left-shift
operation, so let's use it when available.
By default we will consider using BRR, except for platforms that define
GPIO_IP_WITHOUT_BRR.
Since most of the code in i2c_api.c is now relying on STM32 HAL, there
is now a possibility to make a common usage of this code accross families.
The IP version definition is introduced per family, to allow a switch of
functionnalities, especially the frequency management which differs.
BTw, we fix the F0 frequency settings at the same time.
F1 is managed for now as an exception as the HAL API for sequential transmit
/receive is not yet available (coming soon)
Through some minor extensions it is now possible to use all available alternate functions of a specific gpio pin. These alternatives exist up to now only as commented lines in PeripheralPins.c.
An API change is not necessary for this new functionality, only several pin definitions.
The new definitions now looks like:
{PA_0, ADC_1, STM_PIN_DATA_EXT(STM_MODE_ANALOG, GPIO_NOPULL, 0, 0, 0)}, // ADC1_IN0
{PA_0_ALT0, ADC_2, STM_PIN_DATA_EXT(STM_MODE_ANALOG, GPIO_NOPULL, 0, 0, 0)}, // ADC2_IN0 // choice: PA_0 with ADC_1
{PA_0_ALT1, ADC_3, STM_PIN_DATA_EXT(STM_MODE_ANALOG, GPIO_NOPULL, 0, 0, 0)}, // ADC3_IN0 // choice: PA_0 with ADC_1
PA_0, PA_0_ALT0 or PA_0_ALT1 has to be used as pin names for the usage of the three possible ADC blocks (ADC1, ADC2, ADC3) connected to the pin (PA_0).
This applies the same fix as was done for F4 to solve issue #2638.
The fix applies ell to all other families excpet STM32F1.
Basically, to avoid over-writing the pull-up/-down settings, we read the
current state from HW.
the SPI_ASYNCH feature has been already activated for STM32F4.
This patchset makes it supported on all STM32 families by:
- moving spi_s structure at family level instead of board level
- using the F4 spi_api.c reference implementation and making it a common
stm_spi_api.c file which makes maintenance a lot easier.
- the only part that needs to be implemented for each family is the computation
of the clock frequency input to the spi peripheral which is not the same
accross families. So this is what remains in the spi_api.c of each family.
Because of the introduction of the common file, all the above modifications
needs to be done at once.
Supported toolchains initialization steps have been modified to make sure
that mbed_sdk_initi is called _after_ RAM initialization and _before_ C++
objects creation.
since this was done, there is no need to redundant SystemCoreClockUpdates
in the drivers
Laurent MEUNIER
Sam Grove
Michel Jaouen
Martin Kojtal
Adrien Chardon
jeromecoutant
Anna Bridge
adustm
bcostm
Olaf Hagendorf
Laurent MEUNIER
Christopher Haster