Arduino and the Two-Wire Interface (TWI/I2C) Including A Short Didactic Parenthetical On Making TWI Work On An Arduino Mini

I have been using the Arduino and Atmel microcontroller’s generally using the SPI (serial-peripheral interface), but decided to look at the two-wire (a.k.a. I2C) interface as well. I’m doing this partially because it would be good to know how it works, but also because it’s electrically more compact. It only uses two-wires, rather than the four required for SPI, so schematic designs and board layouts become a bit more manageable. The trade-off is a little bit more complicated protocols semantics, but nothing out of control. (I’m also looking at using a two-axis accelerometer that’s much less expensive than the three-axis one I’ve been using – $4 versus $15. For some experiments, two-axes may be perfectly fine, and I’m happy to save the $11.)

The first step was making sure the Arduino would handle the TWI – there’s pretty much no reason it shouldn’t, because the Atmega8 certainly handles it. So, the next step was finding out how best to handle TWI transactions.

To do this, I consulted the Atmega8 specification sheet, which has a pretty thorough explanation of the protocol and the implementation details on the Atmega8. (There are also a couple of useful application notes available here and here.) It’s so thorough that I had to print it out. I got a pretty good understanding of how it works but before I started coding, I noticed that there were some TWI libraries both in avrlibc and in the “Wire” library in Wiring.org happens to be packaged as a “sanctioned” external library for Arduino, so that was pretty much that.

Nicholas Zambetti, who wrote the Wire library, pretty much told me it should work with no problems, and he was pretty much right. No problems. His library abstracts the TWI innards really nicely, so I don’t have to muck with any Atmega registers or anything of that sort.

I hooked up my Arduino to a handy accelerometer for testing. (I’m still using the expensive LIS3LV02DQ.) Analog In 4 goes to SDA, and Analog In 5 goes to SCL. I have pull-up resistors on those lines, but Nicolas explains that his library enables the internal pull-ups on the Atmega, so I can probably pull those from my breadboard. Either way, it’s working just fine, even with the external pull-up resistors. (I’m using 4.7k resistors.)

(I also found in one weird situation that I had to explicitly clear the clock prescaler to get the UART functioning properly. This was while getting TWI working on an AT90USB1287 – TWI worked fine, but the UART was spitting out garbage. On chips where the clock prescaler can be set through the fuses, it’s important to verify that the prescaler isn’t hard wired to divide the clock. This’ll cause anything that is dependent on timing to potentially be off kilter. In my case, the UART was expecting an 8MHz clock to determine timing and baud rate, but the clock was being divided in hardware – not even in the firmware.)

Wire/TWI (I2C) on the Arduino Mini

Getting TWI working on the Arduino Mini (Although the Arduino and Arduino Mini share a name, they don’t share the same processor. The Arduino Mini uses an ATmega168, while the Arduino..normal.. uses an ATmega8. You’ll need to recompile/re-“verify” the Wire library files in order to get TWI to work on the ATmega168/Arduino Mini. There’s a thing or two you’ll have to do by hand to get this to work, and you’ll need to do it each time you move code that’s using the Wire library to a different processor. In other words, when you decide to port the code to the ATmega8, or you put an ATmega16 in your Arduino, or whatever â€” you’ll need to recompile these libraries. Here’s the drill:

Navigate in a file browser or command prompt to the root of your Arduino file hierarchy. Then go into:

lib/targets/libraries/Wire/delete Wire.o

lib/targets/libraries/Wire/utilitydelete twi.o

Once you’ve done this, make one modification to the header file twi.h in lib/targets/libraries/Wire/utility. Look around line 27 for a commented out line like this:

//#define ATMEGA8

Un-comment it (take out the “//” in the front.) This’ll ensure that the internal pull-up resistors on the ATmega8 are enabled when you’re developing for the normal Arduino. You’ll only need to make this change to twi.h once and for all. Future builds of Arduino should have this fixed.

For those who are curious — pull-up resistors are required on the TWI lines â€” SCL and SDA. You may use your own external pull-ups, but enabling the internal ones saves you the hassle. But, I don’t think you’ll do much harm if you have the internal one’s enabled and use external ones. But, generally you’ll want to avoid having both internal and external pull-ups.)

Anyway. These modifications described above should get TWI working on the Arduino Mini.)

Julian, thanks for your excellent example of the TWI on the Arduino. It helped me get up and running in no time. I have one question though, I tried to take your example a little further by writing my own I2C code (instead of using the wire library) and to do multiple reads from the accelerometer. However, I cannot get it to work. Did you ever get the multiple read functionality to work? I could swear I’m following the LIS3LV02DQ data sheet to the T.

Here is a working example based on the code above that does multiple reads at once for reading all three axis.. I’m using this sketch on an arduino nano.. Thanks for the original example

#include <wire.h>

// TWI (I2C) sketch to communicate with the LIS3LV02DQ accelerometer

// Using the Wire library (created by Nicholas Zambetti)
// http://wiring.org.co/reference/libraries/Wire/index.html
// On the Arduino board, Analog In 4 is SDA, Analog In 5 is SCL
// These correspond to pin 27 (PC4/ADC4/SDA) and pin 28 (PC5/ADC5/SCL) on the Atmega8
// The Wire class handles the TWI transactions, abstracting the nitty-gritty to make
// prototyping easy.

int val[3];
// transmit to device with address 0x1D
// according to the LIS3L* datasheet, the i2c address of is fixed
// at the factory at 0011101b (0x1D)

Wire.beginTransmission( 0x1D );
// send the sub address for the *first* register we want to read
// this is for the OUTX_L register

// set the MSB so we can do multiple reads, with the register address auto-incremented
Wire.send( OUTX_L | 0x80);
// stop transmitting
Wire.endTransmission();

// Now do a transfer reading six bytes from the LIS3L*
// This data will be the contents of the X Y and Z registers
Wire.requestFrom( 0x1D, 6 );

while ( Wire.available() < 6 ) {
// this isn’t really necessary
// a better thing to do would be to set up an onReceive handler,
// buffer the data and go off and do something else if the data isn’t ready
delay( 5 );
}

I’m guessing that you don’t need to make any adjustments in the source code. The LilyPad Arduino, which also runs at 8MHz can be specified under the menu item “Tools->Board” — that should compile your code with the correct F_CPU define of 8000000 without you mucking about under the hood.

After I’ve received my Skinny, 8MHz clock with 3.3volt logic, from the SFE, I had to solve the problem with the program uploading to the Skinny.
Since I already had success, using your didactic instructions, with Arduino Diecimila – I2C of LIS3LV02DQ – hooked up to my PC, I did not suspect the poor old FTDI driver. No success even with numerous changing of reset button timings!
Anyway,long story short, I found the FTDI driver should be updated, and intalled the new one last week. The uploding works great.
I still have to connect the Accelerometer to my Skinny at 3.3V.
I understand I’m quite a bit behind schedule.
My Skinny will be soon connected.

I’ve never tried this part, but I actually think I have it on a break out board somewhere..just never got to it. I used the AD7150 though, which is also an I2C device. Never really had any particular problems with it.

Where have you gotten with the AD7746? I can probably help you debug..

Since x_val is a 16 bit variable and it comes out in two pieces (x_val_h and x_val_l, which are each 8 bits) to assemble the full 16 bit variable x_val, we need to sort of cobble it together. First, taking x_val_h and putting it in x_val, so that x_val contains x_val_h in its lower 8 bits. Then, left shift x_val by 8 bits, so x_val_h is now effectively in the high 8 bits of x_val. Then, just adding x_val_l to x_val basically puts x_val_l in the lower 8 bits and the assembly of x_val is done: x_val_h is in the high 8 bits (from 15-8) and x_val_l is in the low 8 bits (from 0-7).

I am looking for a similar i2c connection from a teensy (arduino based at90usb162 or atmega32u2 mcu) to a uBlox GPS receiver (NEO 5Q). Does anyone has experience with that? Or know about a tutorial/example code?

About

This is the blog of Near Future Laboratory. We are a thinking, making, design, development and research practice based in California and Europe. Our goal is to understand how imaginations and hypothesis become materialized to swerve the present into new, more habitable near future worlds.