Module Building

Archive
1

Hi all

Finally decided to create a new module for gadgeteer, going to be using a I2C chip, on the module, my question is this, looking around the forums it seems that people mainly prefer to stick I2C based modules on the X or Y sockets rather than the I socket, and then use software I2C instead of the built in I2C, is this correct or have i misread other threads ?

Secondly if i go down the X/Y socket route then im making the assumption that the simulated SDA / SCL lines woundnt need pull up resistors as i could just use the internal pull up on th GPIO pin, assuming this then i guess that software I2C modules would generally have only one socket and not chainable.

I have no problem with using just 1 I socket or 1 X/Y socket which effectively just blocks any chainability of modules, pretty much the same as most currently availble I2C based modules seem to do, (makes the addressing easy all modules can be fixed I2C address)

i might have missed the point and got the above totally wrong, hopefully someone could clarify for me, so answers on a postcard

thanks

2

I don’t know for sure, but the feeling I get is that I2C is complex and can be difficult to work with, especially in the confines of what NETMF exposes. That makes working with hardware I2C difficult.

Again, this is only the feeling I get from reading around here.

3

I2C is not treated with the respect it deserves, indeed :frowning:

4

The main reason for recommending an “X” socket instead of an “I” socket is that mainboards don’t have nearly as many “I” sockets as they do “X” sockets. So, if it can be done satisfactorily with an “X” socket and not consume the whole processor then I’d certainly go with an “X” socket. Better utilization of I2C chaining would be nice.

5

Big Gadgeteer deficiency here; I2C is a bus protocol, there should be provision for lots of I2C modules connected to a single I socket.

6

Could someone not make an I2C ‘i’ plug breakout extender?

‘i’ in to 3 x ‘i’ out?

7

http://www.tinyclr.com/forum/topic?id=7893

8

i have read the link, so it seems to me the problem with current I2C modules is not in the gadeteer design but in the existing module designs.

If only the scl and sda lines are used from the I socket and the module address is set by dip switches then gadgeteer would have no problem in supporting chainable i2c modules, is this assumption correct as i think it is ?

9

That is correct, but the drivers will also have to be modified…

I stick with “I” sockets for my modules, as there have been problems with software I2C in the past, which makes it hard to figure out if it is a hardware problem or software problem…

10

And if you need to go from “I” to “X”, there’s the great little “Rewire” module that can make that possible :wink: (with a custom driver)

11

That’s exactly what I’m trying to address with this (at least without specialized chip) :

[em]Edit: so far, usage is done this way, but it may change in the future, I don’t know yet.[/em]

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

namespace AppTest
{
    public class Program
    {
        public static BafModule Baf;

        public static void Main()
        {
			// Onboard Eeprom address (set by dip-switch)
            Baf = new BafModule(0x51);
            
			// 4x20 i2c LCD
            Baf.AddDevice("Lcd1", new I2CDevice.Configuration((UInt16)(0xC8 >> 1), 91));
            Baf.Write("Lcd1", new byte[2] { 0, (byte)12 });
            Baf.Write("Lcd1", new byte[2] { 0, (byte)19 });
            Baf.Write("Lcd1", new byte[4] { 0, 3, 2, 2 });
            Baf.Write("Lcd1", System.Text.Encoding.UTF8.GetBytes((byte)0 + "Essai LCD 1"));

			// 2x16 i2c LCD
            Baf.AddDevice(2, new I2CDevice.Configuration((UInt16)(0xC6 >> 1), 91));
            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"));

            //Baf.EEWrite(10, "Toto");
            var StrTmp = Baf.EEReadString(10, 4);
            Debug.Print("StrTmp = " + StrTmp);  // Writes string "Toto" to debug window
        }

    }
}
12

And while I’m at it, here’s another project currently in dev.

As you can see, I’m trying to reconcile many worlds, here. I’ve just ordered a first batch to test the idea, but there’s still things to do before it’s complete. A good occupation while waiting for the new modules with 2x5 0.1" PTH :wink:

13

@ Bec a Fuel - i assume the first module is to convert the existing modules into a chainable module ? great idea. second board i2c hub i guess ?

just to clarify my original question if i only use the SDA and SCL lines and leve the gpio pins alone and make the module dip switch addressable then they would be chainable in line with the proper i2c protocol. This seems the best way to make future boards. at least i think thats what i`ve convinced myself of.

14

Please see http://www.tinyclr.com/forum/topic?id=8993 for a sample of the first board.

And I think this answers your question ? :wink:

Also, this module is routing the pins 3 & 6 across the Gadgeteer headers. This way, a module using them can still work correctly. Of course, this behaviour is limited to only one module.