I guess this is geared more toward the Netduino Go, since my Panda doesn’t have any Gadgeteer Sockets…
http://gadgeteerlight.codeplex.com/
but then again i could always use the Extender Module…
But why? This will only confuse users and gadgeteer core fits well on Cerberus!!
I hope these guys have a good plan or this can endup being a big mess!
By the way, Microsoft refactored the core in multi DLL so it is even smaller on 4.2 coming next week 
My guess is so you can run Gadgeteer drivers (DRIVERS, not just modules) on non-Gadgeteer boards.
I didn’t look at the code, though.
This is a bit odd, but I don’t want to discourage any work that has potential.
That said, seems you would have to pull a lot of stuff over to make the driver work. My own approach is instead to share core code and add the device-specific code in a separate library. That’s why I did on my MIDI module driver at http://petebrown.codeplex.com .
That way you can take advantage of what each platform offers, while keeping the code pretty tight. I’m not sure I would want to load a pile of Gadgeteer stuff on, for example, a Panda.
I’m more interested in sharing hardware as much as possible. Code is easy to change 
Pete
Unfortunately, Gadgeteer doesn’t encourage sharing hardware that much, either (it doesn’t discourage it, either… that’s why I have .1" headers on my OneWire board).
Let’s see:
[ulist]1 Gadgeteer socket: $1.95 plus shipping from GHI.
1 ENC28J60 ethernet breakout module with .1" headers, DELIVERED, $3.60 from China[/ulist]
Way better than go!bus though, where you’re not just soldering a 10-pin SMT header, you’re acquiring and soldering a whole extra MCU (and dealing with programming it!).
Rereading this post this morning, it seems that I was complaining about GHI’s pricing model, and I definitely wasn’t. I think GHI’s hardware and support are top-notch.
I was just commenting on the realities of Gadgeteer (and go!bus) hardware design.
Sockets are $0.50 in full reel and architect is also offering low quantity for low price. I can only see prices going down in future as this catches on more and we see even higher volumes.
Just as an example, if you compare prices of modules to shields or just any prototyping board, I do not see gadgeteer costing more. I see it costing less. Compare to sparkfun, arduino, netduino…etc.
But this thread is about forking gadgeteer core instead of contributing to gadgeteer, which is very new and could use community contributions. For example, the socket protocol use on neduino could have been contributed to gadgeteer as another socket type. And instead of making a “light version” separate, this could have been discussed and worked on with gadgeteer team…which gadgeteer team already did in 4.2 as I mentioned already!! Not to forget daisylink.
I think in particular DaisyLink covers most of not all of the use cases for go!bus modules.
i myself was wondering as to why this project exists, and that’s the reason why i posted it here when i noticed it on Codeplex…
Hopefully GHI can get together with whoever is really behind this and find a better solution then creating a derivative work of Gadgeteer Core…
only time will tell i guess.
Cheers.
There is no need for a derivative. ;).You will see why soon.
I’m not sure I follow you. It seems to me that the only use case that GO!bus modules have is that they are virtual and can be plugged into any socket. DaisyLink only addresses chaining of modules. I haven’t seen any mention of chaining GO!bus modules but I suspect that it would not be a difficult enhancement. At this point, however, I don’t see any overlap between DaisyLink & GO!bus.
Any .NET Gadgeteer socket type X or Y (which is on almost all the sockets on the mainboard) is a DaisyLink socket. I think “Go” Bus got the same concept of DaisyLink “bus”. The difference here is that DaisyLink bus is chain-able but Go is not.
go!bus is quite different. It’s a pin virtualization scheme (among other things). I’m really just learning it, so let me describe what I know, and correct a few assumptions made here.
It’s not like daisylink, which is intended as a way to chain modules. It’s a fast SPI (or uart if necessary) based protocol for communicating to modules to enable pin virtualization. For example, a module could surface, through that protocol, 30 new digital pins, or maybe it surfaces 5 uarts, or maybe 25 analog pins.
From client code, you refer to the virtual pins like any other pin. Higher-level driver code that needs to be provided with pins to work, would work whether those pins are virtualized or local. (This is one place where Gadgeteer has a deficiency: if you create a button module with 25 buttons, you can’t directly use the same code/binary that came with the gadgeteer button module, as the drivers are very implementation and hardware module specific by design.)
It’s also autodetecting and auto-configuring. Plug stuff in and it just works. Unplug it from one socket and move it to another, and it still works.
The other thing that I like about it, is that the official, tested, go!bus communications firmware for specific on-module devices (STM chips, primarily, although someone is working on AVR) is being made available. I’d love to see the same thing happen with Gadgeteer to make it easy to develop inexpensive daisylink modules with known chips and tested firmware. Including something similar to the standardized go!bus module firmware update code/process would also be nice.
I picked up a few of the STM chips and a programmer. They’re pretty inexpensive, even cheaper than AVR, surprisingly. Also, not every module needs programmable logic. IIRC, the button module has just a shift register or something that returns an ID to enable auto-configuration.
I’m planning to develop a few modules that will target both Gadgeteer and Netduino (as well as classic Arduino form-factor devices). Those modules all needed an on-module chip anyway to handle processing, so there’s no extra cost other than whatever code I need to write to detect and enable the correct protocol. Once I standardize that, it’ll work for most anything.
To be very clear, I’m not saying this approach is better than Gadgeteer, just that it is a very different approach.. I happen to like both approaches, and both companies. If it’s C#, I’m into it
Could it be contributed back into Gadgeteer? I don’t see why not – it’s fully open source. The only thing that (to the best of my knowledge) requries any sort of agreement or license to use is the (G) go!bus logo. I actually think that approach is probably more scalable than the other way around: implementing Gadgeteer on the Netduino, but if you’re talking something with limited resources like the Cerebus, I guess it’s the same either way.
Why both? Many people ask why we need both Google Chrome and Mozilla Firefox, or why we needed .NET when we had Java, or why Silverlight when there was Flash, or why ASP.NET MVC when there’s Ruby and whatnot, or why NETMF when there’s Arduino. I think choice is good.
Then again, we could just build some sumobots, one controlled by Gadgeteer and the other by Netduino, and let them duke it out 
Pete
The pin virtualization is independent of the bus technology. It would be just as easy to do pin virtualization over I2C or SPI, UART, or any other communication protocol.
In fact, there are lots of cheap, widely-available I2C and SPI I/O expanders pre-made that require none of the firmware programming and SMD soldering that a go!bus IO module would require. It would be just as easy for them to have implemented the pin virtualization scheme on top of that…
Sure. As far as I know, they currently support SPI and UART. If you want speed, you need to go with something like SPI. i2c is typically speed limited, as is UART.
Maybe, but I bet it would cost more in the long run. The STM chips they use cost $0.30 in quantity, about a dollar or less in singles. The programmer/debugger was like $25 or something. For those of us who would need on-module logic anyway, this makes sense even more. For others, it’s really no worse than having an on-module chip to support daisylink. For example, take a look at the Gadgeteer multicolor LED module.
More importantly, Gadgeteer wasn’t designed with this approach in mind, so supporting it is a bit of a kludge, just like supporting Gadgeteer X, U, and S sockets on Netduino seems like a bit of a kludge. It’s simply not the primary way either device was intended to be used. See my comment about buttons and whatnot in the previous post.
Why wouldn’t you need SMD soldering with an SPI port expander? Most modules won’t stick a big DIP on board. SMD soldering isn’t very hard*. In fact, most modules even for Gadgeteer use SMD components. That said, I know some folks are working (or have completed) a go!bus implementation for AVR. Those chips tend to cost a bit more, but you have just about every form factor possible there.
In any case, I’m not quite sure what you’re getting at. There are lots of ways to approach the problems, but Gadgeteer and Netduino decided to take different routes. I think both have merit. I don’t think this needs to be adversarial.
Pete
- This guy makes it look REALLY easy. After seeing him and several others do similar work using one of those iron tips, I bought one last night. I can’t wait to try it out. http://www.youtube.com/watch?v=5uiroWBkdFY
What is one thing you can do with go and can’t with gadgeteer? Nothing I can think of and it is even easier and better with dasylink, more on this in about a week.
Now what can you do with gadgeteer and not on go? Many things. Like use built in can or display.
Of course you can add go to gadgeteer core but why since there is dasylink and it is better, more on this next week
Certainly, and I agree. I’m just in it for the friendly discussion. If nothing else, Secret Labs and the contributors to the project have advanced NETMF, and that’s good for all of us.
Definitely, when you’re talking DaisyLink, you’re talking another on-chip MCU, regardless. The chainable design of DaisyLink is a plus in it’s corner, though. I wouldn’t doubt that go!bus could be extended to include this sort of functionality, though.
Most wouldn’t, but they COULD. Just like one COULD support DaisyLink with a DIP AVR or MSP430, or PIC, or what-have-you. Like you said, most don’t, though, and I expect that won’t change much. Until support for one of these DIP MCUs becomes available for go!bus, however, it makes breadboarding a go!bus module difficult without another MCU breakout. All these extra MCUs also have an impact on the power consumption of the system, so I wouldn’t expect to see much in the way of production hardware using the concept.
No, but I would be surprised if this functionality wasn’t on the radar for the Gadgeteer folks. Now that Gadgeteer is out “in the wild” and we’ve got some experience in how people use it and the limitations that exist in socket types, I would expect that two things will happen:
[ol]Modules will become available that more fully take advantage of a socket (for example, Sytech’s SD/Ethernet module, or some hypothetical multiple-button module).
Gadgeteer will gain the ability to work with “virtual” sockets, or sockets provided by modules instead of merely sockets provided by the mainboard[/ol]
Either way, Gadgeteer’s not my thing, for the same reason go!bus isn’t my thing. I prefer to work “closer to the metal”, and the great thing is that there’s room for all of us to get along and even work together.
Gus, the same argument could be made for any of the modules you sell vs. any of the other modules. Panda, Cobra and others.
In fact, the same argument could be made for Arduino vs. NETMF. In fact, the ecosystem for Arduino is much richer than that for NETMF. NETMF, however, provides a different approach, and that alone is important enough. Gadgeteer now has a ton of modules which makes it even easier, but I think you’ll find shields to still be more ubiquitous.
Also, for differentiation, see my previous comment about reusing drivers vs. modules. If you connect a pile of buttons to your new IO board, you can’t use the existing button driver code as-is, as it is tied to a very specific piece of hardware. That’s one of the few things I’ve seen that gave me an “aha”.
Like I said, this doesn’t need to be adversarial, but it certainly can be competitive. I like what GHI is doing and has done for the ecosystem and for the community, and I also like what Secret Labs is doing. Having you both around, doing somewhat different things, is good to keep everyone on their toes. I tend to be a bit of an equal opportunity hacker. Without digging into my storage, here’s what’s lying around on my desk right this minute just for MCU dev stuff:
[ulist]FEZ Spider kit on a board (plus a bunch of modules)
FEZ Cerebus kit on a board
A FEZ Panda
A Mikroelektronica easyAVR6 with two displays (running the same LED chaser non-stop since January )
A Netduino Plus
A Netduino classic
A Netduino GO kit
An AVR In-system Programmer
An AVR JTAG Debugger
An STM8/STM32 Programmer/Debugger
An Arduino with a 4 axis stepper shield
A hand-soldered SparkFun SMT Simon kit that runs Arduino software
A Mikroelektronica Ready for xmega board[/ulist]
There’s a PIC programmer around here too, but I haven’t gotten a chance to work with it yet.
My eggs are not in any single basket
Speaking of dasy/daisy: I’d really like to see some standard firmware and hobby-friendly reference design for dasylink (IOW, not something that needs a $1000 programmer). My initial experiments with it proved difficult and didn’t get very far.
Pete
Furthermore, I can’t really say I understand the NEED for I/O virtualization. The only thing it buys you, really, is the ability to plug anything into any socket (but it doesn’t even do that, really, because, F.E. one Gadgeteer module consumes HALF of the sockets).
If the problem is not enough I/Os, then there’s an LQFP-176 part that has a STAGGERING amount of IO available. That part has:
[ulist]Up to 24 channels of 12-bit A/D
2 channels of 12-bit D/A
17 hardware timers
Up to 16 PWM outputs, which can be mapped a large number of I/O pins
2 CAN busses
3 I2C busses
4 USARTS/2 UARTS (>10mbit)
3 SPI busses (>37mbit)
140 GPIO pins[/ulist]
This part is only a couple bucks more expensive than the 64-pin part in the Netduino Go! and the Cerberus. Porting the software between packages is trivial (it took nearly no time to port GHI’s release from the Cerberus to the Discovery, which is a 100-pin package).
It’s possible that that’s not enough I/O for some project, but that’d be a pretty advanced project. To take a MCU as powerful as an STM32F4 and use nothing but a couple of SPI and UART peripherals, well, it’s a giant waste, in my opinion.
I guess, for me as a non-Gadgeteer, non-Go! person, it boils down like this:
[ulist]Gadgeteer mainboard: I can use it, because it’s got normal GPIOs and accessable peripherals, just like any other NETMF board.
Gadgeteer module: I can use it, because it takes normal inputs available on any MCU.
Go! mainboard: not useable, because I have no Go! modules, and it’s got almost no peripherals and IO exposed.
Go! module: not useable, because I have no Go! mainboard, nor would I want one (see above).[/ulist]
The gulf between Gadgeteer and Arduino may seem large, but the gulf between NETMF and Arduino isn’t, because they’re both just easy ways to program a microcontroller. Gadgeteer is simply a convention and convenient library layered on top of NETMF, so it can be used as a normal NETMF board. Go!, not so much, because the design doesn’t expose much of the underlying MCU’s peripherals.
The fact that it costs another $25 and requires another extremely powerful MCU to be able to use Arduino shields is, in my opinion, a giant disadvantage. I wonder how streaming music from SD to a music shield would work over two go!bus hops…