Some I2C devices require specific zero length read/write sequences which
the HAL_I2C_IsDeviceReady() redirect interferes with. After Removing
these redirects, it was confirmed that zero length reads and writes
would both still work correctly for detecting presence/absence of an
I2C device on a bus.
If I2C slave support is included, then the I2C error handler would
always reset the I2C address, resulting in incorrectly changing the
I2C state to listen for a controller configured as I2C master. This
change conditionalizes the address setting to only occur if the
controller was in slave mode when the error occurred.
The default pin mode shall be set as part of the pinamp_pinout, and
as defined in tables of PeripheralPins.c, but this is currently
over-written by a call to pin_mode(pin, PullNone); from
mbed_pinmap_common.c, so we need a set the mode again here, including
OpenDrain config as needed for I2C.
this I2C IP is meant for automatic STOP, based on programmed number
of bytes to be sent or receivede, not a user triggered STOP.
So the state machiine needs to be reset in case we use this I2C mbed
unitary API (start / byte_write / byte_read / stop).
Following HAL update, this is needed to use the I2C API function
rather than previously used MACRO.
An assert would fail at compilation time otherwise.
STM32 supported targets have 2 possible versions of I2C.
This patch makes the start / stop / read and write byte work ok for IP V2.
This was not working before and does not seem to be widely used.
In case the user applicaiton makes a mixed usage of unitary function
(start, stop, byte write & read) with SYNC operation (write and read of
data buffers with start and stop management), we need to reset the
STM32 HAL state as it is by-passed by a direct call to STOP
The hz value is used to compute timeouts,
and timeout are used in reset function, so the parameter needs to be
initialized to its default value before being used.
So make the assert to cover all possible values
Also assert applies only for I2C_IP_VERSION_V2.
Also in case of I2C_IP_VERSION_V1, the HAL makes the proper
checks and can dynamically scale the frequency in case of
intermediate value.
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)
Bradley Scott
Laurent MEUNIER
Christopher Haster
Sam Grove
bcostm
Anna Bridge