I2C eeprom (Non-)Gadgeteer module

Here’s a proposition for a Gadgeteer module (yes, I know :slight_smile: )

Quick features :

  • type “I” module
  • 256K I2C eeprom
  • selectable I2C address via dip-switches
  • can be chained to other I2C Gadgeteer modules or standalone devices (LCD, other eeprom for example)
  • exposed 3.3V, 5V, GND, SDA & SCL pins via non populated PTH headers or populated screw-terminals
  • selectable I2C pull-up resistors via dip-switches
  • routing of the Gadgeteer socket’s pins 3 & 6

Details :

For my project, I needed some storage capabilities. I could have used SDCard, which is what I’ve done so far, but it has some drawback : it needs some more
libraries, which eats up memory on the Panda boards.
Since I have an I2C LCD in the project, I thought it would be wiser to also use the I2C line for storage, hence the choice of I2C eeprom. This will save some precious
memory space, I think. And while I was at it, I thought I could build a Gadgeteer module for it but with non-Gadgeteer compatibility also in mind.

About the eeprom chip, I’ve chosen a DIP package because I personnaly have this one and some MSOP-8. But those are really small (3 mm, 0.118"). And
I don’t have the package in Eagle for them. Also, DIP format is far easier to solder and generally easily available.

Unlike many (all ?) existing type “I” modules, this one has 2 Gadgeteer headers so that other I2C modules can be chained. To me, only one header defeats the purpose
of I2C and is not a good idea.
Since this is I2C, I’ve also exposed the SDA/SCL lines to the non-Gadgeteer world by using PTH header and/or screw-terminals. This also permits the use of this module on non-Gadgeteer boards.

In the same spirit, the power/ground lines are of course also exposed. Again, PTH header or screw-terminal can be used.

The dip-switches permits the inclusion of pull-up resistors on the I2C lines. This can be very useful if using Gadgeteer software I2C for which pull-up are mandatory on
modules, which is of course almost never the case.

Also, since this is a type “I” module, it should also provide connectivity for pins 3 & 6. This module does not use them, so they will be routed between the two Gadgeteer
connectors. Here again, two dip-switches are used for this. In the “OFF” position, pins are not routed and are not available at the “out” connector. Obviously, in the "ON"
position, pins 3&6 will be available.
This can be very handy if you use a type “I” module that is using pin 3 (for example) and another one that is using pin 6 (in addition to I2C pins) : you put this eeprom module
between the 2 and put the switch “pin 3” to OFF and “pin 6” to ON.

What do you think ?

ps: I have one question for specialists : do I need ground planes, here ?

This is a good module for your needs. It is also good for people that understand hardware and want to hack into it. I think you should finish if and offer it for sale.

We are finishing a flash module that has 4MByte soon, by the way.

Why do you say that ? This module does not require any hardware skills for its use. With all dip switches to their default values OFF, it will work straight forward.

Now, if someone wants (for example) to change the I2C base address,then it will have to change some switches. I don’t see anything particularly hard here. Much like setting the dip-switches on the Spider, for example.

I will certainly finish it. Even if it’s for my own and unique use.

This will be far better than this 256K eeprom, indeed.

On a similar note… The IO60P16 module includes a 27K EEPROM. It hasn’t been exposed in the current version of the driver but it could be accessed directly using the register calls. If GHI doesn’t add it sooner, I’ll get back around and add it to the driver once I free up some time.

Theres also this one: http://www.soldermonkey.net/shop/index.php?route=product/product&path=59&product_id=67
1MB on an S socket…