Designing model train layout I/O and PWM speed control

[ilium007]

This is a follow on from the discussion in a previous thread:

https://www.eevblog.com/forum/projects/io-connector-advice/

For my project (large model railway) I had originally looked at using TPIC6C595 shift registers to drive 60+ LED's as well as relays to drive points solenoids due to their current sink ability, and 74HC125 input shift registers for all inputs. These would run alongside the 74HC125 quad buffers on the shift registers (TPIC6C595 and 74HC165) to give them tri-state ability to run them on the SPI bus alongside other SPI devices. I already had the code written for it and had it all working on the breadboard ! I binned it all because I thought the MCP23017 was a more elegant solution ! After reading through the above thread I'm going to go back to my shift register design.

The MCU will run in to fan out issues driving too many shift registers so I need a buffer IC, the 74HC125 is a quad buffer but I'm not sure how many of the inputs/outputs need to be buffered on the TPIC6C595 and 74HC165 IC's.

Do I buffer CLK, DATA, LATCH and OE ?

*** I just realised that the TPIC6C595 does not have a LATCH *** I need to do some more research.

Baring the latching issue above, the 74HC125's OE pin would be driven like an SPI SS pin I'm guessing ?

[ilium007]

It looks as though the RCK (Register clock) pin is the same as the LATCH pin on the 74HC595 which I have used before.

There is a fair amount of thermal via action going on here !

[phil from seattle]

I don't quite understand your fan out issue. SRs like this can be daisy-chained.  For 60 outputs, you would have 8 SRs chained. Clock 64 bits through (waste 4) and pulse RCK. Boom! all 64 outputs have the correct data.

[Ian.M]

Yes.  In the other topic you mentioned this is being driven by a Teensy, so you would simply copy all your relay states to a multi-byte buffer and call SPI.transfer(buffer,count) to send all the relay data to the chain of shift registers.

[ilium007]

I was advised that running 8 of these off the one MCU pin would cause fan out issues. I am not sure how to calculate that for myself so I went with the advice. I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

If for no other reason I am interested in learning about the use of the 74HC125 IC's in this scenario.

[ilium007]

Yes.  In the other topic you mentioned this is being driven by a Teensy, so you would simply copy all your relay states to a multi-byte buffer and call SPI.transfer(buffer,count) to send all the relay data to the chain of shift registers.

Exactly - I was just unsure of the pin out names for the TPIC6C595 as they differ from the 74HC595 ie. LATCH is RCK and OE is G.

[phil from seattle]

I was advised that running 8 of these off the one MCU pin would cause fan out issues. I am not sure how to calculate that for myself so I went with the advice. I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

If for no other reason I am interested in learning about the use of the 74HC125 IC's in this scenario.

You received bad advice.  Fan out only happens with 1 output to many inputs.  Each Shift-out pin will provide drive to the next input.

Here's a graphic:

[ejeffrey]

I don't quite understand your fan out issue. SRs like this can be daisy-chained.  For 60 outputs, you would have 8 SRs chained. Clock 64 bits through (waste 4) and pulse RCK. Boom! all 64 outputs have the correct data.

The data lines are daisy chained but the clocks are connected in parallel.  That said, a fanout of 8 for a SPI clock line should be no big deal, assuming you are running the shift clock at a normal frequency. 

[ilium007]

I was advised that running 8 of these off the one MCU pin would cause fan out issues. I am not sure how to calculate that for myself so I went with the advice. I am still considering bi-colour LED's which means my 60 outputs goes to 120 ! 16 TPIC6C595's would surely create fan out problems.

If for no other reason I am interested in learning about the use of the 74HC125 IC's in this scenario.

You received bad advice.  Fan out only happens with 1 output to many inputs.  Each Shift-out pin will provide drive to the next input.

Here's a graphic:

That makes sense, thanks. So for the SPI output to the TPIC6C595's I don't really have to worry about fan out problems, I have MOSI driving the first TPIC6C595 directly and I could have 50 of them daisy chained from there - no fan out problem.

I don't quite understand your fan out issue. SRs like this can be daisy-chained.  For 60 outputs, you would have 8 SRs chained. Clock 64 bits through (waste 4) and pulse RCK. Boom! all 64 outputs have the correct data.

The data lines are daisy chained but the clocks are connected in parallel.  That said, a fanout of 8 for a SPI clock line should be no big deal, assuming you are running the shift clock at a normal frequency. 

So now I want to expand to 100 TPIC6C595's (extreme example) - MOSI has no fanout issue but SCLK and the latch would ? So should I just include a 74HC125 quad buffer and buffer all connections - MOSI, MISO, SCLK and SS (digital pin used to select OE on the buffers) ?

For the 74HC165 inputs I would run in to problems here because (extreme example) if I had 100 IC's talking on MISO to the one MCU MISO pin.

I have been reading a fair bit about SPI and tri-state requirements for devices on the same bus. I came across this image (https://www.dorkbotpdx.org/blog/paul/better_spi_bus_design_in_3_steps):

I'm assuming in this diagram that device #2 doesn't have the ability to put it's MISO pin into high impedance mode where the other two 'SPI compliant' devices can and therefore they can co-exist on the same SPI bus - but what about MOSI ?



The tri-state issue only occurs on the MISO line - why is that ? If I had a device on the SPI bus that did not tri-state its MISO pin when its chip select was disabled I can see the need for the tri-state buffer, but what about MOSI ? Why isn't that the same ?

Is it because there is only one master device therefore on the MOSI line there can never be a collision of a 1 and a 0 ie. a short circuit, but on the MISO line, if a device outputs a 1 when another outputs a 0 there could be a problem. Input devices ignore the traffic on the MOSI line via their SS / OE pins.

[ilium007]

So from further reading it seems that there are two different issues I am dealing with through the use of buffers - again, extreme example of 100 TPIC6C595's and 100 74HC165 IC's:

• fan in limitations on MISO lines and fan out limitations on the CLK line and SS line (for latching the shift registers)
• MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

If I were to require 100 x output shift registers and 100 x input shift registers how would you connect the buffers ?

[C]

in your Good SPI bus design photo

For the micro all signals are outputs but the blue line MISO which is an input.
One output can be connected to many inputs with out a fight.
#1 & #3 have blue line outputs that tristate when not selected by CS.
#2 needs an added gate.

What is not stated is how many bit shift register each of the devices have.
For SPI you want a multiple of 8 bits.
Device #1 could have a shift register 64 bits wide, could be 128 bits wide or any multiple of 8
It does not have to match bit width of other devices.

For an output CS going inactive could latch the output data.
For an input CS going active could latch the input data.

[C]

this post is one device

Look at figure 14 from this data sheet
http://www.ti.com/lit/ds/symlink/tpic6c595.pdf

If you did this each added TPIC6C595 adds 3 connections to MCU. You would run into fan - out problems

Now draw a vertical line between the two TPIC6C595 in figure 14
You have four signals crossing the line.
The line is the 74HC125 quad buffers ic
Four inputs & four outputs. The max load on before circuit is one when you add one 74HC125 & one TPIC6C595.

Now look at the timing of circuit.
If you had 100 boards each with a 74HC125 & TPIC6C595 in series the timing stays good.  Each buffer delays the four signals so that when a signal changes stays close to constant with respect to the other signals.  Data sheet states typical delay of a 74HC125 is 11 ns. You put a signal in and with 100 boards in series, the change comes out 100 x 11ns later from last board, a total delay of 1100ns. But if  clock signal changes 20ns after the data signal change at the end of chain the clock signal will still be changing about 20ns after the data change. The about is due to the differences in each buffer & the difference in cable.


Now if your clock was 10Mhz using SPI the data would change 50ns before the clock change. 10Mhz divided by 8 clocks per board divided by 100 boards and your are updating your leds 12,500 times a second. Think a much slower rate will do.
With 100 boards you would have 100 bytes of data. By expanding to 400 bytes you could have 4 levels of brightness if the update rate was fast enough.

With buffers on each board you can add some distance between boards.
Do you want all the wires for your led's coming to a central point or a much neater spread of boards where each handles 8 leds.
A buss of 6 wires would connect the buffers, power, ground & four signals.
Would be good to have two connections for output power of TPIC6C595.
To make wiring easer, you might not want to use every output.

Now when you think of input that long buffer delay needs to be worked with.
If you replace the output board that has one 74HC125 & one TPIC6C595.with a input board with one 74HC125 & one 74HC165.  Clock in is delayed to clock out with data also delayed.  Would be a good idea to have clock out clocking in the data to microprocessor. To get this you need a slave mode SPI input.

So output data using one SPI port in master mode.
Receive input using a second SPI port in slave mode.
You can then connect the input chain clock in to a clock from the SPI master output chain to get the 8 clock pulses needed.

[rs20]

MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

The 74HC165 chip doesn't have a MISO pin. If you try to press its Q pin into a MISO pin, then yeah it won't be tristated via CS because it's not a MISO pin.

Anyway, if I was driving LEDs, I would just leave the Q pins disconnected. There's no point in routing that data back to the MCU. If you're using other shift registers for input, then dedicate those to input alone.

Also, it's very strange to arrange 74HC165 in an SPI bus arrangement. Why wouldn't you just lay them out as a classic cascaded shift register?

[ilium007]

Thanks for the detailed reply @C - its going to take some time to digest all of this.

[ilium007]

MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

Also, it's very strange to arrange 74HC165 in an SPI bus arrangement. Why wouldn't you just lay them out as a classic cascaded shift register?

Thats exactly what I intend on doing, but if the cascaded chain of 74HC165's is on the same SPI bus as other devices the MISO pin from the cascaded chain needs to be tri-stated - yes ?

I don't have the ability on the iPad to draw what I am talking about - I will try and draw a block diagram of what I am proposing later tonight when I get to a computer.

[ilium007]

this post is one device

Look at figure 14 from this data sheet
http://www.ti.com/lit/ds/symlink/tpic6c595.pdf

If you did this each added TPIC6C595 adds 3 connections to MCU. You would run into fan - out problems

Now draw a vertical line between the two TPIC6C595 in figure 14
You have four signals crossing the line.
The line is the 74HC125 quad buffers ic
Four inputs & four outputs. The max load on before circuit is one when you add one 74HC125 & one TPIC6C595.

Now look at the timing of circuit.
If you had 100 boards each with a 74HC125 & TPIC6C595 in series the timing stays good.  Each buffer delays the four signals so that when a signal changes stays close to constant with respect to the other signals.  Data sheet states typical delay of a 74HC125 is 11 ns. You put a signal in and with 100 boards in series, the change comes out 100 x 11ns later from last board, a total delay of 1100ns. But if  clock signal changes 20ns after the data signal change at the end of chain the clock signal will still be changing about 20ns after the data change. The about is due to the differences in each buffer & the difference in cable.


Now if your clock was 10Mhz using SPI the data would change 50ns before the clock change. 10Mhz divided by 8 clocks per board divided by 100 boards and your are updating your leds 12,500 times a second. Think a much slower rate will do.
With 100 boards you would have 100 bytes of data. By expanding to 400 bytes you could have 4 levels of brightness if the update rate was fast enough.

With buffers on each board you can add some distance between boards.
Do you want all the wires for your led's coming to a central point or a much neater spread of boards where each handles 8 leds.
A buss of 6 wires would connect the buffers, power, ground & four signals.
Would be good to have two connections for output power of TPIC6C595.
To make wiring easer, you might not want to use every output.

Now when you think of input that long buffer delay needs to be worked with.
If you replace the output board that has one 74HC125 & one TPIC6C595.with a input board with one 74HC125 & one 74HC165.  Clock in is delayed to clock out with data also delayed.  Would be a good idea to have clock out clocking in the data to microprocessor. To get this you need a slave mode SPI input.

So output data using one SPI port in master mode.
Receive input using a second SPI port in slave mode.
You can then connect the input chain clock in to a clock from the SPI master output chain to get the 8 clock pulses needed.

I'm thinking of designing these boards with 64 I/O on the one board - that way a single 74HC125 would buffer the 8 x IC's (either TPIC6C595's or 74HC165's).

From your response I presume I should be buffering all 4 lines:

• SRCK (SPI CLOCK)
• RCK (LATCH)
• MOSI (or MISO for the inputs); and
• CE (SPI SS)

Responding to your previous comment, each register takes 1 byte so each I/O board would by 8 bytes of data. These I/O boards could be cascaded, each new board would take another 8 bytes from the one MOSI data line from the uC.

I got lost a little bit re. the timing. I realise that it is a good idea to be buffering all 4 lines so that timing stays in sync due to the 11ns delay through the buffer.

I didn't quite understand this comment or any of the timing info you supplied after that (sorry, I'm still new to this):

Now if your clock was 10Mhz using SPI the data would change 50ns before the clock change.

I didn't understand this either - I assumed to read the inputs from the 74HC165's I could still do this with the uC in SPI master mode:

Now when you think of input that long buffer delay needs to be worked with.
If you replace the output board that has one 74HC125 & one TPIC6C595.with a input board with one 74HC125 & one 74HC165.  Clock in is delayed to clock out with data also delayed.  Would be a good idea to have clock out clocking in the data to microprocessor. To get this you need a slave mode SPI input.

So yeah, still a little bit confused....

[rs20]

MISO collision risk using devices that don't tri-state their MISO pin when chip is deselected via CS (such as the 74HC165)

Also, it's very strange to arrange 74HC165 in an SPI bus arrangement. Why wouldn't you just lay them out as a classic cascaded shift register?

Thats exactly what I intend on doing, but if the cascaded chain of 74HC165's is on the same SPI bus as other devices the MISO pin from the cascaded chain needs to be tri-stated - yes ?

Only if you want to read something back from the shift registers -- but if, for example, you are only driving LEDs with your shift registers, then you don't need or want to read anything back at all, and therefore there's no reason to connect the final Q/"MISO" line to anything at all.

[danadak]

Just a thought but I think you could do do this in a muxed fashion
with a single chip to do all 60 leds, as well as the relay driver
out, and various inputs, with a SPI interface. PSOC 5LP

In fact possibly thru DMA design primarily all HW.

Additionally could be done DMX, I2C, UART, USB, One wire, SMBUS,
as well as SPI.

If you wanted to stay with SR approach design permits custom component
realization inside PSOC, thru verilog or schematic capture. Although I think
you would run up against chip power rail current limits (if not muxed).

Just a thought.


Regards, Dana.

[ilium007]

Only if you want to read something back from the shift registers -- but if, for example, you are only driving LEDs with your shift registers, then you don't need or want to read anything back at all, and therefore there's no reason to connect the final Q/"MISO" line to anything at all.

I will be using the 74HC165 shift registers to capture the inputs from the 35 switches so I will need the tri-stated MISO line.

[C]

when you want to connect a lot of chips in series, step one is the series connection between the chips.
The TPIC6C595 could have 5 signals in the series connection.
SER IN comes from the previous chip.
The remaining 4 are parallel connected. A parallel connection like this can have fan out problems. Will get back to this later.

In figure 14 the SRCLR pin is pulled high. Read 8.3.2, and note that as wired in figure 14, using the clear input would turn on the LEDs. With no clear input, you have random data on output at power up until the MCU has initialed proper levels by a serial shift of all bits followed by pulse on RCK.  But note with control of G you can turn off outputs so random data in latch should not be a problem.
 
If this is ok then you have 4 signals between chips to daisy chain.

You add buffers to reduce fan-out load but also to clean up the signals.

Step two is the interface width mpu to drive these signals properly.
A quick look suggests some work when connected to SPI & some might not.

Serial in could connect to MOSI
Serial clock could then connect to SCI clock

RCK does not match up to a SCI signal.
As shown on page 9, "Voltage Waveforms" this pin wants a pulse after shifting all bits out.
G also does not match up.
So use two pins of MCU for RCK & G

If you have something else connected to SPI port then CS needs to prevent clocks to RCK when not selected.
This gives MPU to buffer to TPIC6C595 with the SPI CS controlling the OE of buffer to RCK

I'm thinking of designing these boards with 64 I/O on the one board - that way a single 74HC125 would buffer the 8 x IC's (either TPIC6C595's or 74HC165's).

This is putting a lot of connections to one board and in process adding a lot of wire to get from board to leds.
If you are going to have PC boards made, more smaller boards could be cheaper.

Timing
"INPUT SETUP AND HOLD WAVEFORMS" page 9 SRCK & SER IN
If you read up on SOI, tsu = th with both = 25% of clock
 tsu + th = 50% of clock
 
Now if SRCK has a period of 110ns
The signals are delayed 11ns per buffer. After 10 buffers the signals align again with one bit delay in time.
Now think of what would happen for above if one signal went through 5 more buffers the the other. You would have data changing at same time as clock,.
If SRCK is slower it would take more buffers to get one bit time delay.

For Input chain
If you think it through, you could get a huge fan-out with two levels of buffers.
The problem with this is long signal runs with boards around the layout.
With buffers in series, you can use a slower clock to collect input data. With slower clock the 11ns per buffer becomes a smaller % of clock time. 
With MPU driving the clock input and MPU reading the data output of buffer chain.
In the above drawing Tsu is changing from 25% with each added buffer.

So to put it all together
Using the MOSI & SPI clock lets you output data faster. You still need two more pins for RCK to latch data & for G

For input nothing stops you from using signal that goes to RCK to latch the input data many times and not read the inputs.
Then after X outputs of RCK you could use and additional pin to clock the 74HC165 shift registers  at slower rate and one more pin to read the data using bitbang mode.
For input 10 to 20 reads of inputs is probably fine. If you are using switches to supply the inputs to the 74HC165 you could have some contact bounce.

This totals 6 pins on MPU.
The higher output rate would let you dim the leds if you wanted to.

 

[ilium007]

Thanks again for your time and detailed reply. I had drawn this up before I read your response. It is just for the outputs on the TPIC6C595 fed from the uC.

Each 'cascade' of TPIC6C595's (and there will only be one cascade because each board will be serially connected to another) will have one SS pin on the uC, this digital pin will also control all OE inputs on the quad buffer IC to bring each pin out of its tri-state high impedance mode.

LATCH_IN and SS_IN in the schematic below are just digital outputs on the Teensy 3.6. MOSI_IN and SCLK_IN are the hardware SPI pins on the Teesny 3.6.



I am still processing the part about timing and I haven't yet got to the input stage to think about them.

One other issue I am going to face is the Teensy 3.6 I'm using is 3.3v and the TPIC6C595 chips are 5v. I am going to require level conversion - I am hoping there is a 74HC125 alternative that does buffering and level conversion 3.3v -> 5v but then I will need something that will do the 5v -> 3.3v for the MISO input from the 74HC165's.

[Ian.M]

Actually RCLK can be treated as a SPI /SS signal - shift out N bytes of data for a write-only daisychain of N TPIC6C595 chips with RCLK low and latch it onto the outputs when RCLK goes high.   You don't even have to gate SRCLK with /SS on a shared SPI bus as any garbage shifted in while its /SS is high is pushed out by the N data bytes before it can be latched.

Few applications need the G output enable signal or the CLR reset signal under MCU control, so you typically only have to buffer SRCLK and RCLK.  The slight timing skew by not buffering SEROUT is negligible over short interconnects, as SEROUT is synched to SRCLK at each device so the relative skew cant accumulate

Also its fairly pointless buffering them for *EVERY* TPIC6C595.  You only need to buffer if the daisy chain goes off board or if the fanout of the  previous buffer (or MCU output pin) would be exceeded.   

As it will be a lot cheaper in prototype quantities to make a smaller relay board, and have lots of them rather than making one big biard as a one-off, I'd put one TPIC6C595 and one 74LVC2G34 (possibly with series resistors on its outputs to limit the slew rate), eight relays and eight antiparallel diodes across their coils on each board.

Unidirectional level translation is trivial: for 3.3V=>5V upwards translation use any 74HCT gate powered at 5V as TTL thresholds are 3.3V logic compatible.  For 5V=>3.3V downwards translation, as long as you keep the load on the 3.3V side down to one gate input and minimal track length, you can use a resistive potential divider, possibly with a few pF of speed-up capacitance across its upper arm to compensate for the load capacitance and square up the edges. 

If you need anything better look at the 74LVC1T45 (single) and 74LVC2T45 (dual) level translators with independent VCC pins for their two sides.

[ilium007]

Actually RCLK can be treated as a SPI /SS signal - shift out N bytes of data for a write-only daisychain of N TPIC6C595 chips with RCLK low and latch it onto the outputs when RCLK goes high.   You don't even have to gate SRCLK with /SS on a shared SPI bus as any garbage shifted in while its /SS is high is pushed out by the N data bytes before it can be latched.

Few applications need the G output enable signal or the CLR reset signal under MCU control, so you typically only have to buffer SRCLK and RCLK.  The slight timing skew by not buffering SEROUT is negligible over short interconnects, as SEROUT is synched to SRCLK at each device so the relative skew cant accumulate

Also its fairly pointless buffering them for *EVERY* TPIC6C595.  You only need to buffer if the daisy chain goes off board or if the fanout of the  previous buffer (or MCU output pin) would be exceeded.   

As it will be a lot cheaper in prototype quantities to make a smaller relay board, and have lots of them rather than making one big biard as a one-off, I'd put one TPIC6C595 and one 74LVC2G34 (possibly with series resistors on its outputs to limit the slew rate), eight relays and eight antiparallel diodes across their coils on each board.

Yeah, I was only going to have one buffer per board (up to 8 shift registers but will be lower given the advice in this thread).

So what pins do I absolutely need to buffer for fanout reasons ? RCLK, SCLK ? I understand MOSI (SER_IN) won't require buffering, SS probably doesn't given what you said about G (OE) not being required (I think it should be tied low not high via the pullup as shown in my schematic)

[Ian.M]

You need to buffer ONLY those signals that would otherwise be wired in parallel to the whole daisychain.  Most likely just RCLK and SRCLK, unless you also want to use G for bulk PWM dimming of all the LED loads.

With PCB area being the dominant cost for prototypes (often 10x of a board is a negligible cost increase over 1x) it doesn't make a lot of sense to put many shift registers on the same board.  The extra cost of right angle M and F headers and PCB mount spade lugs and  4x the number of buffers will almost certainly be cheaper than larger boards.  Its also easier to test!.

It *may* make sense to put two shift registers on the same board, depending on the size of the relays, and any steps in cost vs board area.   Its different economics if you are using padboard or stripboard - then you need to pack as many as possible on one standard size board

[ilium007]

You need to buffer ONLY those signals that would otherwise be wired in parallel to the whole daisychain.  Most likely just RCLK and SRCLK, unless you also want to use G for bulk PWM dimming of all the LED loads.

With PCB area being the dominant cost for prototypes (often 10x of a board is a negligible cost increase over 1x) it doesn't make a lot of sense to put many shift registers on the same board.  The extra cost of right angle M and F headers and PCB mount spade lugs and  4x the number of buffers will almost certainly be cheaper than larger boards.  It *may* make sense to put two shift registers on the same board, depending on the size of the relays, and any steps in cost vs board area.   Its different economics if you are using padboard or stripboard - then you need to pack as many as possible on one standard size board

Understood. I will look at the economics of the board sizes. Only one type of board will be a relay board and 8 relays is all I require for this project so that one is easy. The other boards will be a N-channel MOSFET output board to trigger the 26 solenoids (pulse current is approx 3A !), so maybe a 32 output board (4 x TPIC6C595's and 1 x buffer), and a board just for driving the LED's on a control panel, approx 50 LED's all within close proximity so maybe 2 x 32 output boards just for LED's (similar to the MOSFTE boards just without the 2N7002 output MOSFETS and flyback diodes (the TPIC6C595's will sink enough current for the LED's).

I want to be able to use these designs later on for other projects so I'm trying to build things as generic as possible.