following the discussion about the I2C hub, I was wondering if something could prevent mounting a second socket on modules that don’t use all pins on a socket ?
In the following, I omit on purpose the pins 3.3V, 5V and GND, which I consider as “common” and always used.
If you consider for example the potentiometer module, which is of type A, it’s only using pin 3. So, if you plug it on a AY socket, you loose all the other pins, yet pins 7 to 9 could in theory be used. (pins 8 & 9 for I2C ? no, kidding, don"t flame )
This is only a question, not a proposition or a request. Also, I’m not speaking of cost here, only useability or possibility.
I don’t see why you couldn’t, but it would eliminate the “plug-and-play-just-works-ness” of Gadgeteer. You’d have to know what pins a module used, and what it left over, and work out whether a given module can be chained. Beyond that, there is no way for a module to tell the Gadgeteer designer that it has more sockets. According to the Gadgeteer designer, only mainboards have sockets.
I would expect that this is something that will come in time. The holy grail would be to have a socket expansion board using an I/O expander or additional micro. A protocol would need to be specified (DL-esque) and the designer would need to be updated to support it.
I don’t think that’s the problem Bec a Fuel is really trying to solve. He just wants to access all the pins that are unused. With GO! that would never be an issue. There are plenty of things I think would be an issue but that’s been discussed…
I haven’t tried this…but what if you put an Extender module between your mainboard and your normal module w/o doing so in the visual designer. Then in your program code tried to declare an InputPort or OutputPort from the unused pins? As long as the pins are actually unused by the module and not connected to anything then you could theoretically still use those pins for something else. This is very much a hack but I think it may be possible.
Correct. go!bus is an i/o bus protocol like USB or Bluetooth, rather than a pin mapping system (e.g. Gadgeteer modules, Arduino shields, Grove modules, etc.).
Like Internet Protocol (IP), go!bus is hardware and media agnostic. The pins and peripheral features used in go!bus connectors were selected to provide (among others): compatibility with a wide variety of MCU technologies; over-the-bus ‘no-brick’ reflashing capability; predictable power characteristics; and high-throughput error-corrected data.
All the chained modules would be “virtualized” on the mainboard. That is to say, the mainboard wouldn’t know (or care) that they were chained, because intermediate MCUs are abstracting away the communication. You program as if you’re talking I2C to that module 3 spots down the chain, but what is really happening is that the I2C driver is speaking SPI to the MCU plugged into the socket, which is speaking SPI to the MCU plugged into the next socket, which is speaking SPI to the MCU plugged into the next socket, which is speaking I2C to the module.
It’s all virtualized I/O. Support must be programmed into each intermediate “hop” on the chain, as well as the mainboard.
I mean that when mainboard send something, who revieve it? You either need a chip select pin or you need software which makes if near impossible. Unless each module has a Mac address. For example, dasylink protocol (and USB) host enumerated all slaves on power up.
Its rather simple, and I’ll use an apt analogy to explain it.
Go!Bus is analogous to USB, like USB when the mainboard is started it asks all of its ports if anyone is listening. This part of the process is called Enumeration.
After enumeration the mainboard and the device can chat as often as they’d like over a standard protocol (in this case SPI 2 Data Pins, Clock and CS).
Like USB when you attach a device it communicates with the mainboard and gets an address.
When the module and the mainboard want to speak, and the module is attached via a chain, SPI is used to talk to the first device in the chain, it can then pass along the message, using the assigned address to determine which module to pass it along to. This communication is done via SPI also.
Arron, long time no see. Love seeing you guys here.
So basically there is no chip select? The mainboard sends slave address followed by data? In other words, daisylink but with SPI instead on i2c? But now if I have 2 modules of the same type, buttons maybe, how does a user know which button was pressed?
And version 2 already! Nice, looking forward to seeing it.
There is a bit of information available on our wiki about building modules, perhaps that will answer your questions. To summerize the modules are communicated with via SPI and as such a CS pin is used. http://wiki.netduino.com/Netduino-GO-Module-Builders-Guide.ashx
Thank you for taking the time to learn about go!bus, godefroi. As you explained well, the virtualization is seamless to the user’s code…regardless of module position.
With traditional pin mapping systems (e.g. Arduino shields, Gadgeteer modules), plugging in modules one uses up microcontroller pins/peripheral features as one plugs in modules. With go!bus, every module attached adds pins/peripheral features to the main microcontroller. You basically get to “design your own microcontroller feature set”, much like adding features to a PC using USB.
[quote=“Gus”]
The mainboard sends slave address followed by data? In other words, daisylink but with SPI instead on i2c?[/quote]
go!bus is radically different from DaisyLink. DaisyLink is similar to an EEPROM chain, reading and writing registers to I2C-style devices. go!bus is a super-fast, switched, error-corrected bus protocol with profiles, virtual IO, etc. There are addresses and data in the data stream, but that’s about where the similarities end.
You simply capture the ButtonPressed event for the desired button. Or check its .IsPressed property. Or use it as an InterruptPort if you’d like.
The go!bus open source protocol team will preview some of the new go!bus 2.0 features this fall. To meet a high quality bar with the go!bus 1.0 release, several features were cut from the launch list. But we baked in these capabilities to the hardware up front, and all existing hardware is upgradeable (i.e. go!bus is both forwards- and backwards-compatible).
)
One module per socket, by design… Forget my question, then. At least for Gadgeteer use, of course.
