Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Request for change/enhancement


  • Please log in to reply
No replies to this topic

#1 Roy Salisbury

Roy Salisbury

    Advanced Member

  • Members
  • PipPipPip
  • 32 posts

Posted 13 May 2012 - 08:19 PM

What would be real nice would be a few interfaces for the devices (IInputPort, IOutputPort, IInterruptPort, ect)... the more contract based classes there are, the more extensible the drivers for the devices can be. Also, and I know this is more of a NETMF area, but how about making some of the methods for the classes virtual so we wan extend/override some of the behavior.

Here is an example of why I am looking for the interfaces:

Say I want to write a wrapper around a simple LED .. It has one method .. "blink" (turns on, sleep(500), turn off) .. very simple logic. As it is now, the .ctor for the class would usually contain the Netduino Pin number to use and internally it would create an OutputPort and the "blink" method would then do its thing. But lets say I wanted to use a 74HC595 .. I should not have to change my fancy led blink class. But I would have to ... because its using the OutputPort internally. What about if I wanted to use a chained 74HC595? Different code for the led class yet again. I also just write a driver for the MCP23017 (16 I/O expander). Would have been yet another special case. Sure, I could use delegates all over the place (e.g, Blink(Action externalAction)) and not have any real logic in my class .. but that is bad design.

However, if I had a standard contract (i.e, IOutputPort), then I could have just passed that interface into the led blink class, and it would just work. I can implement something like this:

public sealed class MCP23017 {
  public MCP23017(I2CDevice sharedI2C) {}

  public IOutputPort CreateOutputPort(Pin, initialState) {
    var outputPort = new MCP23017_OutputPort(this, pin, initialState);
    outputPort.Initialize();

    return outputPort;
  }

  private sealed class MCP23017_OutputPort {
    // private OutputPort that only the MCP23017 can create.
  }
}

and to use something like this:

I2CDevice sharedI2C = new I2CDevice(...);

using (var mcp23017 = new MCP23017(sharedI2C)) {
  // These might look the same, but they are controlled by different devcies.
  IOutputPort op1 = mcp23017.CreateOutputPort(Pin.GPIO0, false);
  IOutputPort op2 = new OutputPort(PIn.GPIO0, false);

  BlinkeyLed led1 = new BlinkeyLed(op1);
  BlinkeyLed led2 = new BlinkeyLed(op2);

  while (true) {
    led1.Blink();
    led2.Blink();
  }
}

So, much cleaner and less code duplication (which means more program space) .. all for the cost of a few interfaces.

Having said all that, I have already started using this approach in all my code (I wrote a wrapper around the standard OutputPort that I am using where necessary).

Roy




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.