The pwmout driver is very similar for each STM32 family.
The only family specific part is defined in pwmout_device.h file.
It mainly contains few specific information:
- The mapping of PWM/TIMERS to APB1 or APB2 so that we can get the clock
- The clock calculation uses the right APB clock, which was sometimes
not the case before and could have lead to errors in case dividers were
enabled on APB clock settings. This case is now covered.
- Inactivation of inverted support on feaw families
this first makes pinmap.c a common file
then rework it with several goals:
- avoid gpio / irq / pin management extra dependencies
- improve performances when switching between pin modes
This change is based on LL layer to access to registers level
instead of using HAL higher level API.
The family specific functions are implemented in pin_device.h
of each family. Mostly this is F1 family that is differnt
from other ones.
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.
Martin Kojtal
Laurent MEUNIER
Christopher Haster
Sam Grove
bcostm
Michel Jaouen
Adrien Chardon
jeromecoutant
Anna Bridge
adustm
Olaf Hagendorf
Laurent MEUNIER