Gadgeteer Module Driver Beta Suggestion

Archive
1

The Gadgeteer Light discussion this weekend ( http://www.tinyclr.com/forum/21/6726/ ) has me thinking a lot about the process that GHI has been using to develop it’s Gadgeteer modules and some frustrations I’ve been holding back. GHI, of course, has done an outstanding job at designing the hardware for modules but I must admit that I’m less than impressed at many of the driver interfaces that ship with the hardware. For example, do we really need a dozen different methods in the Multicolor LED module that all basically accomplish the same thing? A single SetRgb() could eliminate most of the other methods (I understand that the on-module MCU causes most of this). The Joystick module data is basically useless without always applying some trig… So, why not do it in the driver?

What I would like to see GHI implement is a beta phase for modules where we (the community) can work with GHI to define the software interfaces for modules before they are officially released and you have to start worrying about supporting old APIs. Whatcha think?

2

@ Ian

I think the involvement you are talking about is pre-beta. At the beta stage, work has already been done on implementing the APIs.

Perhaps GHI could expand their peer review of the API specifications to include a few of the community members?

3

I definitely agree, what i would like to see is a more generic Interface for all Drivers… with general/generic methods…

i mean we have limited amount of Sockets, so why not have a driver that is tied to a socket, where the same driver can be used by multiple modules… and the fine tuning of the data can be done by the end user…

For example instead of passing a string type of data back to the end user, the driver could send back an object that the end user can cast to proper type. this way i would have the same driver run the Temp Module the light sensor module and so on, the button module and so on… since all of them give back reading of some sort that could be converted on the end users code instead of the driver… all you would have to include is an example in the driver on how to convert such object to a usable data.

i believe this would save memory and give us more stable driver interfaces, since multiple modules would derive from the same Driver…
i hope my point is clear to understand…

simply replace the word driver in your definition with PLUGIN.

thanks.

4

@ Mike - yes, that’s exactly what I’m talking about. We should have an opportunity to review the APIs before they are “locked in”.

5

@ Jay

I don’t know if I am a supported of generic interfaces. I prefer functional interfaces.

Yes, it would be nice to always Read() a sensor to get the current value, but I would not support having to cast the return to access the specific value.

I think what is important is a consistency to the look and feel of the interfaces.

6

@ Jay - I somewhat agree with you. Every driver should probably have an Interface to the socket that would expose those native values but I expect a Gadgeteer driver to give me methods to use that module in the most efficient way possible. I don’t believe that just receiving raw data is necessarily the answer to this. For example, I was playing with the Joystick module last night. It gives values from 0-1 for X and for Y. This isn’t particularly useful information to me. What would be useful would be a vector value where I can get the direction (in radians or degrees) and magnitude representation of the joystick data. You might not need this same data for other things plugged into an A socket but I almost always need it with a Joystick.

7

That’s exactly my point, all driver should support a Generic Interface that one could use, in addition to the specialized/specific methods per module, in your case for example a method that would return that specific type of data(vectors) plus the RAW/Generic Method should always be there, so that i can use that Raw data in anyway i would please without having to tailor my application to a certain data type…

SO my take on this would be a unified interface per socket number… that all Drivers should support, while adding the specialized methods and property can be an option and be done for specific modules, and again while still providing the Raw data trough the generic interface.

thanks.

8

@ Jay
Im not sure I clearly understand you…
One interface for every module?
Sounds cool for buttons and the joystick, but for more complex modules like the music module or the t35display?

The only implementation of a true generic interface for all modules would end up in getting pin_HIGH and pin_LOW values.

I think a generic interface would be a step back,
because a strongly typed interface does exactly what it has to do.
I want to get an event from the button when its pressed, I dont wanna mess around polling the pin and waiting for it to get HIGH and afterwards LOW.

A generic interface could work, but not for all of the modules we have.
And so it wont be generic…

Just my 2cents :slight_smile:

9

This is why this is open source. We are trying our best to fit most needs but if you need something else then there are 2 options:

  1. take the code and change it anyway you like to fit your needs
  2. community can work on an updated driver and if new driver was to everyone’s liking, we can drop it in as the standard driver.

…or, let us know how you like to see this progress. Just keep in mind that we try to cover most users, from 15 year old kids at schools to professional so the multiple methods you see in the driver are too much for you but maybe they are nice for a 15 year old.

10

@ Gus - I understand but what I’m suggesting is a short (pre-beta) period where you post your proposed interface to us to allow us to have some input before v1.0 is released. We wouldn’t need to see the implementation, just the methods & properties to help provide some guidance on how we think it will be used. The problem with the current approach is that once things are already in place for v1.0, it’s often very hard to change the names or remove redundant methods.

My experience with 15 year olds has been that they can understand almost anything. It’s the older folks I’m more worried about :wink: I’m teaching a Gadgeteer lab to our .NET user group this week and it can be difficult to explain to professional developers why some of the modules have the methods they do and why they have to do so much work to do something useful with some of the data that is returned. It’s a much easier sell if everything is so simple & logical that I don’t have to really explain anything :slight_smile:

11

We almost always release a beta for you guys to try before full release so I am not sure if we need to do something else.

12

Yes, but that’s usually just days before the final release and after you’ve already done all the work of implementing everything. I think people are hesitant to suggest these types of changes at that point. I’m talking about adding a step early in your development cycle.

13

I think we have drifted off into the subject of system development life cycle(SDLC).

In a formal SDLC, when developing an API, one of the early steps is to specify the external methods and properties to be exposed, and have a peer review before any coding is started. This almost always results in a much better product.

Usually, this review is done internally, but sometimes it includes key customers or other persons who could add significant value. I have never heard of such a review being open to the whole customer base. Too many cooks. :smiley:

Getting external input to GHI internal SDLC would be additional overhead and increased time to market. At this stage of GHI evolution, the concept of external input may not fit.

14

@ ianlee

You’re talking about the difference between an Open Source Project and Open Source Software. Phil Haack had a couple good posts on that:

and

Those are his terms, but I happen to like them.

What you’d like to see is the development done in the open, IOW, an “Open Source Project” as opposed to v1 going out along with its source code with the rights conveyed as Open Source Software.

The former is, IMHO, superior in its end result, but would require more effort from GHI to manage, and more time to solicit and incorporate suggestions.

Pete

15

FWIW, Just about any major true Open Source Project works that way.

Also, Firefox is developed that way. Here’s a short interview with my former direct report Joe Stagner:
http://jesseliberty.com/2012/04/04/yet-another-podcast-62joe-stagner/

Pete

16

@ Pete - exactly. Reading that article last night was a big factor in me deciding to start this post.

I really don’t think it would take that much. When GHI starts thinking about designing a module driver all they would have to do is:

  1. Discuss internally and decide on their best ideas.
  2. Post those ideas to a thread.
  3. Wait a week while the community fights about what’s best…
  4. GHI reads over our ideas and incorporates what they consider the best ideas.

An example… I’m working on a demo right now using a LED7R as a meter. To accomplish this I have to write this [IMO nasty] code:


            for (var ndx = 1; ndx < 7; ndx++)
            {
                if (ndx <= lightLevel/100.0*7)
                {
                    led.TurnLightOn(ndx);
                }
                else
                {
                    led.TurnLightOff(ndx);   
                }                
            }

I’d be willing to bet that this process would have resulted in the replacement of TurnLightOn() & TurnLightOff() with SetLedState() or maybe just a LED property so that the following could be written instead:


            for (var ndx = 1; ndx < 7; ndx++)
            {
                led.SetLedState(ndx <= lightLevel/100.0*7);
            }

My objective here is not to criticize GHI’s software but only to offer suggestions for improving the quality of the product. Obsessive continuous improvement is something I’m cursed with…

17

Oh, so now I’m the trouble-maker.

Just playing devil’s advocate here, but this:

Is what I was talking about. I’m guessing, but I suspect GHI does a lot of rapid development of drivers once hardware is out.

I’m not saying that’s a great reason not to do it, just that is is a reason :slight_smile:

Pete

18

:smiley: “Guns don’t kill people. Crazy people with guns kill people…”

19

Heck, I’d be happy if there was simply a way to track issues, suggestions, and releases. Right now it feels like threads come and go with great suggestions, or issues crop up, and who knows whether or if changes got implemented, and when.

It would also give potential contributors something solid to go on if they’re looking for something to do.

20

@ godefroi +1