Designing model train layout I/O and PWM speed control

[ilium007]

OK - thanks

No smoke is coming out so thats a good thing !

https://youtu.be/8aBOuiYHxXk

[ilium007]

For the 74HC125 control line output buffers simply tie all their /OE pins to 0V.   You *NEVER* need or want to tristate the output buffers.

The last input board in the chain (nearest to the MCU) needs tristate control of its data out, driven by /SS, but the others don't.   Put that /OE on a separate pin of the inter-board connector so you can connect it to /SS at the MCU and ground it at the connector for the next board.

Lets just say I had some other device on the same SPI bus that listened on the MOSI line for data (let say a hypothetical SPI display device) and I didn't want my chain of output boards receiving the data destined for the display, would this be a case to disable the buffers OE pins on the output chain instead of just tying them all to GND. This would put my output chain into tristate mode for SRCK, RCK and MOSI lines and they would ignore the data going to the display.

It probably wouldn’t affect anything because the next time I feed in x bytes of data and latch the chain all the erroneous data would have been shifted out.

Just an example but I'm interested in understanding how other devices could co-exist on the same SPI bus.

[Ian.M]

It doesn't matter what gets clocked along the chain as long as /SS isn't pulsed.  However if you are running the display much faster and don't want the EMI and possible glitch issues of running over-speed data and clock down the chain, then yes you *COULD* gate SPI SCLK and MOSI with /SS, using the /OE pins on the buffers, but it would be essential to have pullups or pulldowns on the buffer outputs to maintain both signals at a valid logic level, the same as their normal 'idle' level while they are disabled by /SS high.  If you get the SCLK idle level wrong, you get an extra active clock edge either on the falling or rising edge of /SS which could cause problems.

IMHO this sort of gating should be done on your MCU board - do it at the level shifter and have one 74HCT125 quad buffer as the upwards level shifter and a 74LVC1G125 as the downwards level shifter per external shift register board connector.  As the /SS signal is unique per peripheral, you don't need to worry about the fanout into the /OE pins of the buffers.  That also lets you mix 5V and 3.3V SPI slaves, as the master bus is 3.3V and it only gets shifted up to 5V for the 5V slaves.   3.3V peripherals can be buffered  and gated the same way, just substitute a 74HC125 run at 3.3V.  Design your board so you can populate either a pullup (to the '125 Vcc) or a pulldown for MOSI and SCLK buffered outputs as you'll need to be able to make the idle states consistent with the SPI mode of the peripheral on that connector. 

[C]

When you have many devices and only want to work with one, you select it in a way so only one is active.

For a memory chip, one way is chip select.

To select on SPI
  You need to things
   The tri-state of MISO so that only one is trying to talk to mpu.
   The Stopping of MOSI data being used at wrong time.
   
  If SRCK dies not happen then a data Input change to chip does not matter.
  If RCK does not happen then Data in the shift register does not get latched. .

So garbage data in shift register does not matter if no RCK
Data changing on Shift register input does not matter is no shift register clock

You asked about display and this. It could also be two or more separate chains of this.

You might have
   SPI display
   SPI chain for console
   SPI chan for track
SPI ...

Each would have a select input.
   The select input  would enable output to MCU and
   enable RCK & SRCK clocks to chain
   MOSI data would not be used with no SRCK

So step one, look at many separate chains of your boards, can you control them one at a time.

If nothing happens between MCU and first serial output chip, then additional chips(boards) also see no change. 
Changing the select input should do nothing but enable clocks to happen, no logic level change on clock input.

Adding an additional SPI device should be simple.
 Check that fan-out to drive more SPI inputs is not a problem.
 Give the MCU a way to control the added select line.
Add software for additional SPI device.

Ian.M is stating same with more detail

One important detail in Lan.M's not to be missed.

Speed differences between things connected to the MCU's SPI port.
The MCU is talking to all at same time.
One version of your boards could use very slow version of logic. Trying to clock this version to fast and you get garbage.
  You have two choices, slow every one down to this safe speed for all
 OR
 Prevent this version of seeing any of the high speed changes.

 

[David Hess]

I will just describe how I did it with less complexity and 4 signal lines.

I used only 74HC165s for inputs and 74HC595s for outputs with no other logic.  The shift/-load pins on the 74HC165s were all tied in parallel with the load pins of the 74HC595.  The clock pins were all tied in parallel.  All 74HC165s and 74HC595s were daisy chained between the serial output and serial input pins of the controller.

So with shift/-load/load held high, new serial data is clocked through all of the registers, then shift/-load/load is toggled low momentarily to latch data out of the 74HC595s and latch data into the 74HC165s, then the serial data is clocked again to read the 74HC165s which should be located at the end of the chain for best performance.  If only a read from the 74HC165s is desired, then duplicated output data has to first be copied to the 74HC595s but that is what shadow registers are for.

The whole thing was way more than fast enough to control 8 7-segment digits (64 bits) plus a full keypad (16 bits) in real time from a PIC which was busy doing other things.  Access could be synchronously timed for minimum noise if necessary which is why I did not use a multiplexed display.  If I did it today, I would probably replace the whole thing with the least expensive 28-pin PIC or similar and program it for multiplexed operation unless the lowest noise is required or the highest reliability.

[ilium007]

It doesn't matter what gets clocked along the chain as long as /SS isn't pulsed.  However if you are running the display much faster and don't want the EMI and possible glitch issues of running over-speed data and clock down the chain, then yes you *COULD* gate SPI SCLK and MOSI with /SS, using the /OE pins on the buffers, but it would be essential to have pullups or pulldowns on the buffer outputs to maintain both signals at a valid logic level, the same as their normal 'idle' level while they are disabled by /SS high.  If you get the SCLK idle level wrong, you get an extra active clock edge either on the falling or rising edge of /SS which could cause problems.

IMHO this sort of gating should be done on your MCU board - do it at the level shifter and have one 74HCT125 quad buffer as the upwards level shifter and a 74LVC1G125 as the downwards level shifter per external shift register board connector.  As the /SS signal is unique per peripheral, you don't need to worry about the fanout into the /OE pins of the buffers.  That also lets you mix 5V and 3.3V SPI slaves, as the master bus is 3.3V and it only gets shifted up to 5V for the 5V slaves.   3.3V peripherals can be buffered  and gated the same way, just substitute a 74HC125 run at 3.3V.  Design your board so you can populate either a pullup (to the '125 Vcc) or a pulldown for MOSI and SCLK buffered outputs as you'll need to be able to make the idle states consistent with the SPI mode of the peripheral on that connector.

Which line are you referring to as /SS ? It is the RCK (latch) line ?

[Ian.M]

@David Hess,

That's great for a limited number of shift registers all on the same board. However I'm surprised you put the 74HC165s in the same daisychain as the 74HC595s - that's fairly pointless unless you are going to shift the output data all the way round so it can be checked against what it was meant to be to catch glitches in a high EMI environment.

The problems start when you have many boards and interconnects in each daisychain  + other SPI devices, hence the more complicated (but expandable) solution 'C' and myself are proposing.

@ilium007,
If you are using '595 style SIPO shift registers, that latch their data on the rising edge of their store clock, then yes that's SPI /SS.   If you are using PISO shift registers for input it gets a lot more complex as you need to latch the inputs into the shift register as /SS goes low so may need some glue logic on the first board to generate a strobe for the chain with the right timing.

[David Hess]

That's great for a limited number of shift registers all on the same board. However I'm surprised you put the 74HC165s in the same daisychain as the 74HC595s - that's fairly pointless unless you are going to shift the output data all the way round so it can be checked against what it was meant to be to catch glitches in a high EMI environment.

The problems start when you have many boards and interconnects in each daisychain  + other SPI devices, hence the more complicated (but expandable) solution 'C' and myself are proposing.

I wasn't recommending my solution so much as describing it for edification; the load signal may be shared for inputs and outputs even in a minimum logic design.

Like I said, except where the absolute minimum noise is required or the highest reliability, I would use a multiplexed design now but that may not be convenient for your application.

[ilium007]

As the /SS signal is unique per peripheral, you don't need to worry about the fanout into the /OE pins of the buffers.

So /SS is the RCK, or latch, line, is it also being used to control /OE on the buffers ? /OE is active low so when high it puts the buffer gate into high impedance mode. So if /SS isn’t latching it is low, this would mean the buffer gate are active but then go high impedance when the shift registers are latched ?

[ilium007]

If you are using PISO shift registers for input it gets a lot more complex as you need to latch the inputs into the shift register as /SS goes low so may need some glue logic on the first board to generate a strobe for the chain with the right timing.

How much more complex ??!! I will be using 74HC165’s PISO shift registers for the inputs. Does this get complex because of what I mentioned previously, the /SS line is disabling the /OE on each buffer.

I’m starting to think I should have just persisted with the MCP23x17 IC !

[Ian.M]

Not vastly more complex - you just need to OR /SS with a delayed and inverted copy of itself to generate a short low going strobe pulse for SH/nLD immediately after the falling edge of /SS.   You also have tristating the final data out to take care of if there are other SPI inpuut or IO devices and you may want to run /SS to all the ClkInh inputs to stop them shifting when not selected.

Using De Morgan's laws, the OR can be replaced with three gates from a 74HC132 quad Schmitt input NAND, + a RC network to implement the whole strobe pulse generator circuit.  Populate it on the first board, and jumper it out on subsequent boards in the daisychain.

[Buriedcode]

Forgive me if I get something wrong, I really haven't read the whole thread, just skimmed (always dangerous) but I if you simply wish to have lots of inputs, and lots of outputs, then I see no need to tristate anything.

This is especially true if you are using a teensy, which has more than one SPI port, you can dedicate an SPI port to output and input shift register (74HC595 for output and 74HC165 for input).  I'm not sure why there is talk of buffers, tristating, and extra logic. Sure you'll need an extra latch pin, but this doesn't have to be part of the SPI port.. often people bitbang the SS/CS line anyway.  You'll also need an extra line for the 165's to latch in their inputs to the register.  I would daisy chain the 595's to MOSI, and the 165's to MISO.  There are a few ways to do this, but having tristate buffers for each shift register so that you can read in from the 165's without writing/updating the output register seems over kill.

I think perhaps you're concentrating too much on the SPI spec rather than just using SPI to drive shift registers (which can have different control lines to actual SPI). The SPI port, in master mode, is just being used as a sift register and clock generator. 

From what I have read - again could be wrong! - there is some confusion because there are lots of terms that can be inter-changable depending on the application, /OE, /CS, /SS, latch, Rclk, clock enable etc..
Diagrams are much better.

[ilium007]

Not a lot more complex - you just need to OR /SS with a delayed and inverted copy of itself to generate a short low going strobe pulse immediately after the falling edge of /SS.

Using De Morgan's laws, the OR can be replaced with three gates from a 74HC132 quad Schmitt input NAND, + a RC network to implement the whole strobe pulse generator circuit.
Populate it on the first board, and jumper it out on subsequent boards in the daisychain.

I have absolutely zero understanding as to how any of what you said would actually work ! I am happy to go and research some more. If this can be done in software I can continue trying to get a board design done but if it relies on hardware changes I will need to stop and gain some more knowledge first. I haven't read anywhere about people running into timing issues with the PISO devices - they all just say chain them together, latch them and the read the MISO on SCLK ! I thought this was going to be a somewhat simpler solution compared to the I/O expanders !

[ilium007]

Forgive me if I get something wrong, I really haven't read the whole thread, just skimmed (always dangerous) but I if you simply wish to have lots of inputs, and lots of outputs, then I see no need to tristate anything.

This is especially true if you are using a teensy, which has more than one SPI port, you can dedicate an SPI port to output and input shift register (74HC595 for output and 74HC165 for input).  I'm not sure why there is talk of buffers, tristating, and extra logic. Sure you'll need an extra latch pin, but this doesn't have to be part of the SPI port.. often people bitbang the SS/CS line anyway.  You'll also need an extra line for the 165's to latch in their inputs to the register.  I would daisy chain the 595's to MOSI, and the 165's to MISO.  There are a few ways to do this, but having tristate buffers for each shift register so that you can read in from the 165's without writing/updating the output register seems over kill.

I think perhaps you're concentrating too much on the SPI spec rather than just using SPI to drive shift registers (which can have different control lines to actual SPI). The SPI port, in master mode, is just being used as a sift register and clock generator. 

From what I have read - again could be wrong! - there is some confusion because there are lots of terms that can be inter-changable depending on the application, /OE, /CS, /SS, latch, Rclk, clock enable etc..
Diagrams are much better.

I'm not proposing one buffer per shift register, I am talking about one buffer per 8 shift registers and being able to expand this to 100 or 1000 shift registers. The buffer IC's are there to control fanout and voltage level shifting from 3.3v to the 5v operating voltage of the TPIC6C595 shift registers.

Diagrams are much better.

I am trying to get to the point of drawing a diagram but I am now so lost by the whole design I don't know where to start.

[ilium007]

Not vastly more complex - you just need to OR /SS with a delayed and inverted copy of itself to generate a short low going strobe pulse for SH/nLD immediately after the falling edge of /SS.   You also have tristating the final data out to take care of if there are other SPI inpuut or IO devices and you may want to run /SS to all the ClkInh inputs to stop them shifting when not selected.

Using De Morgan's laws, the OR can be replaced with three gates from a 74HC132 quad Schmitt input NAND, + a RC network to implement the whole strobe pulse generator circuit.  Populate it on the first board, and jumper it out on subsequent boards in the daisychain.

What is:

strobe pulse for SH/nLD

[Ian.M]

The people just strobing the '165s to latch their inputs then shifting in the result aren't trying to use them with multiple SPI slave input or I/O devices  The alternative to the circuit I  mentioned to generate the strobe pulse from /SS is to provide a separate strobe from another pin of your MCU.

SH/nLD is SHIFT / not(LOAD), the pin that when taken low transfers the inputs to the shift register.   Different manufacturers datasheets will use different names, but they are all functionally equivalent for any 74xx165.

[ilium007]

The people just strobing the '165s to latch their inputs then shifting in the result aren't trying to use them with multiple SPI slave input or I/O devices  The alternative to the circuit I  mentioned to generate the strobe pulse from /SS is to provide a separate strobe from another pin of your MCU.

SH/nLD is SHIFT / not(LOAD), the pin that when taken low transfers the inputs to the shift register.   Different manufacurers datasheets will use different names, but the are all functoionall;y equivalent for any 74xx165.

If I did use a seperate pin on the MCU as a seperate strobe wouldn't I end up back in a fanout issue with *many* PISO shift registers ?

I think my problem is at present I just don't understand the problem I am attempting to fix ! I don't understand the timing issue that requires this delayed strobe pulse.

I am trying to find anything on the internet at the moment that explains it but it seems as though no one else has documented this issue !

[Ian.M]

You need to latch the inputs with a brief low going pulse before you can start shifting the data into the MCU.  Unfortunately that's not how the timing of a SPI /SS signal works as it stays low for the whole transfer in a multi-slave setup, + you need it low for the whole transfer to drive /OE for the tristate buffer on the last shift register's data out.   

You deal with the fanout issue by buffering it every few shift registers down the chain same as you did for the other signals apart from the serial data.

[ilium007]

I am going to have to try and draw it up. I am totally confused now. I am also looking at the SPI library (https://github.com/PaulStoffregen/SPI) and I don't know whether it is controlling the SS pin when the SPI.transfer is called.

I had no idea it was going to turn into this level of complexity.

[Ian.M]

See https://www.pjrc.com/teensy/td_libs_SPI.html#ss for dtails of how to handle the /SS pin driven by a Teensy master and the rest of that page for Teensy SPI in general.

The level of complexity is dependent on how much 'stuff' you have on the SPI bus, and also how expandable you want to make it.  A couple of '595s and '165s off a 5V Arduino(ish) board is fairly trivial, as the fanout permits them to be driven direct, and no level shifters are required.

[ilium007]

Can we work through one section at a time ? Output buffers first ?

Left block - shows the MCU board buffer being used for 3.3v to 5v level conversion, its OE pins tied to GND as it is always enabled. 4th buffer input tied to GND as it is unused. SRCK, RCK(SS) and MOSI buffered.

Middle block - RCK being used for SS / OE on buffers. SRCK, RCK(SS) and MOSI buffered. SRCK and MOSI with pull down resistors to set idle state when buffer is disabled by RCK.

Right block - represents xx number of output boards. Each one with SRCK, RCK(SS) and MOSI buffered.

Is this what we have spoken about to date in this thread ?

All components are numbered to allow reference to any mistakes.

**schematic was wrong - see post below**

[ilium007]

My previous schematic was totally wrong.

If I use the SS buffer OE ping tied to GND on the output board that buffer will always be active, I then pass the SS signal in to the first board and it gets buffered along the chain.

This SS buffered output is then used for the OE pins on the other two buffers:

[C]

Think about your last drawing

If you had a 5V SPI display you could share MOSI & SCK
But you would need a SS for a 5V display

If you wanted to use two sets of boards chains you would also need an additional SS so you could select chain one or chain two

So on your MCU output buffer
SS should be labeled SS #(n)
the un-used pin 2 could be a second SS #(n)

[ilium007]

But the schematic is correct yes ? I could cascade a bunch on TPIC6C595's off the end of the first one and then, as you say, have another SSn connection for, say, a display. I send SS1 HIGH (the cascaded boards) and bring SS2 (for the display) LOW. This was the MOSI, SRCK and SS are in tristate for the cascaded boards and SS2 brings the display online and it shares MOSI and SRCK from the MCU board.

I have 2 x TPIC6C595's running off a 74HC125 in front of me based on that schematic. I don't have another SPI device as yet to test the other use case.

In the diagram the "MCU OUTPUT BUFFER" sits on a seperate PCB to the cascaded TPIC6C595 boards. The buffer on the MCU board is doing 3.3v to 5v level conversion as well as assisting in reducing fanout issues for whatever amount of SPI devices I have connected to the SPI bus.

[bson]

For MRR use I'd look into CANbus.  Single wiring loop, addressable devices, priority transmission, broadcast mode (nice if you want to tell everything on the bus to reset! now!), can handle lots of devices, good noise immunity, well understood, and something pretty much every scope and USB LA can decode.

http://openlcb.org/openlcb-and-lcc-documents/layout-command-control-lcc/

If I were you I'd latch onto that!