The future of Gadgeteer

nobody kick the bucket, ok?

1 Like

No, Gus, I didn’t complain. I only noted. Please don’t put words in my mouth.

Question:

Without gadgeteer, will there be any way to have a visual studio drag and drop layout designer with just vanilla .netmf?

With respect to a Gadgeteer-compatible designer, there are two ways : write a new one, or Microsoft open-sources the existing one.

I am pursuing the latter option internally within Microsoft. There are a few hurdles to overcome yet (I don’t ‘own’ the code within MS, and there other folks that rightfully need to sign off on its release, and a legal process to get through, so it’s not a done deal, and it won’t happen tomorrow). That said, if I can get that code shaken loose, then we’ll have a complete set of Gadgeteer libs and the designer in open source for the community to maintain, for as long as such community cares to do so.

EDIT: The previous effort to do this kinda stalled out, so I am trying to either finish the process or definitively call it dead.

7 Likes

without Gadgeteer, there’s nothing that needs drag-and-drop is there?

@ mcalsyn - tell James to pull finger else threaten him with “if you dont Justin will come knocking” :smiley:

1 Like

Priceless as some of the modules I’m pretty sure I’m the only one that has them, unannounced original Justin specials!!

1 Like

I have at least one (usually more) of every Gadgeteer module that GHI ever made (I likely have about 50 mainboards and got good use out of every one of them) and at least four of their bluetooth modules and their support of their modules and even modules that Seeed created (ie the GPS issue) was outstanding. The bluetooth module might have been a bit skinny on the driver, and the music module had some issues but clearly GHI drivers were the gold standard and the fact that the source code was available helped me learn how to write drivers and easily maintain and enhance ‘obsolete’ modules. Most third party modules didn’t have source code available so I have to re-engineer the driver from the chips on the module on up and try to figure out pinning etc. GHI had not only source code but schematics and such for their modules. In short GHI really tried to make it easy for software dudes like me to use their modules and learn their ‘secrets’ and become hardware savvy, which I think I became and along the way built a ton of devices and started to love coding and creating stuff again.

No doubt I’m sad to see Gadgeteer go as I made a fairly substantial investment in Gadgeteer in time and money, but I loved building stuff with it (and teaching), as its still the only hardware platform that can keep up with my creative thought process as the modules and the designer are unmatched in concept and implementation, but Microsoft choose to let it die and my personal opinion is that is a huge mistake. Not my monkeys and not my circus (to quote Kerry Hammil for all you old Gadgeteer folks), but I tried to make a difference. My next trip to Redmond likely won’t include a visit with the IoT guys as clearly they have chosen a different direction and I wish them luck and maybe someday they will recapture my interest, but for the time being I have different marching orders.

3 Likes

Can you enlighten me, as I think the MS-IOT strategy seems kind of fluffy?

1 Like

@ Gus - [quote]We love the community but the commercial users dictate what we do. The lesson I learned is that GHI did best when we did not get involved with open source, before even netmf was open source. It is simply not for us.

I agree with the many posts, no gadgeteer, no open source, complete focus on netmf. Just like how GHI was before. [/quote]

As I would consider myself a commercial user, I don’t think the answer is quite that cut & dry. While the Fez concept is great for some applications, I’m reading that many more commercial applications are using their own ports to the HW, being able to customize items at the Native runtime level. From my own perspective, If GHI would make open source the BASIC (non proprietary) tools to be able to do this, specifically for their modules, (even if a NDA / Non Compete was needed), it would certainly be a VERY POWERFUL incentive to not look at designing a cheaper module, but simply sticking with buying pre-made ones / or working with GHI to produce a custom one, and allow the creation / debugging of Native code when specific Deterministic behavior is required. (I know some of this exists already, but I’m specifically speaking around the G400)

Secondly, Given that the VP of IT at the company I contract to is a hobbyist himself, and has created several projects with the rasperry pi / Arduino platforms, I’ve quizzed him on why he is using those vs the Gadgeteer ones, and the answer simply comes down to advertising. He just isn’t aware of the differences, especially after hearing him complain that “the instructions were printed right on the board, but can’t get it to connect”, or it said to add a “bypass resister”, but he had no idea why (it was a pull down on a port similar to GHI’s Load Module). He has absolutely no idea about the debugging tools / intellisense that VS offers.

Lastly, given that their is a stated commitment to focus on Netmf, will the modules that exist now still be available in the future, (ie Load module, Ethernet, ect), but just with a different connector style? I’m working on a back plane at the moment to accommodate large numbers of Temp sensors, and wondering if there is a standard type of connector I should be looking at, although I’m leaning towards a similar idea to Bec a Fuels board, but customized for my specific application.

@ michaelb - as for hardware, the current plans is to focus on the SoMs, and FEZ boards that use these SoMs.

For the “accessories”, most commercial users do not need them plus there are many options on the market for those that do need them. Grove, click, shields, sparkfun, eBay… Unlimited options.

MS’ IoT strategy is simple: “drive users to Azure”. Everything else flows from that; Gadgeteer drove few users to Azure, so it’s not part of the IoT strategy.

2 Likes

That was no fault of Gadgeteer, though. Even with vanilla NETMF there still is no good IoT option (Azure or otherwise). The SSL bug still exists and a low price board with WiFi still doesn’t exist. Until these issues are resolved, NETMF’s value just continues to fall further down considering the needs of the current time. Networking & creating IoT on NETMF is far from FEZ today. Sadly, we’ve been having this same conversation for about 3 years now. Had these issue been resolved then there might have been a chance for Gadgeteer as a plug & play contender in the IoT space.

1 Like

@ ianlee74 - The SSL problem is a deal breaker. It is causing me to move to other platforms like Linux and Particle.

I think calling it ‘fluffy’ is more then a tad generous as that would imply that it has some form or structure.

Its funny how many companies and project teams I come across who’s strategy involves wandering around in a forest hoping to stumble upon a kindly old fairy godmother to give them a bucket of money and grant them three wishes, none of which involve their work, in short ‘we don’t need no stinking strategy’ or at least we don’t need to tell anyone, including ourselves. I sometimes wonder if lack of strategies or vision is a by-product of the ‘Agile’ mentality.

1 Like

[quote=“michaelb”] although I’m leaning towards a similar idea to Bec a Fuels board, but customized for my specific application.
[/quote]

In my opinion, MikroBus sockets should be seen as useful for prototyping and/or as an opportunity to provide different optionnal features on your custom devices : you can code your application and driver(s) using a Quail or the (soon to be available) G400TH Carrier board populated with Click modules and once you are fine with the whole thing, then nothing prevents you to “extract” the parts from the Click modules and put them on your custom design. Since their datasheets are available, it is very easy to do.

The other way of thinking (optionnal features) is easy to achieve if you provide some MikroBus sockets : as long as drivers exist, you can provide your custom design with, for example, Bluetooth or Wifi or LoRa or whatever you like.

Of course, a mix of both ways is possible.

I would add a third use case : if you also design your own Click modules, then a MikroBus socket on a design can provide an easy way of replacement for your module. No need to rebuild an entire PCB because of minor (or even major) changes on a module.

This has been done on a commercial project (see pictures).

My purpose here is to say that there are other means of either prototyping or building commercial products than Gadgeteer. MikroBus sockets are one but as Gus said, there are many others available.
Gadgeteer discontinuation may not be that dramatic, to me.

And I would add for Duke Nukem that it could be a good solution for his training courses as well : no cables, no mess on the desktop, a huge amount of available modules (not from MBN) and pure NETMF programming.

7 Likes

This should be considered as a new opportunity.
Joining the GHI boards and standards like ‘click’ microbus and/or ‘grove’ for addon modules would make this the top solution.

Combining netmf and RLP is unbeatable.
Now lets join the new module standards.

1 Like

The community already have click options. As for grove, there is a shield https://www.seeedstudio.com/Base-Shield-V2-p-1378.html drivers and examples can definitely be done.

Take a look at this device

3 Likes

Now in the Catalog FEZ Lemur, FEZ Panda III und FEZ Cobra III got the Legacy label too, is this correct?