update on PR Added the repeated-start feature in I2C driver #590

[ABOSTM]

Summary

Hi @jmchiappa,
Thanks for your PR.
I had a look at the source code and it seems that using I2C_NO_OPTION_FRAME may cause issue:

1. Call to assert() function in STM32 HAL (if assert is activated) will fail because I2C_NO_OPTION_FRAME is not consider a valid option for external API.
2. Also, on F3 family for example, in HAL_I2C_Master_Seq_Receive_IT() the XferOptions can be written in xfermode which is then written in hardware register (I2C_CR2) through call to I2C_TransferConfig()
   {
   hi2c->XferSize = hi2c->XferCount;
   xfermode = hi2c->XferOptions;
   }
   . . .
   /* Send Slave Address and set NBYTES to read */
   I2C_TransferConfig(hi2c, DevAddress, hi2c->XferSize, xfermode, xferrequest);

But 0xFFFF0000 is not a valid value to write to register.

So I discussed with our I2C expert, and we finally reach a new proposal:
for both RX and TX:
if (sendStop == 0) {
_i2c.handle.XferOptions = I2C_OTHER_FRAME;
} else {
_i2c.handle.XferOptions = I2C_OTHER_AND_LAST_FRAME;
}

Unfortunately F0 and F2 do not yet have those defines but it should come in the future,
also F1/F3 will have it soon (next release).
So we propose to update your proposal with the solution from our expert, only when I2C_OTHER_FRAME define is available.
And keep former solution for other families (i.e. stop condition always present, and uncompatible for now with device like your accelerometer).
I made a Pull Request on top of yours, in your fork.

I tested this with I2C EEPROM 24LC256 and with Thermal sensor LM75 on NUCLEO_L476RG to be sure there is no regression. Test are passed.

Would it be possible for you to test with your MMA8451 accelerometer ... if you get it ?

[fpistm]

@jmchiappa
All our tests are corrects. And the slowness has been identified and fixed.
So, from our side it is OK to merge the repeated-start feature.
Could you merge this PR then I will be able to merge yours.
Thanks in advance.