Bitbanging on I²C with a PIC micro

In modern electronics, digital circuits tend to increase their complexity. New integrated circuits become available and can accomplish very complicated tasks. On another hand, the availability of cheap microcontrollers easy to be used by hobbyists (such as PIC's, the ST6 and 7, the Motorola 68HC11 and so on) allows to build interesting circuits.

One of the factors which determine the cost of a microcontroller or a programmable logic array (Altera, Lattice, Maxim, ...) is the number of input/output pins. In other words, with the same computing power and market strategy, a microcontroller sporting 24 input/output pins tends to cost more than one having only 13 of them.

The I²C bus is a system proposed by Philips in the mid 1980's. It allows to control a very wide family of integrated devices using only two I/O lines and the ground. It is therefore a very cost-effective solution of a serial communication working at different speeds (100 kbit/s, 400 kbit/s and more recently 3.4 Mbit/s). Several devices can be connected at the same time and each of them is addressed via a specific code.

In this document, we describe some bitbanging routines for the PIC16F84. They might be useful for other 8-bit PIC microcontrollers, where the hardware USART is not available.

Most of the devices using the I²C are fabricated by Philips, but a lot of other producers adopts the standard, which has become widespread. Among the devices offered by Philips, we find clocks and calendars (PCF8574, PCF8584), static RAM (PCF8570), EEPROM (PCF8582, 24C01), analog to digital converters (PCF8591) and the list is far from exhaustive.

With a PCF8574 integrated circuit, it is for example possible to add 8 input output bi-directional pins to a microcontroller. If you consider that it is possible to use 8 devices, you can add 64 I/O lines controlled by just 2 pins of the micro. If you own a model railway, for example, you can control all the railroad switches, or the lights with just 2 lines. With the PCF8575, the I/O pins become 16 for each chip...

On the Philips website, you can find a wide area dedicated to the I²C standard you can visit to have a more detailed idea of what you can do.

In this article, we describe how to control in a very simple way an I²C bus, using a 16F84 PIC microcontroller. The communication speed is the slowest one allowed by the standard (100 kbit/s) and we will deal only a simple situation where the microcontroller is the only device handling the communication clock. I do not want to describe in detail all the standard (you have a lot of interesting documents such as the I²C bus specification).

The I²C bus is composed by two bi-directional lines and the ground return. The first line is called SCK and it is the synchronous communication clock. The second line, SDA is the line when the data are transferred between the devices. The protocol is therefore synchronous (serial communication via RS232 is instead asynchronous and more complex on certains points of view).

Since more than one controlled device may be present on the bus lines, the connections are made employing an open drain (wired or) strategy, as shown in Fig. 1. There is therefore a pull-up resistance for each line. Each device can thus connect the lines with the ground via a MOSFET (hence the name open drain), or be in a high impedance state allowing the pull-up resistor to impose a 1 logic level. In this way, there is no risk of current overload when conflicts appear on the bus.

We will imagine being in the simple situation where there is just one transmitter and one receiver on the I²C bus. In reality, two kinds of devices exists: the master which is in charge of controlling the clock on the SCK line, and the slave which follows the clock imposed by the master. Note that the master device can be a receiver and the slave can transmit on SDA, or vice versa at a different moment of the transmission. As a general rule, however, on a I²C bus there can be only one master device and any number of slaves.

In our simple example, we have only a simple device connected to the microcontroller. Most often, the microcontroller will be the master device. In other words, the SCK line is always handled by the microcontroller, whereas the SDA line is bi-directional. We start by giving a few definitions in order to understand more easily the code we are going to write:

In our example, the SCL and SDA lines are to be connected with bits 0 and 1 of the B port of the PIC16F84, with a pull-up resistor tied to the positive power supply rail. The choice of the values can be done by keeping in mind that larger values decrease the supply current, where smaller values increase the speed and the noise margin but increase power consumption. In most cases, 10 kΩ is a good trade-off value.

Things get more complicated with software, since we have to control the lines in order to communicate on the I²C bus via bitbanging. Each communication is a sequence of several bytes and each byte is sent starting from the most significative bits. Generally, the SDA line must be set up only when the SCK line is high, as visible in Fig. 2. There are two important exceptions to this rule. In fact, when the bus is not used, all two lines are kept high. The microcontroller starts the communication by putting a low state on SDA while SCK is kept high. Here is the code useful for starting a communication:

In the code, we used the shortdelay function who introduces a delay in order to leave to the receiver enough time to react. With a 4 MHz crystal, a reasonable implementation (even a bit too long) of this delay routine is as follows:

A symmetrical condition is the stop, which gives the end of transmission information. A transition of SDA from high to low when SCK is high.

At this point things become more delicate and we have to deal with the communication. The bits are sent one by one from the most significative one. Each time the sender has completed a byte, the receiver gives an acknowledgment to say if everything was OK or there has been a problem. The microcontroller relinquishes the SDA line and the acknowledgment is done by the receiver by keeping SDA at a low state. The code of the send routine is as follows:

Once the i2csend has completed, the w register will contain 0x00 if everything has gone OK, or 0xFF if the acknowledgment was missing and there has been an issue somewhere. The code to receive a bit is as follows:

Once a byte has been received from I²C, program execution is returned to the caller and register w contains the received byte. Since the microcontroller is the receiver, it should give the acknowledgment to the sender if everything was received correctly. Calling the following routines acknowledges or not the transmission:

We described briefly the base operations involved in the communication: sending a byte, waiting for an acknowledgment, receiving a byte and sending (or not) an acknowledgment. Now, we have to see how those operations are used in the communication protocol in order to let two devices communicate. It should be noted that in this case several details depend upon the devices chosen. The best thing you can do is to refer to the datasheet of the different products to see the exact procedures. Some ideas are almost universal, however.

The first operation from the master is sending a start, followed by a byte which is always the 7-bit address of the device to be selected. Figure 3 shows an example of the address byte of a PCF8573, a real time clock.

The 7 bits are composed by two groups of bytes. The first part is usually 2 to 4 bits long and is determined from the logic state of several configuration pins on the device. You can therefore adopt more than one identical integrated circuit with different configuration states. The second part is always the same for each device of the same type.

For example, in the Philips PCF8573 chip, the fixed second part is always 1101, followed by a bit which is always zero. The first part can be configured depending on the state of pins A0 and A1 on the chip. We can therefore have 4 independent PCF8573's on the same bus.

The last bit of the first byte is the read/write bit. If the microcontroller wants to write something on the bus, it should be high, otherwise if it is expecting something from the slave device it should be low (as a master receiver, it should continue handling SCL).

The start condition may be repeated in a single transmission several times, in most cases when logically different chunks of the transmission should be split. An example is passing from reading to writing on the device etc. In this case (the code is identical), the i2cstart routine might be called more than once.

Even after a careful reading of datasheets, it happens rarely that circuits work at the first time. In fact, you can observe the state of I²C bus lines with special testers which show on a screen what happens there. A simpler solution may be to use an oscilloscope to see what happens on SCK and SDA. You can use the microcontroller to trigger the oscilloscope via a third I/O pin, continuously repeating the message if you do not have a digital oscilloscope with memory.

If you do not own an oscilloscope, you can use two LED's with two transistors in order to see what happens. The I²C protocol is static, so you can slow down considerably the transmission speed by modifying the shortdelay routine. You can follow bit by bit what happens on the lines simply with your eyes.

In this article, I wanted to introduce briefly the widespread I²C communication standard. Probably your VCR and your TV have dozens of chips using this standard. I also presented some PIC assembly code for bitbanging communication on I²C. My routines are not universal and they are published as they are without any warranty, under GPL v. 2. I would be happy to have a feedback if you used them.

Tom Lillevig has kindly sent a note at the end of 2015 about my code. That shows that there is still an interest in those routines! Here is his remark:

Thank you for posting the information about I2C on your website and especially for the PIC assembly language software. I used your examples to help with my first I2C project. All of my PIC hobby projects are in assembly language. I did notice in the "i2cwaitack" routine that you change the SDA line back to an output before you set SCL low. I think that is an error because I believe that the slave will not release the SDA line until SCL goes low. The code works as you have written it but the PIC will be trying to drive SDA high for a few microseconds while the slave is still driving SDA low. I have changed the order of those instructions in my version. Thank you again for your efforts.

Tom Lillevig

I corrected the code above for the "i2cwaitack" routine including Tom's correction. The original code was as follows: