I'm sure I did find a need to stop/start I2C, since its in some of my test code which checks for recovery from an access to an address where nothing responded; maybe it was only a problem with the I2Cv1 driver, which I was certainly using on the F4 until the F7 came out.
I think also you need to send something which the addressed device is happy with, otherwise it may not respond. (Part of the problem is that the I2C drivers were never intended to work like this; if things don't go completely right they return an error. What's needed here is to know whether the address was acknowledged properly, even if subsequent data is rejected).
Tabulous wrote:Kind of defeats the object having to send something that the device will accept.
For a totally generic solution, I agree - you'd need to use a different I2C driver which reports whether the address was acknowledged.
For your requirement, an application-specific solution should work quite well. A lot of I2C peripherals can only be assigned an address within a small range, so have a list of addresses and test strings (or a list in the driver for each supported device).
Tabulous, did you find a solution for scanning the I2C bus? I'm trying something similar, and I also think an I2C scanner would be a nice ChibiOS I2C example project.