--- In [email protected], Thomas Treyer <[EMAIL PROTECTED]> wrote: > My first guess is, that both the DS1302 and normal > I2C devices can operate on the same I2C bus.
That is correct. Both devices can use the same pins. > On the other hand, during the communication of my user program with > the normal I2C devices (e.g. PCF8591) the RST line is not active, and > therefore the DS1302 should sleep peacefully during this time. I have no experience yet with the DS1302 (but I anyhow have to look into this myself), so I cannot tell a lot about the RST line itself. What I do know, is that I've rewritten a big part of the I2C driver and that driver is using the same I2C pins as the ones the DS1302 uses. The Etrax processor has two pins (PB0 and PB1) that can be used as "free" IO pins or as dedicated I2C pins. You have to know that the Etrax processor has "built-in" I2C functionality and if used as such, PB0 is providing the I2C data, while PB1 is providing the I2C clock. See the Etrax 100LX Designer's Reference, chapters 16.2 / 16.2.1 / 16.2.2 / 16.4 and 18.7.5 (especially bit 27 of that register, who defines if the I2C functionality of port PB will be enabled or disabled). To activate/deactivate the internal I2C functionality of the chip, you have the kernel configuration switch ETRAX_I2C_USES_PB_NOT_PB_I2C. When this switch is *not* defined, then the internal I2C functionality of the chip is used. When this switch *is set*, the pins are configured as general IO pins and you can use them for whatever you want, for example for your own I2C communication. That's exactly what I've done (was, in fact, already like this before) when I changed the I2C driver. The very same pins (PB0 and PB1) are "reused" for my SW I2C driver, so I didn't have to "sacrifice" two other IO pins for that functionality. > Can anybody confirm, that DS1302 and normal I2C devices can operate > on the same bus? Or is it preferable to use different pins? Hope I did... > Another aspect can be a race condition, where the kernel tries to > access the I2C bus the same time my user program communicates with > another device at the bus. Is this a real risk or is this avoided by > any method in the I2C driver? As said before, I didn't experiment myself yet with a combination of the two, being the DS1307 and all the other I2C devices. Maybe someone else has? > Does the kernel use the I2C driver for the DS1302 communication or > has the kernel an independent driver for the RTC? There is indeed a separate driver for the DS1302. You can find this one in the directory ./devboard-R2_01/os/linux/arch/cris/arch/drivers/ds1302.c. When looking into that driver, you will see that this one is completely stand-alone. Depending on the settings in the kernel (use "make kernelconfig" to check), certain pins of PB can be assigned to clock, data and rst of the DS1302 (check "drivers for built-in interfaces" in the kernel configuration menu). > What happens if my user space program opens /dev/i2c and keeps it > open indefinitely? Will this be a blocking point for the kernel to > access the RTC? Shouldn't be, but I have to figure it out for myself too. I might be doing this this weekend... > Please excuse all these silly questions, but these topics are > completely new for me. None of the above questions are silly, all are very much relevant. Best rgds, --Geert
