I/O connector advice

[Ian.M]

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.

[ilium007]

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/

[nctnico]

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.

[ilium007]

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.

[ogden]

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

[Fungus]

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.

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.

[Siwastaja]

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

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

[Fungus]

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.

[tszaboo]

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.

[dmills]

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

[mikerj]

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.

[ilium007]

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.

[Fungus]

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

[C]

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.
 

[nctnico]

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!

[Siwastaja]

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.

[ogden]

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 All this and not only, is reason why I usually avoid I2C peripherals in favor of SPI.