Could it be possible for GHI to sell a very simple hub for hardware I2C modules ?
Right now, all of the type “I” modules sold by by GHI or Seeed have only one socket on them, thus ruining the I2C concept You can’t put another module on the I2C bus easily. For example, I wanted to display the data from the compass module on my I2C LCD, but I can’t have both connected on the Cerbuino (or the Hydra)
Btw, “hub” is a big word for something really simple, I think. This would mainly consist in “many” SMD sockets on a small PCB.
All you need is 2 extender modules where you solder a pin header between them. You will end up with 4 socket hub. One socket to the mainboard and 3 for your devices
My main problem with I2C modules is that they don’t have a second socket that would allow extension of the I2C bus. As it is designed now, you can’t have more than one I2C module on the bus without tinkering. To me, this is not really the goal of the Gadgeteer concept (but I may be wrong, of course).
I2C was meant to be “chainable” but modules prevent this.
How would you use both the compass and the accelerometer modules on the Hydra or Cerbuino ? Right now, you can’t without adding other modules (and some hand work) that will represent more than 30% of the cost of the modules. Not quite efficient, at least economically speaking.
Hence my request for a “hub”. Its cost should be more acceptable than trying to add a second socket on each existing module, I think, since it’s basically sockets which are connected by straight lines on the PCB.
This would also have another advantage : it wouldn’t waste the remaining pins #3 to #7, so that you can use them for other devices…
I do not think you understood my reply The hub you wanted is simply 2 extender boards.
Gadgeteer is made so users who do not know hardware can use hardware with no need for any knowledge, basically they do not know what I2C is, just plug this to that and it works. At the same time, gadgeteer is very expandable so if you know what you are doing then you can take at anyway you like, through software and through hardware. This is where open source becomes power. The most important tool to those who understand the internals like yourself is the extender module. I am willing to lose all modules and keep the extender module. It is just that important.
Yes, I think I’ve understood it. And I indeed know that this “hub” is a very (very) simple piece of hardware that can be done easily in different ways. One of them being with 2 extenders.
[quote=“Gus”]
Gadgeteer is made so users who do not know hardware can use hardware with no need for any knowledge, basically they do not know what I2C is, just plug this to that and it works. [/quote]
This is where I will (partly) disagree : how would you use both the compass and the accelerometer modules on the Cerbuino at the same time ? You simply can’t. right ?
Now, giving the text quoted just above, you also can’t ask those people to tinker something they wouldn’t know (the “I2C hub”). So, users with no hardware knowledge won’t be able to use the two modules at the same time with the Cerbuino. Do we agree on this point ?
This is where the hub comes handy : since there’s no spare socket on type “I” modules (that would allow easy connection of other type “I” modules), you could say that if you want to use more than one type “I” module, then you need to use this hub and connect the modules on it.
No need for two other modules that have nothing to do with type “I” sockets (the extenders) and that require soldering.
Btw, it does require soldering stackable headers, which non-hardware people may not be aware of
Of course, you could also say that users may need Hydra to connect the two modules, but the question will come again if they want to add the gyro, for example. Sockets 5 & 6 are the only I2C sockets on the Hydra.
Anyway, this was only a request. You may not agree with it and I won’t throw all my GHI stuff in the bin for that
It’s only that I find too bad that a “chainable” bus (I2C), supported at hardware level, is being restricted by the hardware design of modules.
It’s certainly true you could build your own hub by soldering together a couple of extenders. But I think the request was for something pre- made that solves the problem. Might it not be cheaper to make a single PCB with 4 or 5 sockets than to buy 2 extenders and manually solder a header between them?
And of course gadgeteer is not only GHI but it is an open standard so anyone or company can create and offer any module or mainboard they see will sell. Many modules have been made and sold by community.
I have already forwarded this to the right people up look into.
I agree that having a terminated I2C module does kind of defeat the purpose of I2C. And really I don’t think it’s a manufacturer fault so much as a oversight in planning of the Gadgeteer standard. Really Microsoft should have required a second socket on them the same way they do Daisy Chain modules.
So, in order to get more ‘I’ sockets, you need to also come up with 2 digital IOs. In summary, as of now, there is no automated/simple way to extend any socket type into multiple sockets of that type, no hub. And please feel free to help by cumming up with a good solution to solve this. And also provide feedback directly to Microsoft http://gadgeteer.codeplex.com/
By the way, gadgeteer uses its own interfaces, like SPI/I2C so extending the sockets is not impossible. For example, a module that connects to a socket on mainboard but then it exposes 10 additional sockets, a hub!
Are you saying that Gadgeteer access to I2C doesn’t allow specification of a slave address or am I misunderstanding this problem? Multiple devices on an I2C bus differentiate themselves by slave addresses. So it would seem to me that several ‘I sockets in parallel would allow several I2C devices to exist on the same I2C bus as long as they all have a unique slave address. It seems like a single ribbon cable with multiple connectors on it would solve this problem albeit the two extra pins are still a problem.
Incorrect, gadgeteer I2C uses slave addresses just like any I2C bus but the ‘I’ socket has 2 GPIO pins as well that are probably used by modules. So yes, if your modules only use the I2C pins on the ‘I’ socket and not the other IOs then you only need a cable with multiple sockets or couple extender modules.
I don’t really understand your last post, Gus : with every other socket, once you’ve plugged a module on it, you loose the pins not needed by this module.
With such a “hub” (or whatever term you prefer), other pins not needed by I2C are still routed all along, and thus available for use.
I think the point Gus is making is that a “module” that could have an I2C device on it, can also hijack the non-I2C data pins. Think about a scenario where an I2C device has address control lines, that get wired to the GPIOs, to allow the user to control the device’s I2C address. That’s a valid use of the I socket in Gadgeteer, but obviously you can’t “hub” two of these devices on the same socket, the use of the extra pins would be in conflict.
That’s why as Gus hints, this isn’t “simple” unless you know the device is purely using the I2C lines and no other.
I don’t “Gadgeteer” so I’m not sure of this, but I believe that the Gadgeteer system has no provision for adding more sockets. That is to say, the Gadgeteer core system asks the mainboard what sockets it has, and then provisions them out. A socket can’t have more sockets (unless it’s DaisyLink).
That’s probably the main barrier, here. If that were possible, any ol’ I/O expander (IO60P16 anyone?) could expose additional sockets. You could have “socket expansion” boards, which could have “socket expansion” boards. Enabling that would be step one, I would say.
@ Godefroi, I think the scenario you’re talking about is exactly what DaisyLink is meant to help address, the ability to cascade a collection of devices and abstract the workings of them from the mainboard.
The scenario where you have, say, four I2C 24LC256 eeproms that you want to connect on the same I2C chain works fine if you just use the I2C lines on a Gadgeteer I socket. If your module however was to use the spare GPIO lines on the I socket to set the address on A0 & A1 lines, your second third and fourth 24LC256’s would also have their addresses set using the same address lines, meaning they would get the same I2C address and you could never target one specific eeprom. However, that scenario would be an almost perfect use for a DaisyLink module.
Another scenario, say you have an accelerometer module that uses one of the GPIOs to enable reset through an onboard controller chip. That means it’s no longer “just” an I2C device, it’s an I socket device.
If you know an I socket device only uses the I2C lines, then they could be chained; but then you get complexity in the driver (that most drivers as they’re written today may not handle) that makes the experience less than “Gadgeteer”, less than prototype friendly for people with all experience levels.
The “hub” is a great idea if you control what you’re connecting to it. But you couldn’t really say it’s an I socket device, and I think you’d run into all sorts of challenges if you offered it for general sale for people who don’t really understand the technology of each module they potentially wanted to connect. So it’s an OK thing to do as a “one off, owner takes all responsibility”, but I agree with Gus in that it’s not really a module that would fit in the Gadgeteer lineup.
I think I better understand why Gus and some of you are reluctant to this idea of a I2C hub…
Here are some other thoughts, remarks or questions :
many (all ?) of the “I” modules I see on the GHI site do not permit the choice of their address. I don’t know if it can be a problem with different modules (accelerometer and compass) but it certainly is if you try to connect to identical modules. Though I don’t know yet if you really need to do such a thing (connect 2 identical modules).
is this code possible ?
Compass c1 = new Compass(5);
Compass c2 = new Compass(5);
or
Compass c1 = new Compass(5);
Accelerometer a1 = new Accelerometer(5);
This of course implies that the two modules have different addresses, but the goal here is to know if I can put two modules on the same socket.
Edit: I will try to download the code for those modules so that I can compile them against .NetMF 4.2 and do the test.
I understand the goal of “simplicity” with Gadgeteer, but then how would you connect more than 2 “I” modules on a Hydra or more than 1 on a Cerbuino ?
I think the simple answer is, use a different mainboard. A novice, with a handful of cash and a list of the modules they might like to buy that included three I socket devices, would look at the socket types the modules have and conclude that they would need a mainboard that has that many I sockets.
What I understand with your answer, with witch I would agree because of the circumstances, is that the I2C concept is “broken” in this case, as Skewworks also noticed.
This is where I don’t understand the reasoning made by Microsoft (and not GHI) : there’s a hadrware support for a by-design chainable protocol and it’s not used as such Instead, some nice daisy-link modules are proposed but that need some knowledge to be used or created.
Btw, I also find too bad that on many I2C devices (not only Gadgeteer modules and not only sold by GHI) there’s no dip switches (or similar) to program the device’s address. This also defeats the I2C purpose. But that’s another story
I agree that the concept of I2C is not the same as the I socket. Whether that’s a decision that is wrong, I actually don’t think it is; but it is a decision that has consequences. Yes, like most decisions in life You could say that the decision to have 3v3 and 5v lines on the header is also one that has a bigger impact, because it consumes an additional pin that might have been more beneficial as an IO line. Or that the socket should have been 12 pins to give 8 IOs (and 2 GNDs). But again, tradeoffs
I totally agree with you that the I2C bus can’t be used easily as a bus on Gadgeteer. But again, whether a specific device can or can’t operate on I2C alone is something that totally depends on the device or the way it’s implemented. As you point out; if it needs additional IO lines (reset line, address lines, write lines or any other control lines) then you could wire them to IOs or you could connect them to jumpers or switches; but again those are somewhat design-time decisions that you can influence if you’re making a one-off yourself, but you can’t if you rely on someone else’s module.
Caveat: I don’t know if I2C and DaisyLink is actually able to be done; I expect it is but have not looked ! But perhaps someone who knows I2C and DaisyLink could write an I2C “shell” that means you could have any I2C device connected, use multiple IOs to control address lines etc.
You can’t put another module on the I2C bus easily. For example, I wanted to display the data from the compass module on my I2C LCD, but I can’t have both connected on the Cerbuino (or the Hydra)
