A big smile on my face now. Did you think on why GHI never released the code for daisy link? More to come very soon.
It’s probably relevant to know that I’m a smaller-cheaper-lower-power kind of person. The Hydra and Spider (and ChipworkX and EMX) aren’t interesting to me.
I think of the Cerb40 as my baby. Whether or not someone at GHI was planning/designing/considering such a form-factor is unknown to me, but I personally put a lot of time, effort, and thought into designing the smallest practical PCB for the USBizi chip, and my price target was $20. The Cerb40 module is my dream come true. I may lay out a slightly larger version that exposes all the IO, but until then, it’s perfect.
I guess my interests lie in a different direction than most people’s. The general public wants bigger, faster, more powerful. That’s great for my desktop, but not what I’m looking for in my microcontrollers.
GHI’s goal is to cover as many needs as possible while keeping top support. We always think of those wanting smaller and those who want larger. Listening to you guys here is part of our success.
Your wish is our command 
This whole discussion reminds me of the evolution of VB (and eventually C#) drag & drop programming. I remember going to conferences when this all came about and seeing just how quickly one could prototype an application for a demo. Once we got the bits home and tried to make enterprise apps out of it we quickly learned that the drag & drop functionality yielded crap code that no one in their right mind would just drop into production. However, it was very useful for what it was intended to do - quickly prototype a software design.
I think this is the same evolution that Gadgeteer & GO! are taking electronics design (and I’m hearing all the same arguments on both sides…). If you want to quickly build something based on proven electrical circuit designs & driver software then there is currently no faster way than with Gadgeteer & GO!. Are you going to take that design as-is and start pumping out 1000s of devices? Nope. It’s not a very difficult conversion with Gadgeteer. It would be considerably more difficult with GO!. However, I think if that’s the step in the process that you’re focusing on then you’re missing the whole reason they exist. They are rapid prototyping devices.
From what I’ve seen so far, it seems that GO!s design is perhaps slightly more rapid than Gadgeteer. Once more modules are available, I think GO! will be slightly more attractive to the hobbyist whose prototype will in most cases never go beyond prototype in design.
However, as I said, Gadgeteer has the lead when it comes to taking that prototype to a more permanent design. For this reason, I think Gadgeteer will be the choice of more serious hobbyist and electronics designers who plan to eventually turn that prototype into a PCB.
Once GO! has had some time to be thoroughly tested by the community, I hope that it’s benefits will either be merged with Gadgeteer or it will go away (if proven to have too many problems). NETMF 4.2 brought together some of the differences between netduino & FEZ. GO! just took that gap that was closing and split it wide open again. I’m OK with that if it eventually means the gap starts closing again.
Big smile on my face now 
Gadgeteer is seriously suffering due to it’s complexity.
Go! isn’t rapid prototyping, it’s rapid playing-around. Because you’re not actually interacting with the hardware you think you’re interacting with, you can’t even rely on the “virtualization” layer, because you don’t know what the underlying system is hiding, and when you go to production, you either have to include that, or redo all your prototyping without it.
Go! isn’t useful for teaching electronics, because you’ve abstracted away all the electronics (even more than Gadgeteer does). “Hey, look at this neato widget I made!” “Oh, that’s neat, how did you configure the SPI for that subwidget?” “SPI? Huh? What’s that?”
What Go! is good for, and for this it’s better than Gadgeteer, is hobbyists building one-offs where you don’t want to or need to know anything about the actual electronics, you just want to snap together a widget. It’s “electronics” for the people that think giant overpriced component frameworks are the greatest thing since sliced bread (yeah, I’m bitter, I’ve had zero positive experiences with “component vendors”).
Gadgeteer is drag-and-drop programming. It can be done well, or it can be done poorly. Go! is I**********s or T*****k, where it demos very well, but the moment you step out of the box a single inch, you’re on your own in dangerous waters, and your ticket is non-refundable.
[italic]This is just the rantings of a grumpy, bitter programmer. If any of this offends, I’m sorry, it’s not my intention.[/italic]
Hi godefroi,
I heard that there was some confusion about how go!bus worked, so as a co-inventor of the technology I thought I’d drop by and provide some additional clarity.
[quote]Go! isn’t rapid prototyping, it’s rapid playing-around. Because you’re not actually interacting with the hardware you think you’re interacting with, you can’t even rely on the “virtualization” layer, because you don’t know what the underlying system is hiding, and when you go to production, you either have to include that, or redo all your prototyping without it.
[/quote]
When virtualization is done well, there should be no special requirements for applications or drivers. The virtualization emulates and abstracts the hardware, microcontroller, registers, etc. providing a seamless transition for both existing and future applications.
Our goal with go!bus was to provide the same seamless experience. go!bus at its core is a virtual i/o technology. Much like plugging a USB-RS232 adapter into your PC, attaching a Serial go!bus module will give you a new SerialPort. And because it looks and works like a physical UART, code is portable to other devboards and to custom hardware.
I don’t want to be rude and dig too far into the technology since GHI does not sell go!bus products. So here’s a quick answer: enabling this type of scenario was one of the main design considerations for go!bus. In other words, we wanted to make sure that your C# driver could simply access the SPI bus on the module’s micro as if it were a native peripheral. We love learning.
Back to the main topic of this thread… I am learning a bit here about the “gadgeteer light” project and it does look interesting, particularly if GHI created a Gadgeteer-type shield for FEZ Panda (where users want to quickly adapt a Gadgeteer driver to run on a board with very little flash or RAM).
Chris
That sounds an awful lot like a prototype to me 
A prototype only needs to demonstrate that something is possible not that you know the absolute best way to implement it yourself.
@ Chris - I’m confused… Did you not know about this project? It seems that Stefan is the one that created it. Was it not discussed during the creation of GO! ?
I’m going with Pete on this one as I know he has been playing with both systems and certainly I’m watching Netduino Go and will likely order a kit once it gets past being trivial, but I’m currently fully bought into Gadgeteer and frankly I haven’t seen anything yet which would make me think my investment in Gadgeteer was anything but brilliant. I’m already working on commercial device prototypes with Gadgeteer and I’m very pleased with the results thus far and with the modules just released by GHI and members of this forum and modules yet coming I don’t see anything but possibilities everywhere with Gadgeteer. I wish the Netduino Go guys nothing but all the best, but I’m sure they can understand why I’m staying with Gadgeteer. Toss in the fact that progress and support from GHI has been nothing short of simply incredible, I’m feeling rather wildly confident in Gadgeteer and I have years worth of projects that I’m looking forward to building with Gadgeteer.
I would think that Seeed Studios also sees their Gadgeteer Modules as being rather successful and so I’m wondering what new Gadgeteer stuff they are working on and certainly some other hardware vendors must be wanting in on the initial and growing success of Gadgeteer as frankly I see Gadgeteer as the perfect balance between software and hardware and as a win for both types of developers.
[quote]ianlee74 said:
@ Chris - I’m confused… Did you not know about this project? It seems that Stefan is the one that created it. Was it not discussed during the creation of GO! ?[/quote]
Stefan mentioned that he was working on something a week or so ago, but I haven’t had a chance to play with it.
Variety is the spice of life, so I think it’s cool to see projects like this. Stefan’s a smart guy, and he came up with yet another clever approach to supporting Gadgeteer modules with non-Gadgeteer mainboards. A boon for GHI I suppose, selling more modules…
To date we’ve taken a more raw and integrated approach for supporting Gadgeteer modules on go!bus sockets… But there’s no reason you couldn’t use this instead; honestly, combining both approaches may provide the best results. I love how open source does that…brings out the best ideas.
Back to the topic of Gadgeteer Light (out of respect, in relation to its potential use with GHI hardware)…
Chris
Hi,
I shall introduce myself, I’m Stefan and I made the .NET Gadgeteer Light framework. Not especially for Netduino Go! (although at some point it can be used on one I suppose).
If you downloaded it, you would notice it does exactly that! Included is a schematic (which I’ve been working on this weekend to improve) to make a shield for that, containing 3 sockets:
- Socket 1: SUXY
- Socket 2: AIX
- Socket 3: PUXY
This will fill up all 20 GPIO pins on the Panda/Netduino and all other Arduino form factor boards. Attached you’ll find a picture showing this.
I made this because it’s very simple to use Gadgeteer modules (no soldering, no need to know about electronics, etc. I don’t need to explain the benefits of Gadgeteer to you guys), but sometimes you want to use a gadgeteer module on non-gadgeteer hardware.
Hi Gus,
About the confusion. I tried to remove the confusion from the start. I link (in every .cs file and on the codeplex page) to the original framework. I also mention on the codeplex page it’s just a small subset, and I actually explain there why I’ve made it.
He knew only just before I published it on Codeplex. It’s one of many things I worked on. As a hobby. All things I do are just as a hobby and mostly for myself. It’s just that I love open source and to share my works.
I think there’s a public for a Gadgeteer framework that doesn’t require gadgeteer hardware. And if not, at least I have had my fun and my code organised in a repository 
I also have a Fez Panda, and I could make a board provider for that as well. Would you be interested in that?
I think it’s great to see people share their work, and ideas. without it i don’t think NETMF would have made this far.
But what i think GUS was trying to say is that, Cerberus supports Gadgeteer from it’s CORE and is cheaper than Panda would ever be… so if one wants to use the new Framework he can always buy the Cerberus… and of course your Panda will always be useful for other things… therefore no need to try to make everything backward compatible, it usually just ends up hurting more than helping…because one would try to do something, big on a small board, just to realize after hours of debugging that there isn’t enough memory …
Look at how Microsoft, changed their strategy toward (backward compatibility) they just DROP the old stuff and move on, and frankly doing that allowed them to move forward faster.
with that said…
What i think is missing in Gadgeteer is a UNIFIED/UNIVERSAL Driver Interface… meaning having the same Method Names and Properties, events for the Socket, i mean we already kow ahead of time that socket1 is a Z, and Socket 3 is an S and Y so why not have a universal driver interface for that. (Think a Plugin System) … so i can interchange my Module without so much of redoing my end Code… Just a thought. it will be hard… but i would rather see time and effort spent on this than anything else… but that’s just me… think of how much memory one would save, if i have a one driver to run the Button Module and having the ability to use the same Driver for the Keypad with 10 buttons…
PS: Stefan is not only a smart guy, but he is generous as well, I’ve seen his work on Netduino forum, he never stops sharing, and i only wish him the best.
Thank you.
Hi Jay Jay,
Thanks for your well-founded criticism, and also for the last two lines of your message. I really like to see how people support open sourced initiatives, including mine.
I fully understand that you can’t always do backwards compatibility. It has to stop at some point. But with virtualisation layers, it’s still possible to run MS-DOS games on a Windows 7 PC. I still play Commander Keen sometimes. Also, a product has a life cycle. I don’t believe I shouldn’t develop stuff for a Panda anymore, just because it’s a little more then two years old (I don’t know how old the Panda is exactly tbh, sorry if it’s way older ;-))
Some people just don’t have the money to purchase every cool .NETMF board, me included. So I try to use mine as long as possible. I understand GHI wants to sell as many boards as possible, but with an initiative like this, he could also just sell more modules to those who don’t want to buy a new .NETMF board as well
Hi Garrcomm, thank you for sharing your opinion.
By the way, sine you are one of the godfathers of Netduino GO. what do you think of the suggestion that we made in this post?
http://www.tinyclr.com/forum/12/6722/
[quote]sine you are one of the godfathers of Netduino GO.[/quote]It’s a team efford. You’re giving me much credits here
I also don’t speak out for Secret Labs, nor the Netduino Go! team here, I speak out of my own personal title.
I agree that it’s a good suggestion combining forces for decent .NETMF ports. But sometimes it’s difficult to start with all cards open on the table. I think that’s why many vendors were working on a NETMF port for the same chip at the same time.
I myself am always a bit careful of publishing my projects. There’s always the thing called need-to-know. I don’t mean this in a CIA dangerously secret way, but let me provide you a simple example from my own experience. Every IT specialist has experienced this at some point I think.
When working on something awesome. Writing an article about what you’re doing, and telling people what’s coming. But then it goes all terribly wrong. You find out it took more time then expected, or underestimated the difficulty level. You find that you can’t complete something you promised.
That’s why I rarely publish something before I’m 100% positive I can do it. I don’t want to disappoint people.
For companies this can even be a bigger issue since they have many other factors to worry about as well.
If you would like a statement about colaborating on a NETMF port for ST-chips, you can better discuss it with Chris Walker, who coordinated the Netduino Go! project.
I do know though that the whole firmware for Netduino Go! will be open source eventually (if it’s not open already), so that could help.
Now I would love to get back ontopic
Tonight (CEST) I will publish a board provider for the Panda, so gadgeteer drivers can also work on the Panda. Hopefully this will please some of the people in this community 8)
I guess I don’t see any value to an IO virtualization system when there’s so much unused hardware already.
What I do appreciate, though, is Stefan’s, Chris’, and the Go! team and Netduino community’s contributions to NETMF in general and the STM32 effort in particular. This is an extremely exciting piece of hardware (to me), and I appreciate the efforts that have gone in to it.
That was quick! I look forward to checking it out. When will your Arduino → Gadgeteer shield be available? Will this “board provider” allow the Panda to appear in the Gadgeteer GUI designer as a mainboard? Do you start a project as a NETMF console app or as a Gadgeteer project?
Thanks for your contributions!
I will say this, however, regarding the STM32 effort (and I’ve said this before, multiple times).
“Open Source” means more than just posting a .zip file with a bunch of source that most people will never be able to compile (because it requires something like RVDS). I’ll call that “visible source”. If the various parties working on (and basing commercial products on the success of) the STM32 port of NETMF would like the support of the community, they need to make it practical for the community to contribute.
In the “Open Source” world, that generally means some sort of version control system, issue tracker, mailing list or discussion forum, and a way for changes or patches to be evaluated either by the community or by the project coordinators. Right now we have only one of those things.
Pardon my frustration.
Garrcomm, thank you again for the information.
Our initiative is out there publicly for all, including Netduino, Oberon and other community contributors like you ;).
The design works but I don’t have much experience with the manufacturing process. I made my own boards through Fritzing Fab (http://fab.fritzing.org/) which came out nice so far.
But with a breadboard and extender module you can use this already!
I started it as a console app, but a Panda app can just as well work fine. No GUI designer. This is just a lightweight compatibility layer between Gadgeteer modules and their drivers, and other .NETMF boards (like the Panda)
Panda code is in the repository now by the way!
@ godefroi: I agree to you on some points, but that discussion should be taken somewhere else I think. I didn’t even participated a single line of code to STM32 firmware, nor is this topic about STM32 chips
@ Joe, good to see I can understand it can be difficult to ‘accept’ my projects on tinyclr.com since it’s mainly driven by GHI and I am moderator on the Netduino forums, but believe me if I say so, I just want to help out everyone and practice my hobby as electronics hobbyist.
godefroi,
You may appreciate these two posts by Phil Haack:
Pete