I2C Protocol Subtleties - Part 1

This short article is the initially in a sequence describing the more ‘subtle’ aspects of the I2C Protocol, at first made by Philips.

Considering that you are studying this sequence, I’m assuming you by now know what the I2C bus is, and you might be on the lookout to prevent some discomfort when you need to have to use it in a project. If so, you’ve come to the suitable put. If not, I am going to be incorporating some introductory I2C information and facts shortly at my site.

Just so we are obvious, this sequence will not involve protection of the Higher-velocity mode, as this is significantly various from the structure and conduct of the usual 2-wire shared-bus implementation, and is also not that normally applied. There’s a good deal of great reference product obtainable on the Web that handles this method.

Here is a swift record of what will be included in the rest of the series:

missing Begin
lacking Prevent
Recurring Start
missing knowledge bits
lacking ACK/NAK
information immediately after NAK
again-to-again glitches
pullup resistors
bus repeaters
implementation making use of a entire-hardware TWI or I2C peripheral
implementation utilizing a USI peripheral
implementation making use of a USART peripheral
SMBus variations from I2C

Now, on to the fantastic things!

For this post, we will concentrate on the 3 types of implementations you will come across in layouts nowadays: full hardware, hardware/software combine, and total computer software (or ‘bit-bang’ as it is at times called).

Lots of microcontrollers nowadays, even some low-end gadgets, consist of a completely-hardware I2C peripheral. Atmel refers to theirs as TWI, Microchip calls theirs I2C other vendors use comparable naming. When utilizing a completely-hardware tactic, it is truly complicated to crank out any form of bus error until you misunderstand how the peripheral is effective or what a proper I2C bus sequence ought to appear like. In basic, however, this method demands the least in-depth knowing of the protocol by itself.

The USI peripheral located in some Atmel gadgets is a minimum-hardware design that depends on software program interaction to make it a finish implementation. This functional peripheral can essentially be utilised for I2C, SPI and UART configurations, and is proper for lower-end gadgets where by including all three peripherals would be value-prohibitive. Whilst it requires a lot more coding than a TWI or comprehensive-hardware I2C peripheral, it is in some ways more adaptable. This solution requres a far more in-depth understanding of the protocol, as you are liable for going from one condition to the next, and it is feasible to go in the mistaken course.

Finally, implementing a 100% program technique requires a full knowing of the I2C protocol. Practically just about every microcontroller seller gives software notes and code examples for generating an I2C Master gadget applying a pure-program resolution. In contrast to a UART, I2C is a clocked (rather than timed) protocol, so interruptions in the execution of the protocol are tolerated effectively, enabling interrupts to be serviced with no issue for losing details. The utmost pace of the software package-dependent alternative is finally decided by the CPU clock pace, and ordinarily a Master implementation can simply reach the 400KHz amount.

A software package-based implementation of a Slave machine is a great deal a lot more tough. With no components guidance, the software have to observe each the SDA and the SCL traces at the same time in order to detect clock edges and know positively the condition of the SDA line prior to the rise or drop of SCL. Detection of a Commence or Halt condition will commonly have to have the use of interrupts, otherwise the software package would need to be 100% eaten with checking SCL and SDA. Application-centered Slave implementations have a tendency to be CPU-certain, requiring several MIPS to reach even 100KHz operation. Thus, real software-only Slave implementations may perhaps not even exist for some microcontroller people, and other individuals might not be capable of reaching full 100KHz bus velocity.

With this hardware and application foundation getting been laid, we will dive further into the protocol itself in our next short article. Many thanks for looking through!