What is it that attracts you to Gadgeteer?

NETMF & Gadgeteer
1

For folks using .NET Gadgeteer, I’m curious what the main attraction is for you.

Is it the design surface? If so, is it because you like the designer instructing you in how to assemble the modules? Or is it because you see the design surface as documentation of your project. Or maybe it’s something else?

Is it NETMF + module classes? Is it specifically because you want to write C# or VB code, and like the module abstractions provided by NETMF?

Is it just the hardware connection, and you’d be happy with any language or abstraction on top of those standardized 10 pin connectors?

Is it the support from the forums and GHI?

If you’ve started exploring other non-Gadgeteer solutions, what was the attraction for you?

Don’t read too much into this. I’m genuinely curious about the main attraction for different people. When replying, let me know what kinds of things you’ve built with Gadgeteer in the past.

Thanks.

Pete

2

C# is the primary attraction for me (so for me it’s a toss up of NETMF or Gadgeteer)

If I am using modules, I really like the socket concept much much much more than the stacking shield approach.

While I love the support GHI gives, I don’t necessarily connect the 2 intrinsically (though they appear to be the only ones really supporting it commercially), as they support various other technologies as well.

I’ve gotten a Pi2 and have started to use Mono on it. The price, performance and built in networking was the attraction, though I am not using the header pins currently. At the moment, I’m not interesting in learning Python for this as I’m (eagerly) awaiting to see what this Win10 IoT thing is all about :wink:

3 Likes
3

For me it’s the standardized connector for the “simple” socket types (GPIO, UART, I2C, SPI, PWM, analog In and Out). The more complex types, e.g. USB or Ethernet, make little sense to me, nor those that have no software support already in standard NETMF (CAN).

I am interested in prototyping for microcontroller-based industrial projects, and for those I don’t see the Gadgeteer software layer as interesting. It adds too much overhead, because it is not as modular as I would like to see it for small MCUs. In that space, I don’t want a [em]framework[/em] with highly interdependent classes, I want a [em]toolbox[/em] containing at most a couple of independent interfaces.

The projects we’ve done (I include CSA Engineering here) are of course the Mountaineer mainboards, and later their industrial derivatives, Limmat being the latest.

My ideal would be the simple socket types mentioned above, plus one flexible fast bus, and truly light-weight driver interfaces with as few interdependencies as possible, without runtime overhead. GoBus looked interesting for a while regarding the flexible bus, except that it never got completed and unnecessarily used another socket orientation. MikroBus.NET may be a good shot at the driver issue, but I have no experience with it yet.

7 Likes
4

PS
I certainly like that Gadgeteer uses C#. After all, we invested a lot in bringing C# to Cortex-M microcontrollers by porting NETMF to this architecture. But I wouldn’t mind to see other modern high-level systems-programming languages on microcontrollers, like Go or Rust (and of course Oberon :slight_smile:

2 Likes
5

The list for me is (in this order I think):

  1. The VS Dev environment and full symbolic debugger support.
  2. The C# language and the ease of development associated.
  3. The Sockets for hardware interconnect - stacking shields don’t give the flexibility.
  4. Encapsulated Drivers. This makes the modules very easy to use. I focus on my code, not designing another device driver.

I use Gadgeteer for low volume fixtures and machines. Cost is not a primary driver the way it is when I design for many thousand units. If I can build the machine with less than $50 - $100 worth of electronics, that works.

VS, C#, Sockets, Drivers, moderate cost, easy entry point.

2 Likes
6

@ Pete Brown -

For me, the design surface was an initial attractor, as I was initially pretty intimidated by the hardware stuff. I think for beginners, this is pretty key…the ability to automate the process of instantiating hardware drivers and program to higher-level abstractions is a key win for Gadgeteer in my book.

So as BHB noted, the driver abstraction is REALLY important.

I did an abysmal job with the module driver for my first module (in fact, it didn’t even have a driver initially), but for my StarBoard module, I took the time to do a much more robust driver, and it makes things easier by far, when it comes to getting from File>New Project to a working app with the module.

The productivity aspects of Gadgeteer are a big selling point, IMO.

I’m at a point where I could probably do pretty well with plain vanilla NETMF, but I would always rather use Gadgeteer, because it’s just faster to get things done.

1 Like
7

I was attracted by relative completeness of the whole platform. It was inspiring and I wanted to build a module right away, which I did thanks to the very good module design documentation.

I do like Gadgeteer sockets. It would be nice to extend Gadgeteer mainboard specification and to be able to turn on/off sockets completely.

I still believe the designer feature is one of the (underdeveloped) keystones of the platform. It has a lot of potential and hopefully will be open soon.

@ Cuno you have mentioned a flexible fast bus. Just curious where the DaisyLink lucks in your opinion. It was designed to be that bus.

8

I second this
I chose this for the c#, otherwise if this ran the Arduino code as well, I would have taken an Arduino over this. I also love the lack of sodding and bread boards

9

I second this @ Blue Hair Bob. I made the transition from Arduino/ChipKit to GHI and just can’t imagine ever going back.

10

Interesting question as really the first thing I liked about it was the plug and play modular approach, where I could build a device and not have to deal with a single pin / interrupt whatever. I could focus on the functionality I wanted my device to have. Now the fact that I was using C# and Visual Studio were a given as wouldn’t have considered even trying Gadgeteer without that, but the designer for me was part of that hardware abstraction level and enabled Gadgeteer to move at the ‘speed of thought’ so it could keep up with my creative process. So really Gadgeteer is a package and if you take any one thing away, I might not have tried it.

Now Gadgeteer might not be the tool of choice every project, but its been a amazing start and I’ll say it again, it is the best product out there for bring software dudes into IoT land and really with a little more effort (AOT Compilation etc), Gadgeteer could be ‘The’ IoT tool.

For years we have seen other vendors try to do the modular approach as there is no doubt that is the dream, but as Gadgeteer dudes we have been living that dream.

Everyone I show Gadgeteer to, even battle hardened device dudes are impressed with it. I got a device that I’m going to show off Wednesday night at our local user group, and its a device I’ve always wanted to build, and its a simple idea, but for some reason its always been just out of reach, but now I can hardly wait to unleash it.

11

Simple way to do simple things and avoid the complexities behind the scenes.
Doesn’t fit every task, but gives an easy way to drive use of the current modules I own.

12

For me it is definitely the socket abstraction. My canonical example is working with the N18 display, I wrote a driver for the particular piece of hardware on a non-Gadgeteer platform and it irritated me trying to get the write pins connected to the mainboard and then when I tried a different board I had to go through all that connection pain again. If these where boards that used the Gadgeteer plug standard it would have been a no brainer to migrate from board to board.

As far as the designer goes, it was definitely nice in the beginning but honestly it is not a major factor for me, what it saves is insignificant compared to the effort the actual socket standard saves, at least for me.

In fact I started a project to build a native implementation of the NETMF libraries and wanted to put a native Gadgeteer library around that. Once GHI introduced mbed devices I thought I would give that a try, I like it a lot, but I would still like a native experience using the Gadgeteer hardware standard. I might pick that up again.

13

More or less in order:

  1. VB (I like basic and have been using it since the HP 9845 which was the first PC in my mind). I thought it was a major step up from Fortran.
  2. We have a large code base in .NET and much of it ports over with little effort.
  3. I wanted to move from PIC 18F hardware to ARM as it seems much more powerful, and packaged solutions (like Raptor and others) were available, and it supports #1,2 above…
  4. Stuff has gotten too small. Can’t wire-wrap up a chip these days, and cant see well enough to solder the tiny stuff. Gadgeteer sockets/modules bring the more common stuff, and the more esoteric stuff we use surfboards to hold the small components, and wire into modules like Breadboard X1 or similar.
  5. There are lots of creative minds at work in this area (Justin comes to mind, and others), and much of their stuff is accessible.
  6. The support level on this board is excellent, and at times entertaining. GHI should be congratulated.
  7. Again, regarding the boards, it is interesting to see the issues of running a small business and see how they bleed out onto the boards at times. There is probably material for someones MBA lurking here.

It has been encouraging to see MSFT become more visibly active as of late, as of a year ago I was wondering if this would be around in 5 years.

14

When I first started with NETMF several years ago the attraction was using C# or VB.NET and VS. That was back on Fez Domino and Panda. Having the full OO environment, full debugger, etc was, and still is, fantastic for complex development.

Windows CE was the same, but the hardware so expensive.

So that is still the attraction.

Gadgeteer I use mostly since that is where the NETMF development is mostly focused. It is nice for quick prototyping, but is then hard to translate to a clean and tight mechanical design. Also so many modules use just 1 or 2 pins, so I usually end up using breakout boards to get at the rest. Most of the sensors I use are I2C or SPI so I end up with breadboards and Gadgeteer Breakouts anyway.

So I`d be happy with a good modern NETMF main board with the really common things on it (power supply, LCD, Touch, USB, SD, Network) and a header for the rest. A few Gadgeteer sockets to help with prototyping. Sound familiar (see below). I guess that was Cobra II and since GHI dropped the networked one I assume it was not a success.

About a year ago I returned to NETMF after a few years away (different projects have different requirements) and I was disappointed that NETMF did not seem to have advanced that much while new players were racing ahead. That has prompted me to look elsewhere.

Really cheap and small Arduino compatible boards are one things I am starting to use a lot. For example, Adafruit’s Trinket and Pro Trinket, the Teensy 3.1 and new Teensy-LC are great for doing small simple things in a dedicated package. There are lots of others. Can stick one where ever you need it. Need to keep each one simple however as the design and debug environment are weak (ah, we come back to NETMF again).

A main project controller, with UI (screen or web server), storage, network and complex applications firmware is where I see NETMF fitting in. But now-a-days it competes with Raspberry Pi and similar. Can`t beat the price of a Raspberry Pi A+ as a project controller and UI box. Can certainly beat it from the IDE point of view, which brings us back to NETMF and the culture wars between open source and proprietary.

15

[quote=“Duncan”]Can`t beat the price of a Raspberry Pi A+ as a project controller and UI box. Can certainly beat it from the IDE point of view, which brings us back to NETMF and the culture wars between open source and proprietary.
[/quote]

NETMF itself is open source.

The IDE isn’t, though.

Not sure which one you were referring to.

Pete

16

The IDE is part of MS proprietary world, and it is that which provides a better environment for development of complex software than the open source world.

And being able to use the same IDE for development of everything from cloud, to thin client to thick client to embedded systems is useful to me. Way back when, that was the sales pitch for NETMF. And if MS had moved forward with NETMF with vigor it would have been a good sales pitch. But they have not and other platforms may now be more stable, functional and cheaper for building the mid-high end types of embedded systems targeted by NETMF.

All the above is IMHO. Many would disagree.

Duncan

17

You mentioned Raspberry Pi earlier. Is Windows 10 running on that (programming in C#/VB, JS, or C++, all using Visual Studio) interesting?

Pete

18

I agree with notes from other users.

I think the Gadgeteer concept is great for starters. But only if its 100% bug free. Starters in general have less experience with soft and hardware. They get turned off quickly if something is not working because of a silly bug.

I love the Gadgeteer hardware socket concept for quick prototyping of industrial applications.
I love the development environment. Visual studio + C# for quick development and debugging. Although can’t live without the plugin ReSharper from Jetbrains.

In most of my projects standard NETMF does not supply enough functionality so there’s the need for the premium libraries from GHI. This closes the open source concept and makes you dependent when there is a bug.

Using netMF It’s important to realize the limitations of netMF or its implementation. Sometimes it’s the speed, sometimes it’s the accuracy or reliability.

Final products we made around a netMF hardware board do mostly have external hardware with a dedicated micro controller so that we have full control of what’s happing. NETMF in those product have mainly a communication and management task.

19

The main attraction for me was the ability to code in VB. After I got a bit familiar with a platform, I really have appreciated provided abstractions, ability to debug, this forum and supportive staff.

Of course, I love Gadgeteer sockets.

20

Some really great feedback here. Thank you everyone.

Here are a few things I’ve heard:

  • Designer support helps beginners. Good tooling helps everyone.
  • Sockets are very helpful. Most like these better than shields.
  • C#/VB are important reasons to choose this platform
  • Driver abstraction is key, but only if it’s not bloated and doesn’t require a whole framework of stuff
  • Want to have a better way to move designs into production
  • NETMF has fallen behind the competition and this has made people look elsewhere
  • Needs to be bug-free (don’t think I’ve ever heard anyone ask for bugs )

I’m curious how many here have heard about what we’re doing to put Windows 10 on tiny devices (Raspberry Pi 2, MinnowBoard Max, Qualcomm Snapdragon 410). I know that doesn’t have Gadgeteer sockets or a designer, but it does support the languages you want. Of course, nothing is available to the public just yet.

http://blogs.windows.com/bloggingwindows/2015/03/18/windows-10-iot-powering-the-internet-of-things/

For you, does that change the equation at all? (Note that I’m not talking about walking away from NETMF or Gadgeteer here at all, so please don’t assume that.)

Pete