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.
Add MBED_APP_START and MBED_APP_SIZE to the Odin's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Add MBED_APP_START and MBED_APP_SIZE to the stm32f429's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
With the RTOS, the STACK_SIZE specified here is unrelated to the stack
size available for the main thread (that runs pre_main). Save memory by
reducing the stack size to a more reasonable amount.
On uVisor, HEAP_SIZE is both a minimum available and maximum available
heap size. The heap can't grow beyond the end of the heap into the
neighboring stack. On all uVisor-supported platforms, guarantee at least
0x6000 bytes of heap space. This increases the portability of uVisor
applications as the memory available for legacy heap allocations is
guaranteed. This helps to avoid out of memory errors on platforms that
were previously guaranteeing less memory.
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)
As reported during review, this was not understandable as it is.
the get_i2c_obj allows to get a pointer to i2c_s struct from the
handle pointer. This therefore makes a hard-coded assumption
about the struct itself
in case of 2 consecutives calls to HAL_I2C_Master_Sequential_Receive_IT
with the Xfer mode I2C_FIRST_AND_LAST_FRAME, the second trasnfer does
not start at all.
It seems this is because the previous state is maintained as I2C_STATE_MASTER_BUSY_RX
and therefore the START condition will not be generated
With this new implementation, as in slave implementaiton, we use the
interrupts instead of accessing to registers continuously.
This has 2 main advantages:
- this shall improve performances overall and allows for sleep
time in the future
- this also removes some direct registers access from this
layer of code and makes it more generic among families
The timeout values are based on for loops and therefore should depend
on the core frequency and the I2C interface frequency.
This patch introduces this computation and base the timeout on the time
it should take to send a byte over the I2C interface. When sending a
number of bytes, this value can also be used.
In the loops, the timeout should also be decreased before the while
condition so that its value is 0 in case the timeout elapsed and this
can be treated as an error.
With this new implementation, the slave use the Interrupt
to be notified of a request from master, instead of
accessing to registers continuously.
This has 2 main advantages:
- this shall improve performances overall and allows for sleep
time in the future
- this also removes some direct registers access from this
layer of code and makes it more generic among families
With this commit we define I2C irq handlers that can be used by the driver
in sync mode. This also provides a mecanism for enabling and/or disabling
these handlers
Those handlers will be superseded by MBED ones in case of async mode usage.
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.
- Remove waiting for 'BTF' flag in 'i2c_stop()':
When 'i2c_stop()' is called from 'i2c_read()' or 'i2c_write()' flag 'BTF'
has already been cleared (indirectly) by the calling functions and therefore
'i2c_stop()' would mistakenly always run into a timeout.
- Delay clock enabling until pins are configured:
Enabling the I2C bus clock before configuring its pins might in rare
cases lead to HW faults on the bus.
- Move initialization of 'handle->Instance' to function 'i2c_reset()':
As 'i2c_reset()' uses '__HAL_I2C_GET_FLAG(handle, I2C_FLAG_BUSY)' field
'handle->Instance' must have been initialized before doing so. Therefore,
this operation has been anticipated by moving it from function
'i2c_frequency()' to function 'i2c_reset()'.
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
Various toolchains supported in MBED don't follow the same initialization
steps. This can have impacts on platform behavior.
For STM32, it is needed to call the HAL_Init() _after_ the RAM has been
initialized (sdata from flash / zero initialized data) and _before_ the C++
objects are being created, especially if those objects require support
of tickers for instance.
In GCC, this is easily done because SystemInit is called after the ram
initialisation, so HAL_Init does not need to called from mbed_sdk_init.
this is covered by the changes in mbed_overrides.c files.
This series should solve issue reported here:
STM32 (At least F401) breaks if Tickers are activated in a global object #2115
This function reads the pull mode from HW and can then be used
to avoid over-writing the previously set pull-up / pull-down modes.
This is done following reported issue: #2638
Laurent MEUNIER
Russ Butler
Sam Grove
Jaeden Amero
Michel Jaouen
adustm
Martin Kojtal
bcostm
Adrien Chardon
jeromecoutant
andreas.larsson
Brian Daniels
javierpedrido
Andreas Larsson
Christopher Haster
Mike Fiore
Russ Butler
Laurent MEUNIER
Wolfgang Betz