I have that module, and have used that driver (and contributed suggestions too), and I don’t think it’s a joke; I have it in “production” use on my thermocouple datalogger. Perhaps not as simple as it could be, certainly not as polished, but for what I want it’s fine.
I agree that the intent of Gadgeteer is simple to use drivers that don’t require you to delve into datasheets. I would also say that to a degree this means the “problem” extends past the driver and really needs a thought-out API design - how will the real world use of this device work, not just how can I abstract the user from the configuration and the comms details etc, but still let them figure out how to use it.
I think that Gadgeteer is better for having the Seeed modules, but I honestly think they have a hardware focus that doesn’t flow down into their software focus and that has left the drivers somewhat stranded. They may have seen this as a “quick” way to get a new market for their existing IP; change teh socket on the board, use black soldermask, and you’re good to go. From the outside is seem as if they have thought this was too hard and won’t continue to add more modules to their current list.
I think GHI are doing a stellar job. Adding more modules that are desirable in the community is fantastic. But as Godefroi says, for them to have widespread appeal a conprehensive driver needs to be available. But when is the right time to release the hardware? I get that widespread adoption needs solid drivers, but perhaps it’s worth calling out where a hardware piece is released for community testing with an evaluation driver, not a real driver in the Gadgeteer designer sense of the word. For those people who want to get their early adopter bonus points, great; if not, you know you won’t get the polish up front. Or maybe don’t list them in the Gadgeteer module section, but in a more “experimental” heirarchy; something to distinguish they may not have the experience a lesser-experienced end-user would expect.
[quote=“godefroi”]Maybe what each module needs is a CodePlex project of its own. That way you get issue/feature tracking (which is HUGE, and something I’ve suggested several times), revision control, and documentation tools.
[/quote]
That is exactly what I’m recommending. Each module should be treated as it’s own project and not as one bit of this goliath called the Gadgeteer project. I also want to install drivers via Nuget rather than as part an SDK update… Of course, this starts causing problems for people new to Visual Studio.
Something else that I think should be made clearer is the status of drivers for different firmware releases, I brought a bunch of modules a while back only to find there where no drivers for 4.1, and even though 4.2 is close it’s still not released. As nice as it is to think that people will always be on the bleeding edge, that’s not the real world. Especially given the lag in getting 4.2 out the door on the GHI boards.
I also agree with godefroi, that the modules should be cut from the main gadgeteer project, and moved into a stand alone project. It would also provide a chance to switch to GIT or Mercurial, something that makes it easier to submit patches and branch.
Another option is to start putting all the module drivers up on nuget as separate packages. I think that would be an ideal solution is it would massively reduce the overhead of getting new module drivers out to users.
@ ianlee74 I think it’s perfectly valid that a company like Seeed should be able to produce hardware only modules, they just need to be clearly marked as such. I’ve got no problem hacking up a driver for a module if I know that’s what I’m letting myself in for. Expecting a PnP experience and finding out I’ve got to wade through arcane data sheets and schematics to get the thing to work isn’t on.
That is exactly what I’m recommending. Each module should be treated as it’s own project and not as one bit of this goliath called the Gadgeteer project. I also want to install drivers via Nuget rather than as part an SDK update… Of course, this starts causing problems for people new to Visual Studio.
[/quote]
It seems I took to long writing my reply
We could update the new project templates for .netMF to include all known driver packages at the time the SDK was built, much like ASP.Net works. This would allow the core gadgeteer framework to ship and then auto update when you create a new project, new users would not really notice a difference.
That said, I’m not sure how clever the MF compiler is, if there are a load of unused references in the project, will they get deployed to the target device?
Haven’t got VS installed at the moment so can’t go and have a look.
I don’t know if that is really a fair statement as XBee in and of itself if a bit of a gong show at the hardware level and product versions and has its own limitations, but that is the nature of the problem and the XBee solution which forces a custom thin skin for the hardware and the bumps of the different versions of hardware tend to show through. Certainly part of the problem is self inflicted when it comes to drivers as it human tendency to code beyond the basics, but XBee might be one of those places where its better to keep it really simply to start with and only have at most a handful of functions to begin with to get it out there and then let the user community direct the next group of required features when ready. GBee and XBeeClient on CodePlex are both really cool and helpful, but I find it hard to believe the user community is complaining given they have two worthy software packages and haven’t gotten involved, which is always my concern about open source, as you can lead a horse to water, but you can’t make him drink sort of thing. I’ll be honest I don’t mind paying more for a module that has supported drivers as I know that software support costs money and its worth something to me.
Bluetooth is somewhat a similar case. I’ve had the joy of dealing with different bluetooth stacks in the past and wondering what was the standard supposed to be and where did it go. So I pretty much expected the same thing with Bluetooth on Gadgeteer.
The Barometer thing is interesting in that it was a working module and it worked well, so what happened? Why did it change as when something works, I really try to avoid breaking it, apparently someone else doesn’t have that rule.
The Git “submodules” feature handles this beautifully. It would be very easy to convert the Gadgeteer project to Git and break out all the modules into their own projects/repositories in CodePlex and still maintain the current source tree in the super project as it is today.
I don’t think it figures this out. I always use Resharper to remove unused references.
That would be a good first step with minimal overall impact, what I’d really like to see, as you suggest, is the individual drivers in nuget, The biggest stumbling block to this at the moment is the visual designer and how it handles showing items in the toolbox and what it does when you drag an item to the design surface and it needs to add references. If you wire everything up in code it would be a doddle.
It would be interesting to have a hack around in the designer and see if it can be made to pull form nuget instead; would need to have a look at how it handles package discovery. Could be an interesting project.
The original driver offered nothing, is my understanding. The current driver offers nothing but a stream to read and write to the serial port. That’s hardly a “driver”. Certainly it isn’t plug-and-play. There was a lot of work done (by two members of the community, though I understand they were “sponsored” with hardware) to create an actual driver, but unless you came to this forum and knew what to search for, you’d never find it.
You say it’s human tendency to “code beyond the basics”, but it’s capitalist tendency (and trust me, I’m a die-hard capitalist) to provide the absolute minimum value that will sell for the highest price.
Bluetooth isn’t a similar case at all. There are no “bluetooth stacks” on NETMF. There is only the stack implemented in the particular board GHI used on the module. There is a very specific way to interact with that board, and the “driver” implements none of it. It offers no interaction whatsoever with the board other than knowing if something paired with it. You said you have no problem paying for a module with a supported driver. In this case, you either did pay or would pay $40 for a module with no way to interact with it.
Guys - lots of meaty stuff on the last few pages of this thread, but maybe it deserves its own topic (or two). Not much in here about measuring air pressure Obviously, a lot of thought has been put into what to do about module drivers by forum members. I hope GHI will tackle this (off) topic, first by listening to our gripes and suggestions, and second by working with us to do something about it. This has caused a lot of frustration and needs to be resolved.
I do not see the need for arguing. My last post said we just finished with major steps and all we are doing now is going back to test and update whatever is needed and we welcome any list of changes and suggestions. I am not pointing this post to any specific reply but only saying we are here to make your experience even better.
I see some comments being too harsh and unfair when you consider everything but I also know you guys love this community and you are all asking for reasonable things, which we are working on.
So, Bluetooth and xbee are on top of the list. We are right on it.
You know (I hope) that you are working with a company that cares very much so you only have to ask. Feel free to even call the office directly and talk to us. We are only here to serve and enjoy being part of this amazing community.
Obviously, a lot of thought has been put into what to do about module drivers by forum members. I hope GHI will tackle this (off) topic, first by listening to our gripes and suggestions, and second by working with us to do something about it. This has caused a lot of frustration and needs to be resolved.