0
\$\begingroup\$

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

\$\endgroup\$

closed as unclear what you're asking by brhans, Enric Blanco, Voltage Spike, Dmitry Grigoryev, Dave Tweed Jun 8 '17 at 21:31

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ Have you heard of so-called "interrupts"? \$\endgroup\$ – PlasmaHH May 30 '17 at 11:54
  • \$\begingroup\$ Could you clarify your question by providing some more context? You refer to the I²C specs and quote a single sentence from them. It would help to cite the section before which gives context to the "such an interface" part. \$\endgroup\$ – Mels May 30 '17 at 12:27
  • \$\begingroup\$ we have to poll the bus but according to me that is the only way That is incorrect, like PlasmaHH says, the magic word is "interrupt". Polling is like looking on your phone every minute to see if there is a new message. Interrupt is your phone making a loud noise to interrupt you. \$\endgroup\$ – Bimpelrekkie May 30 '17 at 12:33
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ +1 I didn't even think of this perfectly valid way to interpret the question. I assumed the OP was talking about an actual H/W I²C interface vs bitbanging in software. \$\endgroup\$ – Mels May 30 '17 at 12:25
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ "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." , but even if we use I2C interface aren't we essentially giving the job to another processor which makes the resource usage yet still the same. \$\endgroup\$ – user2984602 Jun 1 '17 at 15:29
  • \$\begingroup\$ @user2984602 not from the perspective of your application code. Your code simply submits the task and can then immediately start doing literally anything else while the transmit/receive operation happens in the background. \$\endgroup\$ – Mels Jun 2 '17 at 13:39
  • \$\begingroup\$ And I would presume the hardware implementation is more efficient in terms of power usage in many uCs, as well. \$\endgroup\$ – Mels Jun 2 '17 at 14:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.