I2c Eeprom module


This module is one of the possible solutions to the request made here : http://www.tinyclr.com/forum/topic?id=7893

I’ve finally received all the needed components for this module, which is also acting as a small i2c hub, both for Gadgeteer modules and non-Gadgeteer devices.

All is working as expected, as you can see on the attached picture. I’ve connected 2 LCDs and a compass. This gives 4 devices with the onboard eeprom chip.

Usage is very simple :

using System;
using Becafuel;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.Threading;

namespace cerbuino_netmf
    public class Program
        public static BafModule Baf;

        public static void Main()
            // Address of the onboard eeprom
            Baf = new BafModule(0x50);

            // 2x16 i2c LCD
            Baf.AddDevice("Lcd1", new I2CDevice.Configuration((UInt16)(0xC6 >> 1), 91));
            // Send command to clear the screen and to set backlight ON
            Baf.Write("Lcd1", new byte[2] { 0, (byte)12 });
            Baf.Write("Lcd1", new byte[2] { 0, (byte)19 });
            // Write a string at (2,2) coordinates
            Baf.Write("Lcd1", new byte[4] { 0, 3, 2, 2 });
            Baf.Write("Lcd1", System.Text.Encoding.UTF8.GetBytes((byte)0 + "Essai LCD 1 2"));

            // 4x20 i2c LCD
            Baf.AddDevice("Lcd2", new I2CDevice.Configuration((UInt16)(0xC8 >> 1), 91));
            // Other way of accessing device, by its number. Onboard eeprom is 0.
            Baf.Write(2, new byte[2] { 0, (byte)12 });
            Baf.Write(2, new byte[2] { 0, (byte)19 });
            Baf.Write(2, new byte[4] { 0, 3, 2, 2 });
            Baf.Write(2, System.Text.Encoding.UTF8.GetBytes((byte)0 + "Essai LCD 2 2"));

            var StrTmp = Baf.EEReadString(10, 4);  // Read a 4 chars length string at address 10
            Debug.Print(StrTmp);  // Printing "Toto", as it was previously written at this address

            Baf.EEWrite(1, (byte)12);  // Write a byte (value 12) at address 1
            byte b1 = Baf.EEReadByte(1);  // read it to be sure ;-)
            Debug.Print("Byte = " + b1.ToString());   // Printing "12"

            // Compass Gadgeteer module from Seeed Studio
            // i2c commands and config taken from Seeed's source in the Gadgeteer tree on codeplex
            Baf.AddDevice("COMPASS", new I2CDevice.Configuration((UInt16)(0x1E), 100));
            while (true)
                // Do a single reading
                Baf.Write("COMPASS", new byte[] { (byte)Register.MR, (byte)Mode.SingleMode });
                // Read values
                Baf.Write("COMPASS", new byte[] { (byte)Register.DXRA });
                byte[] Res = Baf.Read("COMPASS", 6);
                // Only rawX for the example
                int rawX = (Res[0] << 8) | Res[1];
                rawX = (((rawX >> 15) == 1) ? -32767 : 0) + (rawX & 0x7FFF);
                Debug.Print("X = " + rawX.ToString());


Excerpt for the compass results :

X = 215
X = 209
X = 205
X = 196
X = 185
X = 179
X = 180
X = 170
X = 164
X = 161
X = 157
X = 153
X = 149
X = 144
X = 135
X = 123
X = 112
X = 97
X = 91
X = 88
X = 77
X = 69
X = 71
X = 61
X = 49
X = 37
X = 24
X = 11
X = 4
X = 0
X = -2
X = -2
X = -8
X = -16
X = -21
X = -24
X = -28
X = -50

Of course it’s also working with non-Gadgeteer boards. It then permits the use of Gadgeteer modules with PandaII, for example.
Next example will add a second Eeprom module with a different address (set by the DIP switches), in addition to the 3 existing devices. It will be done tomorrow as wife is sleeping and my soldering station is quite noisy :frowning:

Now, about soldering the Gadgeteer header, it’s a real pain, as Ransomhall told me :wink: So I’m hereby asking Godefroi his permission to use his design with longer pads for those headers…

Next step will be the “shield” version, shown here : http://www.tinyclr.com/forum/topic?id=8905&page=2#msg88792
It’s still a work in progress, though, but I’m confident about a (relatively) short delay for this one.


@ Bec a Fuel - nice work :slight_smile:

Nice job! What would be especially useful for Gadgeteer, though, would be one that just had several sockets. The current version seems very specific to your application.

Why ? In its “basic” form, it’s only an eeprom module. But it can be chained with other i2c devices, Gadgeteer or not. The PTH headers and screw-terminals are here to permit the use of non-Gadgeteer devices, whatever they are.
Really, I don’t understand why you think it’s specific to an application ?!

It seems you didn’t see the second link in my post :wink:
I’ve put the picture here again (please note that it’s still work in progress and that some errors are present on this revision).

This “module” (or “shield”) will have the following features :
Gadgeteer compatible format
Arduino shield compatible format and cabling for the i2c lines. (the other IOs from the Arduino pins are not used)
onboard eeprom with selectable address
i2c lines available for external devices with many connectors : screw-terminals, PTH headers, Gadgeteer headers, Groove headers
IO60P16 specific connector because of its (weird) i2c cabling. This connector permits the use of the IO60P16 with hardware i2c from standard pins. Additionnal pull-up resistors have been added to deal with this.
Software i2c connector (#2 on the picture) with configurable pull-ups. For example, you can use pins 3 & 7 if you want and put on the DIP switches accordingly.
header #2 is still compatible with hardware i2c on the dedicated Gadgeteer pins (8 & 9)[/ul]

If there’s still enough room, I may add another Gadgeteer connector, though.

Of course, this board can’t be a Gadgeteer module, but will instead be a plain NETMF board.

[em]Edit: of course, all the 4 Gadgeteer headers are used to share the hardware i2c lines. This wasn’t clear in my description, I think.[/em]

As you pointed out, I didn’t really look at the other link. I was going off of the photo that only had one socket and a couple screw down terminals. I understand it better now. Too bad there’s not a way to use the Gadgeteer drivers with it. Hopefully, this concept is be discussed in the halls of the Gadgeteer kings.

I would say : “Too bad that Gadgeteer did not anticipate this !” :wink:
As many users have already said, i2c is a bus protocol but the Gadgeteer implementation has ignored it. This is not the fault of other people, to me. This could also explain why there’s only one connector on i2c module : since it’s not expandable in an easy way, why bother with a second connector ?
But still, it fails on the i2c spirit, to me.

However, I think that the method I’ve used to access different devices connected to this eeprom module can be used in Gadgeteer, too. This is only an idea at the moment, but if I create a Gadgeteer module driver, then the fact that subsequent devices can be logically added to it should work in the Gadgeteer world. No need to try to share the line since the driver will handle it internally.

Of course, you still won’t be able to use existing drivers :frowning:

Certainly you can use the footprint. It is available here: http://3ln.org/media/35280ecc-52f5-4587-9b30-067af5fe144e/Blog/mark_gadgeteer_socket_lbr

There are pictures of the footprints side-by-side for comparison here: http://3ln.org/blog/2012/09/30/Gadgeteer-socket-library

Thank you very much, Godefroi. Unfortunately, your lib is for Eagle 6 and I have v5, which I need to keep :frowning: Is it possible with v6 to save a v5 version ?

@ ianlee74 : would this new board revision satisfy you in terms of Gadgeteer sockets ?

@ Bec - there’s certainly plenty of sockets there. I would be worried about the ones on top, though. It’s going to be nearly impossible to solder those on by hand in that orientation.

If V6 can save a V5 file, I haven’t figured out how :frowning:

As far as I know V6 cant save V5 files. But you can have V5 and V6 installed on the same PC, so why not install V6 too?

@ GMod(Errol) : thank you ! Then I will try this ASAP.

@ godefroi : I will try to check if it is even possible and tell you what I’ve found out. Success or not.

@ ianlee74 : indeed, this should be tough, but I think it can be done with air-flow. Soldering those headers is already a (big) pain, so it won’t add much difficulty, I hope… :wink:

Or, what about two rows of 3 headers ? The 3 additionnal headers could then be placed just near the ones on the right ? What do you think ?

I have had horrible experiences with these sockets and hot air. Just doesn’t work. The hot air concentrates on the high, sharp plastic edges and melts them way before the board starts to reflow. Hotplate soldering might work better…

Unfortunately, I don’t have the needed tools to do hotplate soldering, although I’m following with great interest the thread about it.

About hot air, you’re right : if temperature is too high then the plastic is melting. On my station, https://www.sparkfun.com/products/76 , I have to put the temperature somewhere between 250° C and 300° C with air flow at minimum, with the smallest nozzle.
While waving the nozzle vertically on the pads, it takes about 4-5 sec for the solder paste to melt. This is not enough to melt the plastic, although it gets of course very hot.

But I agree on the point : it’s real tough to not warm the plastic while still doing “pretty” soldering :frowning: