For me even the whole concept of Gadgeteer is a little waste of flash space but when i think about users that are afraid of hardware things like designer, unified sockets etc. makes sence. Also thinking in that categories those LED could be usefull. That’s true that for low GPIO CPU this is too expensive but this could be an optional feature on gadgeteer boards. Also some additional chip could be added to handle the LED.
@ devhammer
D’oh iPad auto correct fail. Edited to correctly say honey now. Made me laugh when I read your post though
@ Gus
One thing that would be nice to have, and better than LEDs (if it’s possible to change the hardware standard) would be a way for modules to advertise what types of socket they implement. That way software could detect if you have the wrong module plugged into a socket and fall back into a safe mode rather than maybe damage a device. It could be implemented with seven pins, the first five being inputs encoding up to 32 socket types, the sixth being an output and the seventh a ‘socket select’, all being wired to a small PLD that implements a combinatorial logic function that returns a 1 for every socket type the module implements, and a 0 for each that it doesn’t, if socket select is also high (the socket select pin would be a dedicated connection for each socket, the other six pins would be a bus to which all sockets are connected). For example, the output pin on a USB device module would only be high if the five inputs are low, low, low, high, high (00011 = 3; if we start counting at 0, the 4th letter is D). Similarly, button modules (that go with sockets X and Y) would respond to 10111 and 11000. Sure, you lose six IOs plus one per socket, but most SoCs these days have so many that some go unconnected anyway. The firmware would start out by setting all pins to a safe configuration (eg inputs), then set the ‘socket select’ for that socket to high, and send all possible 32 values, one at a time, via the five socket type pins. If the function pin is 1 only for the functions the socket supports and 0 for all others, the pins are initialized to their normal use. Otherwise a device has been plugged into an incompatible socket and the firmware reports an error. If all 32 values return 0, it means nothing’s plugged in 
Gadgeteer is already designed so there is no damage even if you pluged things wrong. We discussed and tested this many times before gadgeteer standard was completed.
Also the gadgeteer designer does in fact tell you what modules work with what sockets.
Basically, all is covered with gadgeteer. no need for add additional hardware (additional cost)
Finally, as mentioned before, gadgeteer to production is a very simple move. You only combine all modules on one pcb and remove cables. That is for professional, for a hibbiest, it is also great because it teaches you what interface types are. For a maker, if gives you sockets with raw signals to all perephirals.
So, is that what it’s going to be called?
:o !! :whistle:
Stop with the secrets Gus, you’re too excited about this stuff 
According to the Netduino forum posts, the Go! has two separate go!bus implementations. Using a Gadgeteer module on one of the ports makes all the rest of the ports on that bus unavailable. That’s a disadvantage if you’re expecting to work with Gadgeteer modules and go!bus modules.
@ Gus
Ah, I see. Thanks
@ ianlee74
Everything in the GO line (like the rest of the Netduino) will be open-sourced and the community will clear up any confusion. Boards just started shipping and more info will be available soon.
@ EricM
Thats correct, every port accepts every Go! module.
@ godefroi
Absolutly correct, but given the available speed of the uC and the speed of SPI the delay should be minimal. Though until a few more are out in the world we won’t know for certain.
@ Duke Nukem
Nope, The Netduino community is growing very quickly. 
@ Architect
That maybe true, but the power draw is minimal, and the real estate is also minimal. I think the convience it adds is worth the < 1/4 square inch.
@ godefroi
Correct, you can use 8 Go!Bus modules or 2 Gadgeteer Modules, or 1 Gadgeteer Module and 4 Go!Bus.
Note: I don’t work for Secret Labs, but I do use the Netduino (and Fez) and am an active member of the Netduino community.
To me, just looks like a different development model for a different set of people. I can see how the Go! would make the hardware less intimidating for others.
To me, I like the pure Gadgeteer approach.
More choices are better for the community as a whole.
One thing I’m trying to figure out is… If every pin is virtualized and apparently they have the power & ground the same as Gadgeteer then why would it not be possible to create any Gadgeteer socket virtually and therefore have a full-fledged Gadgeteer port?
Certainly. You could have a Cerberus (or Spider, Hydra, whatever) pretend to be a go!bus module, and then you get all your Gadgeteer sockets.
But you lose the designer.
A similar approach could be developed within the Gadgeteer environment. Imagine a mainboard with daisy chain compatible sockets and a family of modules based upon the daisy chain protocol. You could plug any module into any socket, or chain multiple modules off one socket.
Use of the daisy chain approach would make development of modules more complex, but the development of a framework for module development could ease the complexity. A framework may exist already?
This approach would make connecting modules a bit easier, and perhaps, in the future, could bring additional hobbyists, who find the current Gadgeteer connectivity too complex, into the G world.
Remember, that the current design already supports that. You can chain up to 127 modules :o on just one socket.
How does Bitmap class work on this display?! What about NETMF built in fonts?
@ Mike - basically what you’re suggesting is that every socket be a DaisyLink socket which would certainly be cool for some cases. But, as someone who has attempted DaisyLink (and failed) that would make module development MUCH more complex and not very practical if the end result is to be a non-Gadgeteer embedded design.
@ Ian
Absolutely; the development of modules would be much more complex, but connectivity would be even simpler than today.
I am not pushing the concept of an all daisy chain socketed board. It could be something to consider in the future if the Gadgeteer community determines there is a requirement for socket agnostic configuration.
hi guys,
What if a variation of Cerburus would be created with an integrated daisy-chain chip and sockets, wouldn’t that keep development of module as it is now?
So if you want to daisy-chain bunch of module you could put the Cerberus with daisy-chain support in the middle and off you go? just wondering.
From my point of view its great that Gadgeteer has competition. Even better that both solutions use NET MF Also i agree 100% with Ians arguments.