Cerberus + RelayISOx16

OK, it is logic :wall:

@ LouisCpro - yes i can see that, but i was also under the impression that they still dont work on 5 and 6ā€¦

@ nicholas.goodman - Does it actually work on 5 & 6?

@ SENSEI as well: Is there anything in your application that uses SPI, even if it is not associated to these sockets? All of the tests we have run to help solve this issue, have been conducted on sockets 5 and 6 (Which is where we discovered the socket labeling bug).

It was not, but as nicolas has fixed the xml, it should !

It does not work on 5 and 6.

The board functions for about 2 seconds and then locks up as reported by the OP. Most of the red LEDs stay on (except for a few in the middle).

@ nicholas.goodman - Interesting - and your using Non - Ethernet firmware?

@ James - I think i can pretty much confirm having multiple SPI is buggy from the stuff i have been doingā€¦
And i think worse on Ethernet firmwareā€¦

That is correct. I have non-ethernet, meanwhile Sensei has ethernet firmware, I believe.

the code I see isnā€™t using spi, itā€™s bit banging the pins

So Iā€™d be really suprised it its SPI related

Iā€™d guess timingā€¦
Or HW

at my side, i have ethernet firmware and i confirm that after having modified the xml file to specifiy socket type Y instead of S, the relay board works as expected initially on socket 2 for example on the Cerberus motherboardā€¦

We can confirm that while using the Ethernet Firmware while the RelayISOx16 is on socket 5 results in the same pattern and behavior as you describe. We are investigating the possible cause of this issue.

1 Like

This is not a problem, we are talking about sockets 5 and 6 right? Those share signals. Please see the note on the image here ā€œshared signalsā€ http://www.ghielectronics.com/catalog/product/349

When using socket 5 (or 6) then you have to consider what goes on the other socket. What surprised me here is that you did not get an exception. We will look into this.

To make this simple, you can use S (SPI) on both sockets simultaneously but if you are not using S then these sockets become X type for one and Y for another. This was required to expose 2 SPI sockets.

1 Like

I do not quite understand the solution here. I have tried to edit the GadgeteerHardware.xml file which did open up other ports but didnā€™t work for me. Still heard the clac and then froze.

Original GadgeteerHardware.xml file


      <Sockets>
        <!-- This example socket is compatible with socket type S, and it has electrical connections to pins 3,4,5,7,8,9, with 7,8,9 being shareable (SPI bus) -->
        <Socket Left="70" Top="49" Orientation="180" ConstructorOrder="1" TypesLabel="Y">
          <Types>
            <Type>S</Type>
          </Types>
          <Pins>
            <Pin Shared="false">3</Pin>
            <Pin Shared="false">4</Pin>
            <Pin Shared="false">5</Pin>
            <Pin Shared="true">7</Pin>
            <Pin Shared="true">8</Pin>
            <Pin Shared="true">9</Pin>
          </Pins>
        </Socket>
      </Sockets>

Updated GadgeteerHardware.xml file


      <Sockets>
        <!-- This example socket is compatible with socket type S, and it has electrical connections to pins 3,4,5,7,8,9, with 7,8,9 being shareable (SPI bus) -->
        <Socket Left="70" Top="49" Orientation="180" ConstructorOrder="1" TypesLabel="Y">
          <Types>
            <Type>Y</Type>
          </Types>
          <Pins>
            <Pin Shared="false">3</Pin>
            <Pin Shared="false">4</Pin>
            <Pin Shared="false">5</Pin>
            <Pin Shared="true">7</Pin>
            <Pin Shared="true">8</Pin>
            <Pin Shared="true">9</Pin>
          </Pins>
        </Socket>
      </Sockets>

Any help in getting this working and resolved will be greatly appreciated.