Posted on by

Introduction

In our modern world of fast, cheap and powerful computing, there are countless different components that do nearly everything imaginable (and a bunch more that you would never have thought of). Combining these different components into a final product, be it a DIY weather station, homemade rover or satellite control system is at the essence of electronics design. But how do these components communicate?

This article will discuss one of the ways in which electronic components communicate called I2C (pronounced “eye-squared-cee”). I2C is very common, well supported and relatively simple to use and by understanding it we can develop an appreciation for electronic communication. [Brief note to clear up some confusing terminology: I2C is also called two-wire interface (due to it only using two wires) by some companies to avoid trademarking issues with the I2C name (which is actually used by Phillips). There is essentially no difference between the two protocols and are operated identically. SMBUS is another very similar protocol, but is more used in computing and is less common in electronics with the notable exception of being present in the Raspberry Pi.].

Arduino connected to two circuit boards
Figure 1 – BlueSat uses I2C to communicate between different components in a satellite

 

The Basics (Writing)

As communication protocols can get technical and overly confusing pretty quickly, let’s try an analogy to explain the basics and we’ll move more into the technical aspects in subsequent posts.

Imagine it’s half time at the football game and the players have gathered around the coach for a stirring half time speech. The coach has a couple of things he wants to say to the team, change some players and make some specific comments to some of the team.

Comparison of I2C Wiring Diagram to FNL Speech
Figure 2 – Less of a stretch than it may seem at first

Master and Slave

In this case the coach is called the Master and the players Slaves. The Master is in charge of starting communication and finishing it (you don’t want to be talking back to coach out of line, he’s not too understanding), while Slaves only respond to what the master instructs them to do. The slaves are allowed to do whatever they want otherwise (e.g. drink some water, have an orange slice, glare at the other team’s huddle, etc.), but they can’t speak. Typically there’s only one Master (there can be multiple but it gets a bit confusing and we’ll ignore it for now as most projects have only a single master. There can and often are many slaves though.

Importantly, coach needs to let everyone know who he’s talking to. He can’t just say “okay you come off and you go on in your place”, no one knows who he’s talking to. Thankfully, each player is easily identified by the number on the back of their shirt (the coach gave up learning everyone’s name after the first week) and coach can instead say “17 listen, come off and 3 go on in your place”.

This number is called the Address and each slave has one. They should each be unique as if they’re not there’s no way of knowing which slave the master is talking to and general confusion results. It’s sort of like having two friends named Andrew, you’re probably going to call one of them Andy (i.e. change their address) to stop getting confused.

Start and Stop Sequences

Coach has a couple of quirks, before he starts to talk he claps his hands and grunts “alright”. This makes everyone pay attention to what he’s going to say. When he’s finished talking he claps his hands again and says “OK”.

In I2C these are called Start and Stop Sequences respectively and are unique in that they are only performed at the beginning and end of a message. They let all the Slaves know when a new message is about to start (so they can see if it’s relevant to them) and also when it’s ended (so they can stop listening).

Acknowledgement

To make matters more confusing coach wants to know you’re paying attention (he hates repeating himself just because you weren’t listening). Each time he calls for you or finishes talking to you, he wants you to say “yes coach”. The only time he doesn’t want to let you respond is when he’s done talking to you (when he’s done he means it).

This is called an Acknowledgement and is important in I2C to determine if the slave has received the master messages. If no acknowledgements are received, the master could be speaking to no one at all and it wouldn’t know. Acknowledgements are required after each message except start and stop sequences.

Coach talking to player
Figure 3 – Coach is very particular about his communication protocols to avoid any misunderstandings

Example Exchange

So let’s put all this together in an example exchange:

 

Football Action

I2C Terminology

Purpose

Coach: “Alright” *claps* Master: Start Sequence Broadcasts to all slaves a message is about to be sent
C: “14 listen” M: Address of Slave to be Written To Identifies which Slave the Master wants to communicate to
Player 14: “Yes coach” Slave: Acknowledge Bit Requested Slave lets Master know they are listening to the message
C: “You’re all over the place, stay on your man” M: Sends Message Master sends his message to the slave
14: “Yes coach” S: Acknowledge Bit Slave lets master know his message was received
C: “OK” *claps* M: Stop Sequence Let’s slaves know this communication is over

Not too complicated at all. This basic format is used for nearly all I2C messages with the address and the message being the only things to change in most cases.

 

Talking Back (Reading)

But I hear you ask, what if I need to tell Coach something, what if the slave needs to send some information to the master. This is a very common situation (imagine a thermometer over I2C, if it can’t send its temperature to the master it’s pretty useless) and is called reading (as opposed to writing which we’ve previously been doing). It’s a little bit more complicated, but not much.

Let’s go with an example first this time and then breakdown the differences.

Football Action I2C Terminology

Purpose

Coach: “Alright” *claps* Master: Start Sequence Broadcasts to all slaves a message is about to be sent
C: “11 listen” M: Address of Slave to be Written Identifies which Slave the Master wants to communicate to
Player 11: “Yes coach” Slave: Acknowledge Bit Requested Slave lets Master know they are listening to the message
C: “Do you think you can break through their defence” M: Sends Message Master sends his message to the slave
11: “Yes coach” (NOTE: Remember this is not the player responding to the coach, but instead the acknowledging the message”) S: Acknowledge Bit Slave lets master know his message was received
C: “Alright” *claps* M: Repeated Start Sequence Broadcasts to all slaves a message is about to be sent
C: “11 I’m listening M: Address of Slave to be Read From Identifies which Slave the Master wants to hear from
11: “I think I can do it coach if Riggins can block me” S: Sends Message Slave sends his message to the master
C: “Thank you” M: Acknowledge Bit Master lets slave know his message was received
C: “OK” *claps* M: Stop Sequence Let’s slaves know this communication is over

Straight away we can see a lot of similarities, in fact the first half of the message is exactly the same as the writing example except instead of ending with a stop sequence, we ended with a start sequence. This is because the first step of reading is the Master telling the Slave what information it wants and this involves the Master writing to the Slave just as we did before.

Another start sequence (often called a repeated start sequence) is sent to keep communication going. This is where the analogy starts to break down, some devices like to have a stop and a new start in between writing and reading, while others are happy with just repeating the start. When using I2C devices, make sure you check their datasheet for how they like to communicate specifically.

The master then sends the address of the slave it wants to communicate with, but changes the last part of the statement to reflect that it wants to read from the slave, rather than write to it. The slave then sends the message and the master sends an Acknowledge bit (so that the slave know its message was received). Finally, the master (as the device in charge of communication) sends a stop bit to indicate the communication is over.

 

Conclusion

There we are, hopefully you have more of an idea how I2C operates. This is only the tip of the iceberg and I2C importantly also defines a whole range of different events and implementations such as what happens when these protocols aren’t followed properly.

Remember to check back on the BLUEsat blog for more technical posts on everything space and engineering in the future.