Hi Michael, On Wed, Dec 05, 2007 at 09:05:01AM +0100, Michael Schnell wrote: > > >First, I was wondering why there are no error messages when the > >slave does not send an acknowledge. > The acknowledgment does not need to be sent with the next clock. AFAIK, > there is no predefined timeout for the acknowledgment. (Moreover the > slave is allowed to pin the clock low to slow down the transfer at any > time for as long as it wants to.) > > Thus to recover from not seeing an acknowledgment you need a project > specific timeout definition. This can't be handled by the driver on it's > own.
I can not agree here. The acknowledgement has to be sent with the next clock, but you are right there is no fixed definition when this clock does take place in case the slave uses clock stretching. However, the driver definitely has to wait a pre-defined time for this next clock cycle or at least terminate with a proper error condition, which is not the case at the moment. For handling some special slaves it might be necessary to make this timeout configurable, but this is not the case here. (We are using all the devices with a bit-banging driver on a different controller, so I know quite exactly what the slaves are doing.) There currently are two different problems: - the driver in its current state (without my modification) does not return an error if there is no acknowledge at all. In this case there is no timeout needed because there is no client that could do clock stretching. IMHO, this is a straight bug and should be fixed if the hardware in all supported processors supports this. I was hoping that maybe somebody here has an overview about the I2C controller evolution in the coldfire family. - In my setup, the driver/hardware at some point gets stuck with the already mentioned "I2C bus always busy" message and I did not yet find out what causes this. And how to reset the I2C controller without re-starting the processor. Regards, Wolfgang _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
