On Wed, Mar 11, 2009 at 06:19:18PM +0800, 伊泽 wrote: > > Not true. You need to provide a firmware for that device and this > > firmware selects the I2C slave address. Read the datasheet again. > > > Thanks Jean, daniel, > > Yeah, the capsensor has the function to re-program its own slave address ,we > did try that already. If programmed with other address, only coming out data > "0". > > The capsensor with 0x00 can also work with correct data,except the phone > hang problem. > > I really be confused, when i2c bus unit is blocked by some slave device, is > it necessary to control the scl/sda by GPIO mode operation? You need to have a master to the bus. Whether that is done by GPIO bit-banging or with a real hardware module in some kind of processor or peripheral device is up to you. You won't even see the difference from the Linux API as long as your bus master is supported. > > "The I2C address is programmable during configuration. It can be locked > > to prevent accidental change by setting a flag in a config-uration > > register." > > > > > > We met much phone hang problem with i2c,errors such as "waiting for bus > > > > free" or "exhausted retries" are all with this sensor. > > > > Same reason. Without a firmware, the chips does not have its I2C core > > set up and hence it's blocking SDA and/or SCL. > > I think we have the firmware, and the chips have its i2c-core set up > already,any other situation which the device block the SDA / SCL ? Every device connected to the bus can probably block it. If that happens, you need to find out why (this implies at least using a soldering iron and an oscilloscope). But as long as you're not sure whether you have 'the firmware' or not, I'm confident nobody on this list can help you with that. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
