I2C Protocol Subtleties – Part 1

By Donna Thompson 10 months ago

This short article is the initially in a series describing the a lot more ‘subtle’ facets of the I2C Protocol, at first developed by Philips.

Because you might be examining this collection, I am assuming you already know what the I2C bus is, and you might be on the lookout to keep away from some soreness when you will need to use it in a task. If so, you’ve got occur to the appropriate area. If not, I am going to be including some introductory I2C information and facts quickly at my site.

Just so we’re very clear, this collection will not incorporate coverage of the High-speed method, as this is substantially different from the structure and habits of the standard 2-wire shared-bus implementation, and is also not that normally used. You will find a great deal of outstanding reference material accessible on the Net that covers this method.

Here’s a rapid record of what will be covered in the rest of the sequence:

  • lacking Start
  • missing End
  • Repeated Start
  • lacking information bits
  • missing ACK/NAK
  • information immediately after NAK
  • back-to-back again problems
  • pullup resistors
  • bus repeaters
  • implementation making use of a comprehensive-hardware TWI or I2C peripheral
  • implementation applying a USI peripheral
  • implementation applying a USART peripheral
  • SMBus distinctions from I2C

Now, on to the superior things!

For this post, we will target on the 3 kinds of implementations you will come across in models right now: full hardware, hardware/software package mix, and whole software (or ‘bit-bang’ as it is in some cases known as).

Lots of microcontrollers these days, even some very low-close devices, involve a fully-components I2C peripheral. Atmel refers to theirs as TWI, Microchip phone calls theirs I2C other suppliers use equivalent naming. When employing a fully-hardware solution, it is really hard to deliver any sort of bus error except if you misunderstand how the peripheral is effective or what a suitable I2C bus sequence need to seem like. In standard, while, this tactic demands the minimum in-depth knowledge of the protocol itself.

The USI peripheral identified in some Atmel products is a minimum-components layout that depends on software program interaction to make it a entire implementation. This versatile peripheral can really be used for I2C, SPI and UART configurations, and is ideal for reduced-end equipment where by incorporating all three peripherals would be price-prohibitive. Although it demands more coding than a TWI or whole-components I2C peripheral, it is in some means a lot more versatile. This solution requres a a lot more in-depth knowledge of the protocol, as you are dependable for going from one particular state to the up coming, and it is feasible to go in the incorrect direction.

Finally, employing a 100% software package tactic requires a whole comprehending of the I2C protocol. Practically each and every microcontroller vendor supplies application notes and code illustrations for generating an I2C Master device utilizing a pure-computer software solution. Unlike a UART, I2C is a clocked (instead than timed) protocol, so interruptions in the execution of the protocol are tolerated effectively, letting interrupts to be serviced devoid of concern for losing info. The highest pace of the software-based mostly answer is finally decided by the CPU clock velocity, and generally a Master implementation can very easily arrive at the 400KHz amount.

A program-based mostly implementation of a Slave unit is considerably extra hard. Devoid of components aid, the software program must check both equally the SDA and the SCL traces concurrently in order to detect clock edges and know positively the condition of the SDA line prior to the increase or drop of SCL. Detection of a Start off or Cease situation will ordinarily require the use of interrupts, in any other case the software program would want to be 100% eaten with monitoring SCL and SDA. Program-primarily based Slave implementations have a tendency to be CPU-sure, requiring quite a few MIPS to achieve even 100KHz operation. As a result, genuine program-only Slave implementations may possibly not even exist for some microcontroller family members, and other folks may perhaps not be able of reaching whole 100KHz bus speed.

With this hardware and program basis acquiring been laid, we will dive further into the protocol itself in our next post. Thanks for studying!

(Copyright 2010 Robert G. Fries)

Leave a Reply