.NET Gadgeteer Light

Alright, point taken. To many/most, “open source” doesn’t mean more than releasing the source. I’ll update my personal definition.

Ironic, however, for Gus to be lamenting the fact that efforts are being duplicated, when not a single group, of at least three, who have created “open source” NETMF ports for STM32, have done anything to mitigate that.

Don’t think like that. We take all comers, no matter where they’re moderators. At heart, we’re all NETMF people :slight_smile:

I am sure that community members are enjoy discussing with you. So don’t worry about any piece of information you put out there as long as it is reasonable enough to be on our forum. :).

But I still insist that .NET Gadgeteer light is not really needed with the high capabilities of the new low cost hardware like FEZ Cerberus $29.95. I believe users will upgrade their hardware sooner or later. :wink:

You’re correct and I think Gadgeteer Light will make an interesting & useful addition to the overall Gadgeteer solution. I have several extra Pandas laying around that I bought when they were on clearance. It’s nice to know that I can plug some of these great Gadgeteer modules that are coming out into them and use their drivers if I decide to.

@ ianlee74: Current FEZ Panda II board owners develop applications at NETMF libraryl level or RLP which is lower than .NET Gadgeteer’s level. so I think they are experienced enough to make use of .NET Gadgeteer driver for a certain module available in codeplex and optimize it in the application without the need for the whole .NET Gadgeteer platform.

@ Joe, yes but some of us are lazy (like me) and like to really “plug and play” without thinking about code. Some of us are also bad at code (like me) so it’s better not to have to think too much about that.

Having said that I personally don’t imagine I would use this layer, I would go to the raw feature I need instead. But at least this is an option if someone didn’t want to re-code or think too much. The Gadgeteer model is also sometimes good because it might change the way a lesser experienced person might think about event based application design.

Correct, see this thread as an example: http://www.tinyclr.com/forum/2/5974/. Community member wanted to connect gadgeteer compas module to FEZ Mini. All i had to do to help him was a little modification of the driver from codeplex and some clarification which pins need to be connected where on Mini side.

Joe, I happen to own several Panda boards. So, you obviously don’t speak for us all. Let’s suppose that I have an OBD-II Gadgeteer module and a super awesome driver has been developed and tested for it that has every bell & whistle imaginable. Then we suppose that all of my Gadgeteer boards are tied up with other projects and I have a weekend project I want to take on that involves interfacing with my car’s OBD-II. Sure, I’m quite capable of writing a new driver for the OBD-II module but do I really want to spend all weekend doing that when an excellent driver already exists that has been well tested? Not if I don’t have to. This utility will be very useful for these type of projects.

I currently have plans to upgrade a couple of my Panda projects to Cerb projects in the near future. This means I’ll have even more Pandas lying around needing something to do.

The gadgeteer driver will work without gadgeteer with minimal changes. Still, I think the new changes made to 4.2 will allow it to run on panda.

I guess that’s really the piece that would settle this debate. Push it out and let’s find out! :slight_smile:

Yep seeing the changes on 4.2 would definitely make it easier to run on most boards, since they’ve split most of the code into separate dlls, which will give more memory back to the user…

This sound promising.

Is there anything you can share even in a partial state. Is it something we can comment on?

Pete

@ Godefroi

I was referring you to Phil’s post as he makes a distinction between “Open Source Software” and “Open Source Project”, which I found to be useful. There’s a lot of OSS going on in NETMF land, but too many “big reveals” and “just wait until we show you” for things to be considered true Open Source Projects.

There are many things which just get released, and you can play with the source, but I don’t necessarily see community input up-front. It’s certainly better than proprietary, but it loses many of the collaborative benefits of open source projects, both for the people designing the software/hardware, and the people using it.

Design-by-committee can be a real mess, so I’m not proposing that as the direction. However, there are often times when a little input early on in a project can mean the difference between supporting a cool scenario and not.

Companies need to decide on their own approach to meet their own business goals (they’re a business, not a non-profit in most cases), but I thought I’d make it clear which approach I prefer :slight_smile:

Pete

I understand completely what you meant me to get out of it, and it was indeed informative.

I just think it’s ironic that Gus bemoans overlapping effort…

Basically it is complete set of everything anyone needs to use and create dasylink modules.

Built in boot loader from main board
Free compiler and tools
Dip package chip option
50mhz $1 chip
Cheap debugger option
Multiple reference designs
Generic gadgeteer driver with designer
Minor improvements on the standard, pending discussions and approvals.

… And yes it is all open source software and hardware.

We prefer to provide complete package for everyone to try and comment before answering more questions please :slight_smile:

That sounds really neat! Breadboardable, as well as mass-production-ready.

I think DaisyLink is probably one of the most underutilized and underrated part of Gadgeteer.

That sounds like a really great package, thanks.

For people who may need to use a chip for other on-board processing (multiplexing, logic etc.), will the source be reasonable to port?

I have a bunch of modules in mind, and all of them need on-module logic in native code to handle heavy lifting. I’d rather not have two chips if I can avoid it.

Pete

To accompany a daisy chain (DC) development environment, a DC prototyping module would nice. A module with the sockets and chip included, and an area add whatever.

To accompany a daisy chain (DC) development environment, a DC prototyping module would nice. A module with the sockets and chip included, and an area to add whatever.

+1