I/O connector advice

[ilium007]

Hi - I’m building a 128 input / output board based on 8 x MCP23017 IC’s. I’m having a hard time coming up with solutions for I/O connectors.

I looked at Molex KK 254 / 356 for the 2 pin power input, and Molex KK 254 for the 4 pin I2C input from another board that will have the Teensy 3.6 mounted. I don’t think the single row KK series will work for 128 connections due to board realestate, I think I will need 2 row connectors.

Each MCP23017 has 2 banks of 8 x I/O. I plan on building seperate 16 output relay daughter boards (due to the board size consumed by the relays) that will need to be connected. The 128 I/O main board will run on 5v (standardising on 5v for everything except the 3.3v Teensy board) and I’m not sure if I need to pass on the 5v and GND alongside the 16 outputs for each daughter board. All daughter boards will run off the same 5v DC power supply, if I don’t need to pass power and ground I can just use a 16 pin header (vs. an 18 pin connector) and connect the daughter boards via IDC ribbon cables. I assume given all boards will have the same GND that a signal, high or low, from the MCP23017 on the main board will still be referenced from the same GND and will work as if on the same board.

The relay boards I’m building will use 16 x N-channel 2N7002 MOSFETs to drive 16 x 5v coil relays. I’m not going to be able to supply enough current on an IDC ribbon cable 5v / GND wire to run 16 of the FET’s and 16 relay coils come currently - a conservative estimate is in the vicinity of 1A per 16 channel relay board.

Does anyone have any other ideas for this amount of I/O from one board ?

I need to figure this out before I start placing components on the PCB design.

[tszaboo]

DIN 41612
Comes in all sizes, for cable, right angle, stacking connector, half size, third size, whatever. Once you used it for connecting boards, you just know, this is the way boards should be connected together.

[ilium007]

DIN 41612
Comes in all sizes, for cable, right angle, stacking connector, half size, third size, whatever. Once you used it for connecting boards, you just know, this is the way boards should be connected together.

Looking now ! This is exactly the advice I am after, I’ve never built something large scale like this so any advice is welcomed.

[ilium007]

The DIN 41612 connector looks solid but $3 - $8 each in Australia they are well out of my price range.

[dmills]

You would pay that for an equivalent number of ways of almost anything else (96 pins is commonplace on 41612).

The thing about 41612 style connectors is that the common ones are cheap, and the uncommon expensive, make sure you are using a common one.

I would suggest the 2mm "Hard Metric" connectors as an alternative, you could easily get all your IO on one connector.

However, WHY are you putting the 23017s on the main board? Stick them on the relay boards and set a different address for each board, then you can just loop a 10 pin ribbon or such along the back of all the relay cards on IDC connectors and box headers, much cleaner.

Regards, Dan.

[ilium007]

I originally contemplated having an MCP23017 on each board but I was advised that the multiple I2C connections would lead to capacitance / reliability issues having the I2C cables running out / daisy chained to the 8 seperate boards.

If this isn’t an issue (boards will all be pretty close together - within 10cm) I would rather build them seperate.

[dmills]

I would run SPI rather then I2C (You can still use the chip addressing stuff on those parts, but see the errata for details of a silicon bug), just because I2C is in general general pain in the arse, costs an extra IO pin but it is IMHO worth it.

For relay drivers I would also see if something that would reduce your parts count was available, maybe a MIC5841 or similar, gets you the relay drive transistors and catch diodes in a single package that can just be daisy chained from board to board, note that this would require a series connection of the data line so it may or may not be a win over addressable parts with an IDC bus connection.

Over 8 inches at low data rate I2C would in fact probably be fine, with stiff pullups, I just hate having to write the state machine.   

Regards, Dan.

[ilium007]

State machine ?

From what I had read, SPI would have been even worse over any sort of distance.

[CM800]

What datarate & latancy is required?

You could always do SPI through differential line drivers, or use some other bus, CANBUS is good for some 1MBAUD

[ilium007]

Extremely low data rate requirement. I am building a controller for a large model train layout. Approx 50 input switches, 35 solenoids to drive relays, 50 indicator LEDs and a few more bits and pieces. Lots of low speed I/O.

[dmills]

SPI is generally **MUCH** better over distance because it is actively driven both high and low, there is far less of an issue with capacitive loading. Because the bus is not a weird open collector thing you can series terminate at the transmitter and user schmitt triggers at the receivers, and it will generally just work (There is an annoying gotcha in that which clock edge things sample on is not that well defined, so you sometimes have to think a bit when setting up the micro). 

I2C is so painfully slow that if you have any sort of fast processing to do you sometimes find yourself writing hideously complex interrupt driven state machines to handle the transitions from start -> address->ack->cmd->ack-> (sometimes) repeated start->address->ack->data->ack->stop, easy to write one that is not reliable, surprisingly tough to write something that really works reliably (And that is before you get some part that gets confused and locks the bus).

Personally I try very hard to stay away from I2C for any but the most trivial of purposes. 

[ilium007]

SPI is generally **MUCH** better over distance because it is actively driven both high and low, there is far less of an issue with capacitive loading. Because the bus is not a weird open collector thing you can series terminate at the transmitter and user schmitt triggers at the receivers, and it will generally just work (There is an annoying gotcha in that which clock edge things sample on is not that well defined, so you sometimes have to think a bit when setting up the micro). 

I2C is so painfully slow that if you have any sort of fast processing to do you sometimes find yourself writing hideously complex interrupt driven state machines to handle the transitions from start -> address->ack->cmd->ack-> (sometimes) repeated start->address->ack->data->ack->stop, easy to write one that is not reliable, surprisingly tough to write something that really works reliably (And that is before you get some part that gets confused and locks the bus).

Personally I try very hard to stay away from I2C for any but the most trivial of purposes.

Ok. Thanks for the heads up. Back to the drawing board 

[Ian.M]

It all depends on the I2C bus speed - the slower you run it, the more capacitance it can tolerate.  However the I2C bus is vulnerable to noise pickup, and the MCP23017 has a bit of a reputation for being buggy, so personally, I'd stay *FAR* away from it.   

Look at the TPIC6C595 SPI compatible 8 bit shift register with power open drain outputs that can drive most relays directly.   Buffer SRCK and RCK on each relay board, and you could daisy chain them ad-nauseum - just put a 4 pin right angle header on each end of the board for signals and ground, one male, the other female, and a pair of PCB mounted 1/4" spade lugs for power and ground to hook up a crimped daisy chain power and ground backbone cables to so you don't get excessive voltage drop.  N.B. there would be a considerable advantage in using a higher voltage for the relay coils - 12V relays would reduce the worst case current by a factor of about 2.4.

If you want to be able to do long runs between boards, consider putting local intelligence on each relay board (or cluster of relay boards) and using RS485 line drivers and the MODBUS protocol, then you can setup a multi-drop bus over readily available twisted pair cable and power them over the same cable. e.g  if you use Ethernet cable, with one pair for data, and three pairs for power/ground, you can deliver 1A to remote boards with no issues.  Local regulation at the remote board is strongly recommended.

[dmills]

I have used a lot of the MCP23S017 (The SPI version) without encountering much trouble with them, but they seem rather overkill for relay drivers when you can do the whole thing in a single package (including high current drive and catch diodes), and if the fora are to be believed the I2C version seems to have a few issues (Always a bit had to tell how much of that is finger trouble on the programmers part).


The '595 workalikes have the virtue of simplicity and are almost idiot proof.

Regards, Dan.

[Leo Bodnar]

If you still have the choice, don't use MCP23017.  They and their cousin MCP23S17 are one of the worst MC products out there.  Just say no if you can.
Leo

[dmills]

I have not had bad luck with the MCP23S17, once I found the errata dealing with that addressing issue, they seem to do what they say on the tin.
What is the problem with them?

They are overkill for this, but in the right place they seem to me to do ok.

Regards, Dan.

[Leo Bodnar]

I have not had bad luck with the MCP23S17, once I found the errata dealing with that addressing issue, they seem to do what they say on the tin.

How many have you used?
Leo

[dmills]

They are in one of my employers audio monitoring products, so we probably have a few thousand in the field by now.

We had a problem with a poor choice of connector, but these things (which are used to read incremental encoders) seem to do fine.

Regards, Dan.

[Leo Bodnar]

They are in one of my employers audio monitoring products, so we probably have a few thousand in the field by now.
We had a problem with a poor choice of connector, but these things (which are used to read incremental encoders) seem to do fine.

Hopefully it stays that way. These things are prone to latching up and burning out.  I'd never use them anywhere close to long wires, connectors or high current again.
Leo

[dmills]

No high currents, no long wires, and the connector problem was a gold on one half and tin on the other sort of screwup.
As I say we have seen no issues with the SPI version, but they are overly complex for the OPs needs.

I do not claim they are the best thing ever, and would actually rather have gone for an NXP io expander, but we had this thing designed into an existing product, and it is usually better to pick something that is already in use.

Regards, Dan.

[Siwastaja]

Hopefully it stays that way. These things are prone to latching up and burning out.  I'd never use them anywhere close to long wires, connectors or high current again.
Leo

I'm a bit confused - did I miss something glancing the datasheet earlier? It looks like a standard 5V logic part, without any specially robustly specified structures in inputs or outputs whatsoever. What made you think you could think in terms of "long wires", "high currents" or "connectors"? 25mA is absolute maximum rating of the output pins. I'd use proper line drivers, isolation, gate driver, or whatever required by the application. Do you think these parts are more prone to failure than, say, unprotected "standard" microcontroller IO or 74HC logic parts? Are you sure you didn't abuse the parts, expecting something they are not supposed to do in the first place?

[mariush]

May want to consider if ethernet ports and ethernet cable would be something suitable for your needs. You have 8 contacts in a very narrow connector.
They're made in huge quantities,so they should be cheap in volume and you can also use ready made ethernet patch cables,  even flat ones if you need to... and these are also available in various lengths right from the factory. 
The regular ethernet cables has twisted pairs so i suppose SPI signals should be relatively safe through the cable... and you could probably even use FTP cable or shielded utp cable to insulate the whole cable from outside noise.

Other than ethernet, you should look at JST's catalogue, and see if you can find some 2.0mm pitch connectors with good locking/retention mechanism which would be also cheap for you. 2mm should still be easy to solder (manually) on a circuit board and maybe route a trace between two pins if needed 

[ogden]

I'm a bit confused - did I miss something glancing the datasheet earlier? It looks like a standard 5V logic part, without any specially robustly specified structures in inputs or outputs whatsoever. What made you think you could think in terms of "long wires", "high currents" or "connectors"? 25mA is absolute maximum rating of the output pins.

Take everything in public forums where anyone can tell anything - with gain of salt

[tszaboo]

Hopefully it stays that way. These things are prone to latching up and burning out.  I'd never use them anywhere close to long wires, connectors or high current again.
Leo

I'm a bit confused - did I miss something glancing the datasheet earlier? It looks like a standard 5V logic part, without any specially robustly specified structures in inputs or outputs whatsoever. What made you think you could think in terms of "long wires", "high currents" or "connectors"? 25mA is absolute maximum rating of the output pins. I'd use proper line drivers, isolation, gate driver, or whatever required by the application. Do you think these parts are more prone to failure than, say, unprotected "standard" microcontroller IO or 74HC logic parts? Are you sure you didn't abuse the parts, expecting something they are not supposed to do in the first place?

Yeah, they are pretty much a PIC16+program. SPI is not designed to go through cables, nor I2C. If you know how to use the interfaces, and ASICs there are very few problems with these. For example the SPI @10 MHz is about 100MHz BW for the signals. So did you do the same precautions as ethernet? Do you have controlled impedance, twisted cable, differential signaling, proper grounding, ways to handle propagation delays? No? Then do you even expect it to work properly?

[ilium007]

Thanks for the feedback. Wow...

** I am starting another thread to discuss this new approach as this is now off topic **