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 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.
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.
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?
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.
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.
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