I think we are at the point where it would be helpful to have some common interfaces for some of the FEZ software components. We have several motor shield drivers and different joysticks, and a pile of different temperature sensors, and so on. I think a common motor driver interface class would be a great thing and everyone who implements a new motor driver shield / temp sensor / etc. implements to that interface (when appropriate). That way, when we change our project from a 1 amp motor driver to a 25 amp motor driver, we have a common interface and don’t have any code changes.
SO, maybe Fezzer.com could add a category for Interface (in addition to Driver, Snippet, Extension, etc.). I think it could make code development even easier.
Of course, this is only where appropriate - we don’t want to bend a device to artificially fit an interface that doesn’t make sense.
That’s a very good idea! Something like the interface for the distance sensors. You select the distance sensor in code and up you go. If I attach a different one, I change the type of sensor and I am done. ;D
Interesting, Bec suggested starting on common interfaces a few months ago and got roasted. Everyone thought it would be waaayyyy to complicated for the newbie. Interesting to see that as folks have gotten a bit more experience under their belts how attitudes have changed.
I think a st of common interfaces would be great. I can think of the following real quick:
[ol]
Character LCD
Hobby servo
Small graphic LCD
[/ol]
He did not get Roasted. The same issues will come up. The one difference here is its not blantly stated that we will not work with anything that doesn’t fit our interface which was stated last time. So if I write a motor driver for a the adafruit motor shield but don’t use Go and the the call to make the motor move it gets ignored. Let alone tell a new guy how to write his code to the interface. Even deciding what goes into the interface. All those problems still exist. All of them will have to be solved or worked on. The project was to move forward last time. Not sure why it did not.
Perhaps like most “open source” “collaborative” efforts, it often fizzles or booms based on the enthusiasm of the collective. There was obviously not much enthusiasm before exept from Bec’s side.
But as bstag says, the same issues will come up for sure. Good luck to anyone who takes this further.
I don’t think we have to have a lot of issues because we don’t need any enforcement or standards. I think this can be entirely cooperative. Maybe like this:
[ol]A guy writes a motor driver and defines an interface[/ol]
[ol]Another guy writes a motor driver and chooses to use the same interface[/ol]
[ol]Some guy decides he wants an extended interface and he publishes it.[/ol]
[ol]The other guys decide they like the new extensions and they update their drivers[/ol]
[ol]Another guy doesn’t know about the interface or does like it or it doesn’t fit, so he does what he wants to[/ol]
I think it can be cooperative rather than “collective”. Really, it will be lots of fun and probably a little messy and lots of fun and really valuable.
yes, sure, of course it can work. The benefit is that everyone can get an “extensible” approach; the challenge is in either getting the collaborative quality (perhaps also quantity) to do a good design to start, or in getting agreement on the approach. In the LCD example PRINT vs WRITE are good “topis for healthy discussion”
Fezzer is now a great place to put some of this collaboration although there may be reasons to move to a more structured collaboration environment (like codeplex) once this progresses to something like the GPS toolkit Chris and Mark and others worked on for their navigation projects.
As I said, good luck to anyone who takes this further.
Very good idea. Maybe the trick here is not to try and standardize by committee but get standard interfaces through adoption. The interface with the most “fans” wins… It will be very nice to have like a voting system or just an indicator of usage on interfaces and libraries on Fezzer. Imagine being the author of the most widely used interface on .Net Micro Framework. That’s something I can aspire to
Maybe this is also the chance for the hobby community to show the commercial lot how to do it. Corporates don’t really benefit from having their stuff replacable by something else with no code change. For us however we want to be able to plug things in and out. Maybe we can drive our own standards.
I did a project a while back where I flirted with this idea. I started by saying most of my peripherals derive from either Sensor or Actuator. Actuator starts with something simple like On/Off and progresses to something complicated parameters like Speed and RampTime etc. The point is however that most things have origins in simple and common foundations and those make great interfaces.
For example, a high-end CNC-type servo that shares foundations (interfaces and inheritance) with a simple RC servo:
That’s a good thread. The idea is the same, the people different - so maybe all it takes is one to start the movement
I realise interfaces are “contracts” and it makes maintenance easier etc. etc. but it sounds like “rules”. Maybe we should however look at the benefits to the hobbyist as opposed to the “professional developer”.
For example, I would get great value from an interface from a learning perspective. You can capture years of experience into a well thought-out interface without implementing a line of code.
If someone with great experience on a topic - say Motion Control or GPS functions or LCD display - creates an interface, someone else can then do an implementation against a well defined structure using any hardware of their choice. The interface is a guide on what the widget does, not how it does it. The thrill of implementing it your own way is still there, but a lot of thinking (and headaches) will be spared by the interface.
For example, I just Googled “Motion Control API” and found a site with an API with over 100 functions. Now I never thought motion control could be that involved - because I’m a hobbyist in that field. The point is, with an interface with 100 possible functions, it is a great starting point for me to implement the bits I really need - and may need in future too.
To illustrate what I’m talking about… Consider the first method you’d think belongs in a IMotionControl interface: Move(x,y). What about (x,y,z) and are those of type int, uint, float or what? What about MoveRelative? An expert interface will very quickly teach you those things and leave you to go implement it the way you want.
If nothing else, a good interface can at least let you claim “a best practice implementation”.
@ realizer, that is a really good point. When working with junior or even senior engineers, we often start by having me define the interface to the component. They can fill in the details, but it takes experience to start well. Everyone benefits from a good start.
