11 replies to this topic

[JoRu1407]

Hello guys, I have a question regarding my Netduino Plus and an C# App: How can I define all 14 digital I/O pins of my Netduino as OutputPort variables without creating 14 single variables. Is there any possibility to define this with a loop or so what? Many thanks in advance. JoRu1407

[ashishmgupta]

I am very new to Netduino. However, I just wonder why you need separate variables for those pins. Those are actually C# constants which means they are directly baked into SecretLabs.NETMF.Hardware.NetduinoPlus.dll and therefore can be used directly in the code where ever you need to use them. using Microsoft.SPOT.Hardware; using System; namespace SecretLabs.NETMF.Hardware.NetduinoPlus { public static class Pins { public const Cpu.Pin GPIO_NONE = -1; public const Cpu.Pin GPIO_PIN_A0 = 59; public const Cpu.Pin GPIO_PIN_A1 = 60; public const Cpu.Pin GPIO_PIN_A2 = 61; public const Cpu.Pin GPIO_PIN_A3 = 62; public const Cpu.Pin GPIO_PIN_A4 = 10; public const Cpu.Pin GPIO_PIN_A5 = 11; public const Cpu.Pin GPIO_PIN_D0 = 27; public const Cpu.Pin GPIO_PIN_D1 = 28; public const Cpu.Pin GPIO_PIN_D10 = 54; public const Cpu.Pin GPIO_PIN_D11 = 17; public const Cpu.Pin GPIO_PIN_D12 = 16; public const Cpu.Pin GPIO_PIN_D13 = 18; public const Cpu.Pin GPIO_PIN_D2 = 0; public const Cpu.Pin GPIO_PIN_D3 = 1; public const Cpu.Pin GPIO_PIN_D4 = 12; public const Cpu.Pin GPIO_PIN_D5 = 51; public const Cpu.Pin GPIO_PIN_D6 = 52; public const Cpu.Pin GPIO_PIN_D7 = 3; public const Cpu.Pin GPIO_PIN_D8 = 4; public const Cpu.Pin GPIO_PIN_D9 = 53; public const Cpu.Pin ONBOARD_LED = 55; public const Cpu.Pin ONBOARD_SW1 = 29; } }

[hanzibal]

You could try something like below.

Beware: The code is "pseudo code" from the top of my head so it won't compile as is but I think you get the general idea.

// create a 14 element array of outbound digital ports
var ports = new  OutputPort[14] 
{
    new OutputPort(PIN.GPIO0),
    new OutputPort(PIN.GPIO1),
    new OutputPort(PIN.GPIO2),
    .
    .
    .
    new OutputPort(PIN.GPIO13)
}

// example of how to use the port array
for(int i = 0; i < ports.Length; i++)
    ports[i].Write(true);

The snippet above is for OutputPort objects only so if you want to mix analogue, digital in various directions you need to find a base class that is common for these port types. If such a base class does not exist, you can always create an array with elements of type System.object but then you would have to cast the elements whenever you need to use them as actual ports of each type respectively.

Anyway, hope this helps you some. Goodl luck!

[JoRu1407]

Thank you, Hanzibal. But is there no way, to save these many individual new assignements?

[hanzibal]

Hi!

I'm not sure how you mean, maybe I misinterpreted you initial question?

The pseudo code I wrote earlier will create fourteen new instances of the OutputPort class which are configured to use each of the fourteen pins respectively (you have to modify the GPIO0 through GPIO13 enums to their actual names). The ports are then stored in a fourteen element array which you can use to access any of the ports as shown in the example for-loop.

If you wan't to use the 14 ports from anywhere across your application you can create a static variable in your Program class like so:

public static OutputPort[] ports = new OutputPort[14] 
{
    new OutputPort(PIN.GPIO0),
    new OutputPort(PIN.GPIO1),
    new OutputPort(PIN.GPIO2),
    .
    .
    .
    new OutputPort(PIN.GPIO13)
}

[Stanislav Husár]

But is there no way, to save these many individual new assignements?

You can store pin assigments to an array of type Cpu.Pin in the same way, as Hanzibal stored OutputPort objects to array. In the code below, I stored pin assigments and initial states to two arrays, and initialized ports in for cycle.

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;

namespace NetduinoPlusApplication1
{
    public class Program
    {
        static const Cpu.Pin[] pinAssigments = new Cpu.Pin[] {Pins.GPIO_PIN_D0,Pins.GPIO_PIN_D1,Pins.GPIO_PIN_D2,Pins.GPIO_PIN_D3 };
        static const bool initialState = new bool[]{false,false,true,true};
        static const OutputPort[] pins;
        public static void Main()
        {
            pins = new OutputPort[pinAssigments.Length];
            for(int x = 0;x < pins.Length;x++)
                pins[x] = new OutputPort(pinAssigments[x],initialState[x]);

        }

    }
}

[nakchak]

Why wouldn't you want to define 14 variables?

I havnt looked very closely at the garbabge collector code in netmf, but i suspect that you would get better performance from 14 static readonly objects rather than an array or other collection. If nothing else your code would be more readable and easier to debug. Especially if you start getting out of memory errors as you will probably find that the index of the array changes each time you encounter such an error, also you have to take into account the overhead of a static array, index variables and 14 outputport objects, (which are not static) vs 14 static objects.

Personally i would just declare all 14 as follows:

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;

namespace NetduinoPlusApplication2 {
	public class Program {

    	private const bool InitialState = false;
    	private static readonly OutputPort Output01 = new OutputPort(Pins.GPIO_PIN_D0, InitialState);
    	private static readonly OutputPort Output02 = new OutputPort(Pins.GPIO_PIN_D1, InitialState);
    	private static readonly OutputPort Output03 = new OutputPort(Pins.GPIO_PIN_D2, InitialState);
    	private static readonly OutputPort Output04 = new OutputPort(Pins.GPIO_PIN_D3, InitialState);
    	private static readonly OutputPort Output05 = new OutputPort(Pins.GPIO_PIN_D4, InitialState);
    	private static readonly OutputPort Output06 = new OutputPort(Pins.GPIO_PIN_D5, InitialState);
    	private static readonly OutputPort Output07 = new OutputPort(Pins.GPIO_PIN_D6, InitialState);
    	private static readonly OutputPort Output08 = new OutputPort(Pins.GPIO_PIN_D7, InitialState);
    	private static readonly OutputPort Output09 = new OutputPort(Pins.GPIO_PIN_D8, InitialState);
    	private static readonly OutputPort Output10 = new OutputPort(Pins.GPIO_PIN_D9, InitialState);
    	private static readonly OutputPort Output11 = new OutputPort(Pins.GPIO_PIN_D10, InitialState);
    	private static readonly OutputPort Output12 = new OutputPort(Pins.GPIO_PIN_D11, InitialState);
    	private static readonly OutputPort Output13 = new OutputPort(Pins.GPIO_PIN_D12, InitialState);
    	private static readonly OutputPort Output14 = new OutputPort(Pins.GPIO_PIN_D13, InitialState);

    	public static void Main() {
        	Output01.Write(true);
    	}

	}
}

Nak.

[Coyttl]

Why wouldn't you want to define 14 variables?

I havnt looked very closely at the garbabge collector code in netmf, but i suspect that you would get better performance from 14 static readonly objects rather than an array or other collection.
Nak.

I believe that it's just personal preference - I don't think any memory savings (if any?) would be that great between an array and 14 individual variables.

(Be an interesting test, however. I may try that out later today, if I get bored working on the house..!)

-Mike.

[hanzibal]

I believe that it's just personal preference - I don't think any memory savings (if any?) would be that great between an array and 14 individual variables.

I don't think so either and in general I like to wait with sub-optimizations until I know of it's necessity.

Personally, I'm not at all obsessive about memory overhead (not saying that you guys are) and frankly, I've never even used the IDisposable pattern and still haven't run into any memory issues in any of my projects. Naturally, memory considerations depend on the nature of the application but I think in general, if you're only looking to create a "proof of concept" kind of application, I'd save memory consideration for the "production model"

In fact, I'd even use a Dictionary object to map the Cpu.Pins.xxx enums to each instance of the corresponding OutputPort. But that's just me.

[nakchak]

There is a lot of personal preference when it comes to these sort of things, the day job dictates that i have quite a rigid coding standard to work to, and readability for me is the #1 consideration. As for proof of concept vs production standard i learnt the hard way a long time ago that its better to treat everything as production as you would be amazed of the number of QDF's (Quick Dirty Fixes) that become production systems and then become a nightmare to maintain... (you can only refactor bad design so much/apply lipstick to a pig). Obviously i am somewhat biased to my way of thinking, but i would like to stress this is not a case of good vs bad, or right and wrong, all ways described so far have their pro's and cons. For me readability is vital as i dont want to spend hours 6 months down the line trying to remember how something works... Nak.

[JoRu1407]

Thank you for the answers. Of course it is just a personal reference, but it does no matter to create 14 vars - So I will do that...

[hanzibal]

There is a lot of personal preference when it comes to these sort of things, the day job dictates that i have quite a rigid coding standard to work to, and readability for me is the #1 consideration.

As for proof of concept vs production standard i learnt the hard way a long time ago that its better to treat everything as production as you would be amazed of the number of QDF's (Quick Dirty Fixes) that become production systems and then become a nightmare to maintain... (you can only refactor bad design so much/apply lipstick to a pig).

Obviously i am somewhat biased to my way of thinking, but i would like to stress this is not a case of good vs bad, or right and wrong, all ways described so far have their pro's and cons. For me readability is vital as i dont want to spend hours 6 months down the line trying to remember how something works...

You are of course right but you're a professional while I am but a simple hobbyist

but it does no matter to create 14 vars - So I will do that...

So basically, we're back where we started