Sunday, December 2, 2012

I2C EEPROM Shield and Platforms Roundup



 
This I2C EEPROM shield was built to study I2C communications.  This two-wire bus involving bidirectional clock and data lines was invented by Philips (now NXP) to support a single master and multiple slaves.  A concise explanation and pseudo code is available on Wikipedia.   The shield is composed of a Microchip 24FC1025 which is a 1024 megabit (128 kilobyte) EEPROM, and supporting circuitry of jumpers, sockets, and resistors.  The jumpers provide options for the implementation to support a variety of platforms. 
 
Note: there is a strong advantage to using the I2C 24FC1025 over its SPI cousin the 25AA1024 that I highlighted in another EEPROM Shield article.  The I2C version has a simple API: write the address, then read/write bytes.  The SPI version has a complex API including erasing the whole chip, erasing a page, writing a page of memory, etc.  While the SPI device adheres to some JEDEC standards allowing for interoperability and has faster protocol speeds (20MHz) than the slower I2C device (100 kHZ, 400 kHZ, or 1MHz), using an I2C EEPROM is much faster to develop for time to market when engineering from scratch.
 
 
The form factor of the EEPROM shield supports the original Arduino such as the Duemilanove.  This also makes it compatible with a variety of other Arduino boards, and boards that are compatible with the Arduino shield form factor.  I have access to quite a few boards that are either directly compatible with this shield, or easily adapted.  Testing these boards with the EEPROM is summarized in the following table:
 

Board Type VCC Pullups SDA/SCL Solution Notes
Arduino Duemilanove arduino 5V internal A4/A5Wire.h  
Arduino Leonardo arduino 5V external D2/D3 Wire.h  
chipKIT Max32 arduino 3.3V external D20/D21 Wire.h 1
chipKIT Uno32 arduino 3.3V external A4/A5 Wire.h 2
Netduino Mini netmf 3.3V on board 9/10I2CDevice 3
Netduino Plus netmf 3.3V external A4/A5 I2CDevice  
Netduino Plus 2 netmf 3.3V external SDA/SCL I2CDevice 4
Panda II netmf 3.3V on board D2/D3I2CDevice  
FEZ Cerbuino Bee netmf 3.3V external D2/D3 SoftwareI2CBus 5, 6
Netduino Go Shield Base (Standalone) netmf 3.3V internal A4/A5 SoftwareI2C 7
 
Notes:
1. jumpered D20/D1 pins to D2/D3
2. JP6/JP8 jumpered to RG3/RG2
3. custom board used to adapt the Mini to Arduino form factor
4. jumpered SDA/SCL pins to D2/D3 or A4/A5
5. hardware I2C pins on Cerbuino not available to shields so using software method
6. WARNING: RESET/A1/A4 are not 5V tolerant on the Cerbuino.  I could have damaged the Cerbuino if I had used different SDA/SCL jumper settings on the EEPROM shield.
7. waiting on a fix from Secret Labs so can use I2CDevice
 
I was able to successfully access the EEPROM using all of these platforms.  The Arduino and chipKIT boards use Arduino and Arduino compatible IDEs.  The .NET Micro Framework (netmf) boards used either the included support for the I2C hardware lines, or in a couple cases had to use either included or added software drivers.  The upside of the software drivers is that the wiring is more flexible and can use CPU internal pullups, but the downside in this case is the software drivers are slower than hardware drivers.  It is recommended to use the hardware drivers if you can, but there are also software drivers available that work for all these platforms (Arduino and netmf).
 
The circuit was designed on the fly to quickly get up and running with I2C.  There are a few changes I would make to improve this circuit.
  1. Remove the 3.3V pullup options.  These were not needed.
  2. Add jumper for switching the entire circuit between 3.3V and 5V.  The EEPROM can run at lower voltages, and this would allow the shield to be compatible with non-5V tolerant platforms like the Arduino Due.
  3.  
Schematic

2 comments:

  1. Wonderful article. Highly informative. Could you elaborate one thing though? Why is it better to use hardware drivers for these instead of the software drivers?

    ReplyDelete
    Replies
    1. Reason(s) native hardware peripherals are preferred: speed and efficiency. So much more processing is required to bit bang, including code space requirements.

      Delete