Pin and Gadgeteer

Archive
1

Hi, may be someone can clarify how to use Cpu.Pin and GT.socket.CpuPins[] calls.

I need to write a simple driver that is not gadgeteer only, so in the driver constructor:


...
        public Driver74HC595(Cpu.Pin _pin_CK, Cpu.Pin _pin_SI, Cpu.Pin _pin_RK)
        {
            pin_CK = _pin_CK;
            pin_SI = _pin_SI;
            pin_RK = _pin_RK;
        }


        public void SendData(byte b)
        {
            byte btemp = b;
            int i = 0;
            OutputPort o_pin_CK = new OutputPort(pin_CK, false); // <=== I get exception here
            OutputPort o_pin_SI = new OutputPort(pin_SI, false);
            OutputPort o_pin_RK = new OutputPort(pin_RK, false);
...

// in the main thread :

GT.Socket sock = GT.Socket.GetSocket(6, false, null, null);

Driver74HC595 sr = new Driver74HC595( sock.CpuPins[5], sock.CpuPins[4], sock.CpuPins[3]);
...

Exception is:


 #### Exception System.Exception - CLR_E_PIN_UNAVAILABLE (3) ####

This happen on the FEZ Hydra. I’ve not checked other board.
Thanks

2

Did you connect anything to that socket in the designer by any chance?

3

Ahhh, ok, sorry I forgot to mention that on the socket 6 it’s plugged an extender board. I’ve tried with and without extender in the designer with same result.
In any case I changed the driver now, sending socket number (6) in the constructor:

        
        public Driver74HC595(int numsocket)
        {
            socket = GT.Socket.GetSocket(6, false, null, null);
            
            pin_CK = new DigitalOutput(socket, GT.Socket.Pin.Five, false, null);
            pin_SI = new DigitalOutput(socket, GT.Socket.Pin.Four, false, null);
            pin_RK = new DigitalOutput(socket, GT.Socket.Pin.Three, false, null);
        }

In this way it works.
But I was trying to make the driver not Gadgeteer dependent.
I’m working on a very easy relay board (4 or 8 ) using only a 74hc595 + ULN2003 ics, with separate power supply for relay coils (5V or 12V).

4

When dual targeting, you’ll need to do some conditional compilation at a minimum. The setup code won’t work identically across NETMF devices.

I refactor the common code out into a shared class, and then have my Gadgeteer driver and other drivers all delegate to that. Example is the latest checkin at http://petebrown.codeplex.com (although I use uart, not pins)

Pete

5

But I’m a bit worried due to the fact that I/O pin seems not mapping correctly between gadgeteer mboard chip and sockets.
But if I need to use OutputCompare or other pin related functions, how I can do that ?
I was thinking that Socket.CpuPin[x] would map to a Cpu.Pin correctly…

6

@ dobova

Things like outputcompare differ even between Gadgeteer implementations as I recall.

The pin model is different between Gadgeteer and base NETMF. IMHO, you’ll need to branch your code between the two.

Gadgeteer also does some interesting pin mapping/reserving so I don’t think you can say anything is exactly 1:1. That’s part of its strength, but it does make it a little more challenging to share code.

Pete

7

What do you mean exactly? Isn’t Gadgeteer just adding a layer of abstraction and for the pins it provides a factory pattern? At the end regardless of running on Gadgeteer board or regular NET MF you end up with an Cpu.Pin enum that points to your pin. Then you can initialize OutputCompare for example. Am I missing something?

8

@ Gralin
That’s exactly what I was meaning, but I miss something probably.
In any case my problem could be related to reservation of pins made by gadgeteer layer.

9

Take a look at socket.cs…
The reservation happens there with no way of releasing the pins. I’ve complained about this and not sure if my claim was heard,
We need a way to release the pins when the class is garbage collected …

Just saying…