Bitbanging on I2C with a PIC micro
Note in 2013: I wrote this article in 2004 and some things have changed since then. In fact, Philips does not fabricate semiconductor devices anymore since activity has be spun off in a new company called NXP. Then, the 16F84 PIC was already obsolete then, now is nothing more than a curiosity. However, some concepts are still useful today and the article might be worth reading.
Note in 2016: Indeed, it seems that someone still reads this page! I thank Tom Lillevig for pointing out an error in the "i2cwaitack" routine.
What it can be done
All the hardware stuff
When things go wrong...
Correction suggested in January 2016
In modern electronics, digital circuits tend to increase their complexity. New integrated circuits become available and can do 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 easily 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, even with the same computing power and market strategy, a microcontroller having 24 input/output pins tends to cost more than one having only 13 of them.
The I2C 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 microcontrollers of the same family when the hardware USART is not available.
Most of the devices using the I2C are fabricated by Philips, but a lot of other producers adopt 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 I2C 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 I2C 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 I2C bus specification).
The I2C bus is composed, as we saw, 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 (not as the RS232 which is asynchronous and more complex).
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.
Fig. 1: the connection of several devices in a wired-or configuration (from the Philips I2C bus specification).
We will imagine being in the simple situation where there is just one transmitter and one receiver on the I2C 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 I2C bus there can be just one master device and any number of slaves.
In our simple example, we had 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:
; **************************************************************** ; I2C routines developed by Davide Bucci, version 1.0, August 2004 ; **************************************************************** ; Control lines of the I2C interface SCL equ 00 SDA equ 01 I2CPORT equ PORTB I2CTRIS equ TRISB ; Variables, substitute adresses of free RAM bytes TMP equ 0C ; Dummy variable COM equ 10 ; I2C Communication Register
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 bigger values decrease the supply current, where lower values increase the speed and the noise margin. In most cases, 10 kΩ is a good trade-off.
Things get more complicated with software, since we have to control the lines in order to communicate on the I2C 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:
i2cstart ; Send a start on the I2C bus BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output bcf I2CTRIS, SCL ; SCL as output BANKSEL I2CPORT bsf PORTB, SDA ; The start condition on the I2C bus bsf PORTB, SCL ; An high to low transition when SCL is high call shortdelay bcf PORTB, SDA call shortdelay bcf PORTB, SCL call shortdelay ; Leave SDA and SCL low return
Fig. 2: the start condition, inspired from Philips datasheets.
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:
shortdelay ; A short delay ;-) nop nop nop return
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.
i2cstop ; Send a stop on the I2C bus BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output BANKSEL I2CPORT bcf I2CPORT, SCL bcf I2CPORT, SDA ; The stop condition on the bus I2C call shortdelay bsf I2CPORT, SCL ; A low to high transition when SCL is high call shortdelay bsf I2CPORT, SDA call shortdelay ; SCL and SDA lines are left high return
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:
i2csend ; Send a byte over the I2C interface, movwf COM ; return 0x00 if ACK movlw 0x08 movwf TMP ; TMP is used as a counter BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output BANKSEL I2CPORT icloops bcf I2CPORT, SCL ; Clock low: change of SDA allowed rlf COM,f bcf I2CPORT, SDA btfsc STATUS, C ; Test the carry bit bsf I2CPORT, SDA call shortdelay bsf I2CPORT, SCL ; Clock high call shortdelay decfsz TMP,f goto icloops ; i2cwaitack follows directly i2cwaitack bsf I2CPORT, SDA BANKSEL I2CTRIS bsf I2CTRIS, SDA ; SDA as input BANKSEL I2CPORT bcf I2CPORT, SCL ; Clock low call shortdelay bsf I2CPORT, SCL ; Clock high call shortdelay movlw 0x00 ; Ox00 in w means ack btfsc I2CPORT, SDA ; SDA low means ack movlw 0xFF ; 0xFF in w means no ack BANKSEL I2CPORT ; Clock is left low bcf I2CPORT, SCL BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output BANKSEL I2CPORT call shortdelay return ; This version of i2cwaitack can be a little bit too fast for some i2c devices ; such as some EEPROM's. ; It may be convenient to introduce a timeout mechanism when waiting for the ; acknowledge. ; Refer to your device datasheet for more details.
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:
i2creceive clrf COM ; Receive a byte over the I2C interface movlw 0x08 movwf TMP ; TMP is used as a counter BANKSEL I2CTRIS bsf I2CTRIS, SDA ; SDA as input BANKSEL I2CPORT icloopr bcf I2CPORT, SCL ; Clock low: change of SDA allowed call shortdelay bsf I2CPORT, SCL ; Clock high call shortdelay bcf STATUS, C ; Clear the carry rlf COM,f btfsc I2CPORT, SDA ; Test the bit being received bsf COM,0 ; Stock the bit read in COM and rotate decfsz TMP, goto icloopr movf COM,w bcf I2CPORT, SCL ; Clock is left low call shortdelay return
Once a byte has been received from I2C, 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:
i2csendack BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output BANKSEL I2CPORT bcf I2CPORT, SCL ; Clock low: change of SDA allowed call shortdelay bcf I2CPORT, SDA ; SDA low means ack call shortdelay bsf I2CPORT, SCL ; Clock high call shortdelay bcf I2CPORT, SCL ; Clock is left low return i2cnoack BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output BANKSEL I2CPORT bcf I2CPORT, SCL ; Clock low: change of SDA allowed call shortdelay bsf I2CPORT, SDA ; SDA high means no ack call shortdelay bsf I2CPORT, SCL ; Clock high call shortdelay bcf I2CPORT, SCL return ; Clock is left low
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.
Fig. 3: the address byte compiled for a PCF8573 device (Philips datasheet).
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 I2C 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 I2C 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 I2C 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 I2C. 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.
I corrected the code above for the "i2cwaitack" routine including Tom's correction. The original code was as follows:
i2cwaitack bcf I2CPORT, SCL ; Clock low bsf I2CPORT, SDA BANKSEL I2CTRIS bsf I2CTRIS, SDA ; SDA as input BANKSEL I2CPORT call shortdelay bsf I2CPORT, SCL ; Clock high call shortdelay movlw 0x00 ; Ox00 in w means ack btfsc I2CPORT, SDA ; SDA low means ack movlw 0xFF ; 0xFF in w means no ack BANKSEL I2CTRIS bcf I2CTRIS, SDA ; SDA as output BANKSEL I2CPORT ; Clock is left low bcf I2CPORT, SCL call shortdelay return
August 2004 - First version of the page.
May 26, 2013 - Review and English translation.
January 10, 2016 - Added Tom Lillevig's correction in the code.
January 17, 2016 - Corrected the end of i2cwaitack and some typos in the Italian version of the page.
Copyright (C) 2004 Davide Bucci davbucci at tiscali dot it
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.