Hi John, Pls. allow me to come back on some of the issues you gave an answer for.
--- In [email protected], "Geert Vancompernolle" <[EMAIL PROTECTED]> wrote: > > > 2. I see that there's a special CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C > > > definition. > > > Why is this? Is the HW wrt the I2C pins not reliable? Or is it just > > > in case those dedicated I2C pins are taken for other functionality? > > because the rtc does not work otherwise Is the RTC the only device which is not working when using the -what they call- canonical pins? You have any idea what the (technical) background is? Just to know if in the future maybe other I2C devices could suffer from the same "disease". > > > 6. In the i2c_read_data() function, there's first a write of the slave > > > address with the RW bit cleared (so, writing), then followed by a > > > repeated start condition and then the slave address is again sent, but > > > now with the RW bit set (so, reading). > > > Why is this necessary? Isn't it enough to just send the slave address > > > with the RW bit set, without the repeated start condition? > > > Why the restart condition? > > > There's anyhow no extra byte sent between the first time the slave > > > address is sent and the repeated start condition, so to me this is > > > useless. > > this is how i2c works.... check out the philips site for more detailed > info I checked the I2C bus specification (version 2.1) on the NXP website (former Philips) here: http://www.standardics.nxp.com/literature/books/i2c/pdf/i2c.bus.specification.pdf There's an example given on page 14 where info is read from a device (Fig. 12). In this example, the start condition is given, then the slave address with the read bit immediately set. Then an ack is given, followed by the first byte of data coming from the slave. So, here they don't issue Sta | Slave+Wr | Ack | RepSta | Slave+Rd | Ack | ReadByte | Ack |..., but immediately Sta | Slave+Rd | Ack | ReadByte | Ack | ... Is my statement then still incorrect? > > > 8. In the function i2c_ioctl(), I see lots of "fall through" case > > > statements. Is this on purpose? Can hardly think it's the intention, > > > but rather something that's forgotten. > > > It's starting from "case I2C_WRITEDATA" till the end of this switch > > > construction. > i cant remember why, but there was a reason.... has to do with 1-n cases > using the same functions with different parameters... summin like > that... but i remember that i did it for a reason > It would be nice if you could remember why you created such construction. The way it is implemented now, would return always an -EINVAL value for the cases starting from "case I2C_WRITEDATA:" onwards (there's no "break" any more up until the "default:" case, which returns the -EINVAL value). Hope I'm not too annoying, John! ;-) Best rgds, --Geert
