RelayISOx16 - initialization in constructor

Hi,

I am using RelayISOx16 module and I have problem with its initialization. Everytime, when the constructor runs, all relays are turned on for a short time and then turned off. Then everything works fine.

I have found out, that the problem is on the line, where field latch is initialized. So I decided to make some experiments :slight_smile:

Original constructor:


public RelayISOx16(int socketNumber)
{
    Socket socket = Socket.GetSocket(socketNumber, true, this, null);

    socket.EnsureTypeIsSupported('Y', this);

    data = new GTI.DigitalOutput(socket, Socket.Pin.Seven, false, this);
    clock = new GTI.DigitalOutput(socket, Socket.Pin.Nine, false, this);
    // the next line makes the problem
    latch = new GTI.DigitalOutput(socket, Socket.Pin.Five, false, this);
    enable = new GTI.DigitalOutput(socket, Socket.Pin.Three, true, this);
    clear = new GTI.DigitalOutput(socket, Socket.Pin.Four, true, this);
    
    ...
}       

When I changed the constructor, the problem disappeared!
[em](edit: corrected code, was the same as original :frowning: )
[/em]


public RelayISOx16(int socketNumber)
{
    Socket socket = Socket.GetSocket(socketNumber, true, this, null);

    socket.EnsureTypeIsSupported('Y', this);

    data = new GTI.DigitalOutput(socket, Socket.Pin.Seven, false, this);
    clock = new GTI.DigitalOutput(socket, Socket.Pin.Nine, false, this);
    enable = new GTI.DigitalOutput(socket, Socket.Pin.Three, true, this);
    // switched with 'enable'
    latch = new GTI.DigitalOutput(socket, Socket.Pin.Five, false, this);
    clear = new GTI.DigitalOutput(socket, Socket.Pin.Four, true, this);
    
    ...
}

I switched lines where latch and enable fileds are initialized. I have tried that manytimes, and everythnig seems working :slight_smile:

Does the order of fields initialization matter? Is this change allowed?

I also have some proposal of minor changes and additions. Who can I consult that with? Or can I make changes in source control (on codeplex) where someone would approve them before final check in?

Lubos

This isnā€™t initialising fields in a different order, itā€™s initialising the actual pins in a different order, and the initial state of those pins. So it seems to me that by doing what you have, you set enable pin to disable the chip, and then set the latch which would ordinarily trigger the chip to cascade itā€™s ā€œvalueā€ to the outputs. But by disabling it first, itā€™s not doing so. That does seem like a good way of doing it.

As for how to give that feedback and discuss your proposed changes, hereā€™s as good a place as any, but you could add feedback on codeplex as well if you wanted to - Iā€™d expect that the GHI team will look here more often though :slight_smile:

1 Like

Iā€™ve added this to the list of things to examine for the next SDK

1 Like

Also check this thread for a fix without changing any code (post #18):
https://www.ghielectronics.com/community/forum/topic?id=12325

For me itā€™s easier to change a code than to solder a resistor :slight_smile:

The proposed changes will make it in the next release of the SDK. However, issues can still persist, depending on pin states while the firmware is loading the managed code. To properly fix this so it will not be in an on-state, even with out any code controlling it, you will need to add a 10k pull-up resistor between Pin 3 and 5V. Using both solutions results in default off state, with no initialization ā€˜flickerā€™.

The Pull-up should be between pin 3 and 3.3V. The main board processor pins are not 5V tolerant.

I guess heā€™s using Spider so pins are 5V tolerant according to data sheet
(http://www.nxp.com/documents/data_sheet/LPC2478.pdfā€Ž):

5 V tolerant I/O
pins; only valid
when the VDD(3V3)
supply voltage is
present

and values are Min: -0.5, Max: +6.0 V

Yes, you are right. I will have to add a resistor. See whats happening now after a reset mainboard (I have Spider). That didnā€™t happen before, I donā€™t know, what had changedā€¦

So what solution is the correct one? :slight_smile:

Here is a full answer :slight_smile: some gadgeteer mainboards may be 5V tolerant. That said, gadgeteer specification does not allow for 5V on the ins to keep things safe across all mainboard and modules.

So both will work for you but you should use 3.3V.

I think 10k maybe too bug so try 1k if you like.

As Gus stated, after several tests, 1K resistor from 3.3v to Pin 3 solves the problem, sorry for my error :slight_smile:

Thanks. And James, no problem :slight_smile:

Where would be the best place to tap the 3.3V for the pull up resistor to P3? Is there a place from the board? Sorry if this is a dumb question and obvious to all the EEs out there. Also,is there a target date when this will be fixed in the SDK?

all gadgeteer sockets have 3.3v, 5v and ground on the same pins.

https://www.ghielectronics.com/docs/120/gadgeteer-sockets

Thanks!