Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
In the I2C Specification manual it's given "When the device does not have such an interface, it must constantly monitor the bus via software"
I am sorry but I don't understand what is meant by having the an On-chip interface on an micro controller or other peripheral.
And if it is not present then we have to poll the bus but according to me that is the only way , So what does an interface do what is an interface
Imagine a chip that senses some external condition that you don't know when it will occur. Let's say, for example, that the IIC chip does some external communication to some other device. That other device occasionally sends messages, but you don't know when.
With IIC being the only interface to this chip, the only way to know whether the external device sent a message is to poll the chip. That could use up a lot of IIC bus bandwidth, especially if you need to read the message with low latency.
In cases like this, the chip may provide a additional output that you can use if you want to. You can connect this to a separate digital input of the microcontroller. Now you don't have to send a IIC read message just to find out the IIC chip has nothing new for you. Instead you simply check the extra dedicated input.
You can take this a step further, which is to use interrupts. In the above case, the firmware is still regularly checking the dedicated input from the IIC chip. That's simpler and faster than doing a IIC read to see if the chip has something for you, but still requires active checking. The solution is to connect the signal from the IIC chip to a interrupt input of the micro. Now the foreground code doesn't have to do any checking at all. The interrupt routine runs only when the IIC chip has new data for you.
With something as relatively slow as IIC, it gets more complicated than that. You may not want to do the entire IIC transaction in the interrupt routine to avoid long latency in servicing other interrupts. You now also have to consider how to deal with foreground code using the IIC bus when the interrupt triggers. In the end, polling the dedicated line from the IIC chip in a separate task, then then does the IIC transfers when there is data might be the best firmware architecture. The polling loop includes a way to let other tasks run when there is no new data before going back and checking again.
Note: this answer was written under the presumption that the OP was asking about hardware I²C vs a software ("bit-banging") approach.
To greatly simplify the subject, an embedded I²C interface works in such a way that the application software (the part that you write) only has to offer data to send out or know in which register to look for received data. The actual clocking and timing of sent bits, and the clock reconstruction for received bits, is handled by the underlying hardware. A well-defined set of interrupt vectors is typically available to signal important bus events.
Such a setup makes it much easier to write applications that use an I²C bus, at the cost of having less control over the timing and the exact implementation details such as freedom to choose which pins are used for SDA and SCL.
Since the sending of bits is handled by hardware that is separated from the main application processor (only linked through the RAM typically), your code can dump some data to send and immediately move on to do other things which the hardware handles transmission. When you write your own software-based I²C interface, your code is responsible for timing each sent and received bit properly which makes it much harder to do other processing-intensive tasks at the same time.
