Author Topic: I/O connector advice  (Read 6402 times)

0 Members and 1 Guest are viewing this topic.

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
I/O connector advice
« on: November 20, 2017, 09:56:49 am »
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.
« Last Edit: November 20, 2017, 10:32:45 am by ilium007 »
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7305
  • Country: nl
  • Current job: ATEX product design
Re: I/O connector advice
« Reply #1 on: November 20, 2017, 10:37:39 am »
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.
 
The following users thanked this post: ilium007

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #2 on: November 20, 2017, 10:39:14 am »
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.
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #3 on: November 20, 2017, 10:46:20 am »
The DIN 41612 connector looks solid but $3 - $8 each in Australia they are well out of my price range.
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #4 on: November 20, 2017, 01:58:25 pm »
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.
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #5 on: November 20, 2017, 02:03:14 pm »
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.
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #6 on: November 20, 2017, 02:23:39 pm »
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.
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #7 on: November 20, 2017, 02:26:00 pm »
State machine ?

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

Offline CM800

  • Frequent Contributor
  • **
  • Posts: 882
  • Country: 00
Re: I/O connector advice
« Reply #8 on: November 20, 2017, 02:29:50 pm »
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
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #9 on: November 20, 2017, 02:32:59 pm »
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.
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #10 on: November 20, 2017, 02:38:04 pm »
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. 
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #11 on: November 20, 2017, 02:39:39 pm »
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  |O
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: I/O connector advice
« Reply #12 on: November 20, 2017, 03:05:02 pm »
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.
« Last Edit: November 20, 2017, 08:43:09 pm by Ian.M »
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #13 on: November 20, 2017, 03:26:10 pm »
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.

 

Offline Leo Bodnar

  • Frequent Contributor
  • **
  • Posts: 801
  • Country: gb
Re: I/O connector advice
« Reply #14 on: November 20, 2017, 07:22:13 pm »
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
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #15 on: November 20, 2017, 07:27:06 pm »
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.
 

Offline Leo Bodnar

  • Frequent Contributor
  • **
  • Posts: 801
  • Country: gb
Re: I/O connector advice
« Reply #16 on: November 20, 2017, 07:29:37 pm »
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
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #17 on: November 20, 2017, 07:46:17 pm »
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.
 

Offline Leo Bodnar

  • Frequent Contributor
  • **
  • Posts: 801
  • Country: gb
Re: I/O connector advice
« Reply #18 on: November 20, 2017, 08:05:32 pm »
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
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #19 on: November 20, 2017, 08:30:10 pm »
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.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: I/O connector advice
« Reply #20 on: November 20, 2017, 08:44:45 pm »
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?
 

Offline mariush

  • Super Contributor
  • ***
  • Posts: 4982
  • Country: ro
  • .
Re: I/O connector advice
« Reply #21 on: November 20, 2017, 08:50:10 pm »
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 
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: I/O connector advice
« Reply #22 on: November 20, 2017, 09:00:26 pm »
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 :)
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7305
  • Country: nl
  • Current job: ATEX product design
Re: I/O connector advice
« Reply #23 on: November 20, 2017, 09:05:48 pm »
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?
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #24 on: November 21, 2017, 12:10:04 am »
Thanks for the feedback. Wow...

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

« Last Edit: November 21, 2017, 12:19:46 am by ilium007 »
 

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12806
Re: I/O connector advice
« Reply #25 on: November 21, 2017, 12:21:49 am »
Its not the lag that's an issue (as the data out of each shift register is locally synchronised to its shift clock), its the master's fanout and also the possibility of a ground offset along the chain that makes it advisable to buffer the shift clock and the latch signal on each board before feeding them to the next board.

You only need a tristate buffer on the last TPIC6C595's data out if you want to close the loop (e.g. to check data integrity) *AND* have other SPI devices on the same SPI port of the master - beware of ground offsets and timing skew.
« Last Edit: November 21, 2017, 12:25:14 am by Ian.M »
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #26 on: November 21, 2017, 12:31:48 am »
Thanks for the reply - I have created another thread for this discussion on shift registers and SPI:

https://www.eevblog.com/forum/projects/designing-shift-register-circuit-for-spi-bus/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: I/O connector advice
« Reply #27 on: November 21, 2017, 12:48:03 am »
Does anyone have any other ideas for this amount of I/O from one board ?
I'd buy readily made relay boards. There are a dime a dozen so not worth designing yourself. In the past I have used these in the past:
http://www.conrad.com/ce/en/product/197720/Relay-card-Component-Conrad-Components-197720-12-Vdc-24-Vdc

You can daisy chain 255 of these so up 2040 contacts. AFAIK there are also versions which can handle mains.
All you need is an RS232 port and controlling them is very easy. I have used these in various projects including ones which required good reliability.
« Last Edit: November 21, 2017, 12:49:46 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #28 on: November 21, 2017, 12:49:30 am »
I'm undertaking this project as a way to learn more about electronics design and PCB design / manufacture. I'm not looking to buy off the shelf products but thanks for the advice.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: I/O connector advice
« Reply #29 on: November 21, 2017, 06:57:08 am »
I'm undertaking this project as a way to learn more about electronics design and PCB design / manufacture. I'm not looking to buy off the shelf products but thanks for the advice.

Anyway at least you shall listen to what is aid in this forum about I2C and SPI reliability, consider RS485 which is much more robust and widely used for signalling over long cable runs. Internet search "rs485 relay board module" will show you what I am talking about
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: I/O connector advice
« Reply #30 on: November 21, 2017, 08:04:43 am »
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). 

Anything "over distance" (more than a few meters) is much better off with something that has proper drivers, like RS485. If you're going to put in Shmitt triggers then you might as well do it properly.

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).

Or ... just get a chip that has I2C in hardware, eg. just about anything microcontroller these days. :popcorn:

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.

The only real problem with I2C is that if a clock pulse gets lost then the entire bus gets into a weird unsynchronized state. Don't try to build a vital I2C bus without some sort of reset mechanism (ie. add an extra wire for 'I2C reset').

If people tell you other buses are more reliable it's because they haven't fully understood that their favorite bus has a 'reset' mechanism built in. SPI has its CS signal, RS232 is based on hard timing so it automatically resets itself after every byte (and gives a 'frame error' if a stop bit is missing). Without this implicit reset they'd be just as 'unreliable' as I2C.

Done properly, I2C is as good/reliable as any other bus for short distances.

PS: No matter what bus you choose, always use checksums on packets, etc. No bus is that reliable.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: I/O connector advice
« Reply #31 on: November 21, 2017, 08:46:19 am »
Or ... just get a chip that has I2C in hardware, eg. just about anything microcontroller these days. :popcorn:

"Hardware" I2C in microcontrollers, unfortunately, typically means babysitting the "hardware I2C", polling the registers in a busy loop or creating way too complex interrupt driven state machines (as I recently needed to do on STM32), so that it's not much more efficient than just bitbanging the I2C. And, often it proves very difficult to do properly, including handling the corner cases: bit banging it is definitely easier.

This is all fine when you don't need real-time performance and/or reliability, but gets surprisingly difficult in more demanding cases.

I wish some MCU vendor would put in some real intelligence in the I2C peripheral to really offload the CPU. I like the way CAN peripherals are usually done, no need to poll some status bits all the time.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: I/O connector advice
« Reply #32 on: November 21, 2017, 09:11:18 am »
I wish some MCU vendor would put in some real intelligence in the I2C peripheral to really offload the CPU. I like the way CAN peripherals are usually done, no need to poll some status bits all the time.

I haven't used the STM32 but AVR chips like ATMega328 have quite a nice hardware I2C unit. It's a complete state machine that just interrupts you when it changes state (eg. byte finished transmitting, slave address received, etc).

It's hard to make I2C completely autonomous unless all protocol is fully known in advance. This simply isn't the case in microcontrollers.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7305
  • Country: nl
  • Current job: ATEX product design
Re: I/O connector advice
« Reply #33 on: November 21, 2017, 10:49:37 am »
I wish some MCU vendor would put in some real intelligence in the I2C peripheral to really offload the CPU. I like the way CAN peripherals are usually done, no need to poll some status bits all the time.
http://www.st.com/content/ccc/resource/training/technical/product_training/2d/5a/12/09/9e/7e/42/b3/STM32L4_Peripheral_I2C.pdf/files/STM32L4_Peripheral_I2C.pdf/jcr:content/translations/en.STM32L4_Peripheral_I2C.pdf
You mean more than setting up a DMA, and going to sleep, waking up on interrupt when finished? You cannot really cook coffee with I2C.
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: I/O connector advice
« Reply #34 on: November 21, 2017, 11:43:06 am »
"Hardware" I2C in microcontrollers, unfortunately, typically means babysitting the "hardware I2C", polling the registers in a busy loop or creating way too complex interrupt driven state machines (as I recently needed to do on STM32), so that it's not much more efficient than just bitbanging the I2C. And, often it proves very difficult to do properly, including handling the corner cases: bit banging it is definitely easier.

This is all fine when you don't need real-time performance and/or reliability, but gets surprisingly difficult in more demanding cases.
This has pretty much been my experience, the micros I2C core might handle the bit timing, and the data shift register (And may even understand slave clock stretching), but the rest of the protocol tends to turn into a state machine one way or another.
I don't doubt that some parts do better, but it is a little difficult to see how given the sheer variety of I2C devices in play and the various permutations of start/repeated start required. 

If doing I2C, definitely include the code to do a bus reset (Usually consists of many, many clocks without a start condition being asserted).

If you are talking real distance then I would definitely be looking at something more like RS485 (Possibly MODBUS) with a toy micro on each relay board, but I thought we were talking about everything in one chassis, with bus lengths a foot or so?

Regards, Dan.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: gb
Re: I/O connector advice
« Reply #35 on: November 21, 2017, 12:54:24 pm »
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?

It's pretty clear to me that he is saying don't use them in close proximity to high currents etc. as they are quite sensitive to noise.  Obviously it's not a part suitable for directly controlling high currents or being driven by long wires, and I don't think he is suggesting that.
 

Offline ilium007Topic starter

  • Frequent Contributor
  • **
  • Posts: 264
  • Country: au
Re: I/O connector advice
« Reply #36 on: November 21, 2017, 01:59:02 pm »
Anyway at least you shall listen to what is aid in this forum about I2C and SPI reliability, consider RS485 which is much more robust and widely used for signalling over long cable runs. Internet search "rs485 relay board module" will show you what I am talking about

I am definitely listening to you guys ! You know more than I do on the topic. I am going to look in to RS485 as well.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16560
  • Country: 00
Re: I/O connector advice
« Reply #37 on: November 21, 2017, 02:49:09 pm »
I am definitely listening to you guys ! You know more than I do on the topic. I am going to look in to RS485 as well.

RS485 works up to a kilometer. I2C and SPI are fine for a few feet of wire that isn't wrapped around a huge spark generator. Just be aware that I2C needs a reset protocol if it's anything critical, be it soft (lots of clocks with no START) or hard (a separate wire to signal a bus reset).
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: I/O connector advice
« Reply #38 on: November 21, 2017, 04:26:38 pm »

Before you jump to RS485, you might want to think about CAN buss.

I would say RS485 is good for moving data and not built for event processing.

CAN is built for event processing.
Used in vehicles and other places needing events.
The transfer of a small amount of data with priority controlling access to buss.
When you have hardware interrupt the MPU you are doing event processing.
CAN buss lets you expand
A hardware interrupt could cause a packet to be sent on CAN bus.
A software event could cause a packet to be sent on CAN bus.
The CAN bus hardware lets the highest priority packet go first.
All MPU's connected to CAN buss can decide if a packet needs local processing.

Example
A switch causes a CAN packet.
The track switch controller on receiving the CAN packet is to change track switch X
The track signal light controller on receiving the CAN packet set signal lights properly.
A main line track switch change could have a higher priority then a yard switch change.
 
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: I/O connector advice
« Reply #39 on: November 21, 2017, 04:32:57 pm »
I am definitely listening to you guys ! You know more than I do on the topic. I am going to look in to RS485 as well.
RS485 works up to a kilometer. I2C and SPI are fine for a few feet of wire that isn't wrapped around a huge spark generator. Just be aware that I2C needs a reset protocol if it's anything critical, be it soft (lots of clocks with no START) or hard (a separate wire to signal a bus reset).
I agree. Don't ever take I2C or SPI off-board using wires!
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: I/O connector advice
« Reply #40 on: November 21, 2017, 05:23:23 pm »
I wish some MCU vendor would put in some real intelligence in the I2C peripheral to really offload the CPU. I like the way CAN peripherals are usually done, no need to poll some status bits all the time.
http://www.st.com/content/ccc/resource/training/technical/product_training/2d/5a/12/09/9e/7e/42/b3/STM32L4_Peripheral_I2C.pdf/files/STM32L4_Peripheral_I2C.pdf/jcr:content/translations/en.STM32L4_Peripheral_I2C.pdf
You mean more than setting up a DMA, and going to sleep, waking up on interrupt when finished? You cannot really cook coffee with I2C.

Yes, you really need to do a lot more, unfortunately. Try it and you'll see.

Yes, you cannot cook coffee with I2C, that's the ridiculous part: it should be trivial. It should work exactly how you describe it. The I2C peripheral should be there to help.

DMA doesn't help much since you have to babysit (practically bit-bang) all kinds of "send a start bit now" "is start bit ready?" "can I send an address now?" "now write the address", "did I get ACK now?" - then finally you can DMA a few bytes of payload, whoopy doo.

A proper minimum implementation of what could be called "CPU-offloading hardware I2C" should work so that you'd configure one register with the I2C address and set a DMA channel with the data, tx or rx. Then it would do START, ADDR, and datas automatically. A better implementation would support also configuring a device register address beforehand so it would do a full I2CADDR-WRITE DEV REG ADDR-READ/WRITE PAYLOAD cycle on DMA. Unfortunately, it doesn't work in even the minimum way in STM32, and having briefly looked at some others, it seems to be equally bad everywhere.

STM32 implementation also has extra quirks and poorly documented features/bugs which is why it's widely regarded as unreliable. It took several days of fulltime work to get it really run smoothly and reliably, using interrupt driven management state machine (7 interrupts are generated and need to be processed correctly to read one byte of actual data from a device!). Bitbanging the whole I2C in a timer interrupt would have been both easier and possibly more efficient, unless high bitrates are needed.
« Last Edit: November 21, 2017, 05:48:28 pm by Siwastaja »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: I/O connector advice
« Reply #41 on: November 21, 2017, 06:51:54 pm »
DMA doesn't help much since you have to babysit (practically bit-bang) all kinds of "send a start bit now" "is start bit ready?" "can I send an address now?" "now write the address", "did I get ACK now?" - then finally you can DMA a few bytes of payload, whoopy doo.

There's also clock-stretching or for god's sake, bus locking surprises from some I2C peripherals too :-DD All this and not only, is reason why I usually avoid I2C peripherals in favor of SPI.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf