I'm trying to learn the basics of understanding how to wire up a simple circuit using the i2c. I'm wanting to build just a simple project involving an LED and a push button with my raspberry pi. From what I understand the "pi" already is i2c capable and i2c isn't a piece of hardware it's just a protocol from what I understand.

However, I thought initially all I had to do was wire up the push button and LED to the SDA and SCL pins on the pinouts of the "pi" and I would be good. But apparently I need an expansion chip or some similar device that provides instruction and registering for devices like the LED and PushButton.


Do I need a GPIO expansion chip to connect to my "pi" before I can start hooking up devices using the i2c functionality?

I already ordered a 579-MCP3008-I/P and a 579-MCP23017-E/SP in case I have to. I'm unsure on what the I/P or E/SP means but I was told the MCP3008 and the MCP23017 were good ones to get.


From my research here and through examining the circuit diagram below I thought the (SLAVE) devices were my LED and Push Button and then my (MASTER) device was my "pi". I going to assume that my pi is my MASTER device but my SLAVE device would be considered my expansion chip NOT the LED or PushButton.

Therefore, my LED and Push Button isn't a slave or a master device it's just an extension of the SLAVE DEVICE being the expansion chip. Do I have this right.


I drew out my conclusion of what i'm understanding. Forgive my drawing as I know it's not to scale. Can someone critique me on whether or not i'm understanding this setup and terminology when it comes to slave and master.

enter image description here

  • \$\begingroup\$ Just to make this clearer do you mainly just want to understand the I2C bus? If so then fair enough but if you really just want to interface a LED and button it will be much easier to just use the GPIO (general purpose I/O). \$\endgroup\$ – PeterJ Mar 2 '14 at 5:35
  • \$\begingroup\$ @PeterJ yes i just want to understand the I2C. I know this is a very simple project but I would like to start out simple first and get everything communicating before I get to extreme. \$\endgroup\$ – Shane Yost Mar 2 '14 at 5:44
  • \$\begingroup\$ Now this question would qualify to be migrated to the Raspberry PI stack \$\endgroup\$ – Passerby Mar 2 '14 at 18:14

When communicating, there must be an established set of rules for how to interact. Much like how when we speak to each other we are currently using English. In a similar fashion, chips have to have an established protocol for how they communicate in order to transfer data between them.

When speaking, the rules involve use having sounds that form words, and then rules which describe how those words go together to form sentences. When writing, we have symbols which come together to form words, and then the same rules about how words come together to make sentences.

In just the same way, your chip has two pieces of understanding. The first part is the protocol, and the second part is the interface. I2C has both a protocol and an interface at the same time. It describes the interface, which are the rules for how a chip should send electricity to another chip (much like the sounds for speaking or symbols for writing). I2C also describes a protocol, which are rules for how to interpret that information transmitted via the interface (like the syntax for a sentence).

Now, the types of devices which are meant to communicate using I2C are things like microcontrollers and computers. Things which have a high enough level of "understanding" or at least capability to think of things like "addresses" and bytes. When you buy a device which lists that it understands I2C (like this fancy led https://www.sparkfun.com/products/8579 ), then you know that it will understand those rules for both the interface and the protocol of I2C, and you can interact with it directly.

A "normal" LED (like this one: https://www.sparkfun.com/products/9590 ) doesn't understand anything like I2C. It is like a lightbulb, it just turns electricity it receives into light! Because of this, you can't "communicate" with it using I2C. In the same way, a button (like this: https://www.sparkfun.com/products/97 ) doesn't speak I2C either. It is like the switch you used. If you push the button, it physically connects two of the pins on the outside. If you want to use a button or LED like these, you should look into something called the "General Purpose Input/Output" pins, also called GPIO. These are pins on your Raspberry PI which can simply send "hi" and "low" voltage to a component (like your LED), or read if the electricity on a pin is "hi" or "low" itself.

Now, with all of that out of the way, let me answer some of your actual questions!

Q1) From what I understand the "pi" already is i2c capable and i2c isn't a piece of hardware it's just a protocol from what I understand.

A1) With an interface it is quite tedious and CPU intensive to sit in a loop and repeatedly set the pin "hi" and "low" and then wait a precise period of time in order to send your data. Since we would frequently like to send the data, and then have the CPU go and do something else, many microcontrollers and CPUS include sections of hardware which understand how to transform the data from a series of bits into the electrical signals necessary to communicate using certain protocols. Inside of your raspberry pi, there is a special set of registers (or at least memory locations) which, when written to, can cause some of your pins to behave in a manner consistent with the I2C specifications. When doing this in Linux through the kernel this can be quite difficult, which is why many designers will use "memmap" and /dev/mem in order to toggle those memory locations directly. This is quite involved, and you will likely need to find more substantial references than I can provide.

Q2) Do I need a GPIO expansion chip to connect to my "pi" before I can start hooking up devices using the i2c functionality?

A2) As I stated above, if you are not willing to use the GPIO pins already available on the raspberry pi itself, you will have to find a device which can transform the I2C information into a simpler form that your LED and push button "understand."

Q3) Who is the master and who is the slave on my I2C bus?

A3) So there is only one device in I2C which is allowed to initiate communication at a time. In this case, the only device which should be a master is the raspberry pi. If you do in fact have a push button which is I2C enabled, you will tell the raspberry pi to ask the push button slave "are you pushed or not?" and the button will reply, and then you will use that information.

I hope that helps!


I'm wanting to build just a simple project involving an LED and a push button with my raspberry pi.

You don't need I2C for that. Using I2C is inappropriate over-engineering for reading a switch and turning a LED on and off.

From your circuit, I'd say you should try this circuit first and understand

  • Ohm's Law
  • Why a LED doesn't have a fixed resistance
  • The role of a current-limiting resistor


simulate this circuit – Schematic created using CircuitLab

V1 would be two AA batteries in a holder.

The LED should be something like a 5mm green "indicator" LED (not a LED designed for illumination). It should be a cheap one because you are going to destroy it.

Such a LED typically has a forward-voltage of 2V and is designed to illuminate well at a current of 10 mA. However if you drive it at anything over 2V it's apparent resistance will rapidly drop (as it is a semiconductor junction device, not a normal resistive device) and the current will rapidly rise to the point where the working part of the LED gets very hot and burns out.

After that I suggest connecting a pushbutton to (say) GPIO23 and a LED (plus current-limiting resistor) to GPIO24. This example may be helpful.

Do I need a GPIO expansion chip to connect to my "pi" before I can start hooking up devices using the i2c functionality?

No. Some devices "speak" I2C themselves. For example, the TMP100 temperature sensor. You can connect these directly to a Raspberry pi. You don't need a GPIO expansion chip.

Who is the master and who is the slave on my I2C bus?

The Raspberry pi would be the master.


The RPI has both i2c capability (I am not sure if it is hardware or software based, but that's another story), and it has basic GPIO.

I2C is an addressed bus protocol, meant to communicate between a master and a slave (Or multiple masters and multiple slaves). You (The User) tell Bob (The Master) to tell Mike (the Slave) to do Task X, which Mike was hired for.

GPIO on the other hand, means "General Purpose Input Output". You tell Bob to do Task X, which can be turn on a light, and read a switch to know when to turn on/off said light.

The RPI can be used with direct GPIO pins to turn on or off an led (It is 3.3v and only capable of under 20mA of output directly). IIRC, the SDA and SCL pins on the RPI can be used in both I2C AND GPIO mode, but since there are plenty of GPIO only pins, use those instead of mixing them up.

So to answer your written question, YES, i2c requires a i2c GPIO port expander or led driver to turn on/off an LED and to answer your actual problem NO, you don't need I2C to turn on/off an LED, use the RPI GPIOs instead.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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