MS Gadgeteer site: http://www.netmf.com/gadgeteer/forum/default.aspx?g=posts&t=2473 leads to Netduino GO forum: The GoBus Upgrade - Netduino Go - Netduino Forums
Have any of the “cross pollinators” looked at the driver code for a Go module yet? I’m assuming any Gadgeteer module would need a whole new driver to work on the Go.
Have you tried Netduino forum?
Yes, just wondering if any of our “locals” who also have a Go might chime in.
Valentin, do you want to mention what you got a Maker Faire?
Yeah I have that bridge module, but I don’t have GO so I haven’t tried it. Remember GO is not a Gadgeteer. Module drivers use Gdgeteer interfaces so you will need to rewrite the driver for GO.
This is very interesting. You most definitely need a new driver for Go!. The real question is how difficult is it to convert. The obvious question that Gus probably doesn’t want to hear asked is will GHI be providing these drivers to this other revenue stream. I think I know the answer…
Even if we were to provide drivers for non-gadgeteer products (arduino, beaglebone, raspberry pi, go), this will still not work in the gadgeteer designer, which ruins the beauty, friendliness and easiness of gadgeteer.
ahhh…this somewhat runes the surprise but here you go, gadgeteer is already designed/planned to have hubs and work with the same drivers and same designer 
It would be as easy as writing a driver for a module using plain NetMF.
I was also going to mention Arduino which probably be more interesting revenue wise.
Nice! When? 4.4?
Yes, but two totally different camps. I doubt you’ll find many Arduino users wanting to use Gadgeteer modules. They already have their own vast assortment of shields/sensors.
Hi Architect,
It was good meeting you at MakerFaire. Thanks for stopping by and saying hi.
We’ve been working with MSR on Gadgeteer for over 2.5 years now, so I’m excited that this I/O adapter is finally sneaking out from the lab.
To clear up any confusion about Gadgeteer-over-GoBus…
Yes, the Gadgeteer designer works with the Gadgeteer Adapter. GoBus Virtual I/O works just like standard I/O.
Gadgeteer Adapters can be plugged into Netduino Go or one of the upcoming GoBus hubs. Each low-cost adapter adds four Gadgeteer sockets.
You can add a ridiculous number of Gadgeteer modules to your project. Hundreds of sockets of types A, I, K, O, P, S, U, X, and/or Y. Pick what you need.
Third parties who are developing Gadgeteer modules can focus on the simplicity and speed of non-DaisyLink modules. By leveraging GoBus, you can have the number and type of Gadgeteer sockets you need…without changing the modules.
The goals here are to enable hybrid GoBus/Gadgeteer/Shield projects, to enable larger Gadgeteer projects, and to help MSR and module makers expand Gadgeteer adoption.
There’s a ridiculous amount of technology powering the Gadgeteer Adapter. If you have any technical questions, please feel free to ask.
Chris
P.S.
GHI is making a big investment in Gadgeteer modules, so I anticipate that this adapter will be good for GHI sales. Hopefully this news brings a few smiles to the Issa family.
So, does this mean that no Gadgeteer driver modifications are necessary?
Hi Ian,
I can tell that this will be a frequently-asked question 
Thank you for asking me to clarify.
No Gadgeteer driver modifications are necessary. You can use the Gadgeteer designer. It works similar to any other Gadgeteer mainboard.
The beauty here is that Gadgeteer modules can take advantage of a few of the nice features of GoBus: virtualization, high-speed hubs, wireless hubs, and more.
Chris
Marketing talk aside, is there any tutorial with snapshots of a video showing how this works?
@ Chris, thanks for the answer. I’m with Gus. I want to see this in action. Sounds like magic
We announced this module at Makerfaire last weekend and showed an actual demo project. I wish you could have been there, would be nice to meet you some day!
The modules are currently in production, but I can share this screenshot. This screenshot is 100% real and made in the designer. The modules are so new that I don’t have photos, but I will add in the module photos soon too.
I completely understand you want to see some magic in action! I hope I can make a video soon, but for now, there’s still some work to do.
@ Garrcomm - That looks very cool, but if you will excuse my ignorance here as I know little to nothing about how Go-Bus works, I have a question purely out of curiosity.
I can sort of understand that the Gadgeteer module will connect to the “Adapter” module, but how does the adapter module know how to configure the Go-Bus socket to function as the required socket type, what tells the module you now have to act like an ‘S’ socket?
My guess is that at runtime you initialize the port based on the Socket.EnsureTypeIsSupported and then configure the port appropriately, and in the designer you present the sockets and everything so that they designer allows the connections from any module to any of the ‘Adapter’ module ports. Is that close?
Hi taylorza,
Good question. It’s even simpler than that actually. All the Gadgeteer logic happens at design time, just like normal Gadgeteer mainboards.
When you add a GadgeteerAdapter to the designer, a standard Gadgeteer constructor is added which tells GoBus where the Gadgeteer Adapter is located physically. GoBus would normally auto-discover it…but in the case of the Gadgeteer designer we’re making sure that everything matches.
At that point, Gadgeteer basically sees a Netduino Go mainboard with 4, 8, 12, or 200 Gadgeteer sockets. The virtualization magic happens in the GoBus stack: to the designer, the Gadgeteer Adapters’ sockets are just normal Gadgeteer sockets.
Chris
P.S. I think there may be some confusion about how GoBus works (versus pin mapping). Here’s a quick primer which may shed some light on how all this works.
Gadgeteer sockets use pin mapping. The letter combinations indicate which pins offer which features. This is the same way that Arduino shields work…except that the layout and combinations of pins change from socket to socket. When pins are shared between sockets, the pin-sharing sockets sometimes lose “letter” features. Pin mapping is the traditional method used to build electronics projects–Arduino, traditional Netduino, FEZ, Gadgeteer, BeagleBone, Raspberry Pi, etc. all work this way.
GoBus ports don’t use pin mapping like Gadgeteer sockets. GoBus ports use Virtual I/O. So when you plug in a GoBus module, it adds the features of that module to the mainboard as if those features were part of the mainboard’s MCU.
This is the same concept as plugging in an USB-RS232 adapter to your computer. Plugging one in adds a serial port to your PC. It doesn’t map the USB connector pins to UART_TX, UART_RX, etc. It’s virtual I/O…you just add what you need and the software on your computer doesn’t see any difference.
Hi Chris,
Thank you for the explanation, I must admit I am not sure I understand 100%. But, I have not played with the GoBus technology so there is probably an important part of the picture that I am missing. I hope to get a device soon and maybe I will get more clarity, experience is the best teacher after all 
That’s alright. And yes, experience is a really awesome teacher.
In summary…
The procedure is identical to using a standard Gadgeteer mainboard. Except that in this case you’re dragging one more part onto the design surface.
Thanks again for the technical questions,
Chris