What is the maximum number of cascades for the 74HC165 IC?
idbruce
Posts: 6,197
Hello Everyone
I have been searching various datasheets pertaining to the various packages of the 74HC165 parallel-in/serial-out shift registers, and so far, I have been unable to find any information pertaining to the maximum number of devices that can be cascaded. Does anyone know the answer to this question?
Additionally, is there any other device that is better qualified for tracking a high number of inputs? Cost wise and/or IO pin wise.
Bruce
I have been searching various datasheets pertaining to the various packages of the 74HC165 parallel-in/serial-out shift registers, and so far, I have been unable to find any information pertaining to the maximum number of devices that can be cascaded. Does anyone know the answer to this question?
Additionally, is there any other device that is better qualified for tracking a high number of inputs? Cost wise and/or IO pin wise.
Bruce
Comments
Okay, well, as I recall there is no theoretical limit as the cascade is essentially a bucket brigade. I'm sure there are practical limits due to power supply, power glitching, fanout to the clear or latch or other control pins, and so on. Flip flops and shift registers aren't the most quiet things you can add to a circuit.
-- Gordon
Sort of bucket brigade in a chip...
I'm curious as to how many '165's you were thinking of driving.
If you use 16 bit registers rather than 8 to get around some fanout, you'd need 2000/16 = 125 chips! So fanout is certainly a problem without drivers for the clock/latch lines. 10-13 drivers would be needed? Or perhaps use multiple Prop pins if overall current consumption for the Prop is not too high.
Can the sensors be multiplexed at all to reduce the sheer number of external chips required?
Whoo boy, Bruce... seems like time invested in image processing software or getting Qcode stickers on the product might be just as time consuming but lead to a simpler, more elegant solution. I mean, it could be simpler to have a cheap camera hooked up to a portable running Android to read codes or do image processing. What about a simple but long/high gantry for moving the camera to do scans if need be?
Presuming you've been asking in relation to this thread: http://forums.parallax.com/showthread.php?142737-Reading-A-Massive-Amount-Of-Inputs-With-The-Propeller
each HC165 only sees one other, so they individually have no idea how many others there are.
Of course CLK and PL are usually parallel, so 1000 parts could need a 3.5nF clock driver (chip cap alone, add cable/pcb),and if the data reply from the furthest chip has a long way to come back, that also need a high C driver.
A number would help here ?
Depends what you want to do. MHz ? bits ? Ip? Op ? Diagnostics ? Self test ?
HC165 (et al) are a floor-sweeping price, but they are also brain dead, and the wiring/pcb.test costs may swamp their apparent low pin-cost.
They have no pull ups, and no read back, and no choice of IO mix, but are very easy to understand.
We have used CPLD/SPLD for IO tasks, where they do have pullups, and can give some read-back, and a choice of IO.
Small micros are also getting cheaper, but are harder to slave at high speeds.
eg I see a STM8S003K3T6 is 32 pins, 28io, at 49c/10k
Considering that this document specifically relates to problems associated with cascading the 74HC165 IC, I thought it would be appropriate to include a link to it within this thread, just in case someone encounters the problems that this document clearly defines. Although it is intended for automotive applications, it might be of use and importance for non-automotive applications:
Bruce
iirc this chip will connect to your i2c bus and give you 16 gpio expansion pins.. if you need these inputs to acquire hi speed data than this probably wont work for you but if not im pretty sure this solution gives more bang for the buck and is easier to use. i would think your gpios would be as fast as your i2c clock but youll have to look into that.
lemme know what you think as im curious myself
i2c is a chainable bus so i think this will give you max number of i2c devices per bus * 16 pins * acual i2c buses. im not sure how the mcp23017 works as far as master slaving
Let me begin by saying that I appreciate your input, however I have several days into my investigation of the 74HC165 and what I want to achieve with it. Additionally, I have several 74HC165 chips laying around, so I think I will begin with those.
My plan includes a massive amount of inputs and to my knowledge, the best way to achieve that is through cascading. According to Gordon in an earlier post, he states that the maximum number of cascades for the 74HC165 is 42 devices, which would provide 336 inputs. I don't know how practical it would be to cascade 42 shift registers, but the number was provided.
As for the mcp23017, the documentation page states that the maximum cascades for the device is 8, which would provide 128 inputs.
Bruce
As he said, there's no practical limit to cascading them. What you'll run into is just speed issues; every stage takes longer for signal propagation, so you'll have to run at a lower clock.
Now that's funny And I thought he was being serious. LOL
Yea, I imagine it will take some serious experimentation to discover the basics of obtaining a large number of inputs.
Bruce
http://forums.parallax.com/showthread.php?142737-Reading-A-Massive-Amount-Of-Inputs-With-The-Propeller
Yea, I took a peek at Leon's CPLD thread, which was quite informative, and I was going to compliment him on a job well done, but I quickly lost the desire to compliment him
Bruce
There are other techniques:
1. With sets of 4 MCP23017s, (64 pins), the third address pin could be used as a chip select. A 1 of 8 decoder would give 512 pins consuming 5 prop pins.
2. With sets of 4 MCP23017s, (64 pins), the third address pin could be used as a chip select. A 1 of 32 decoder, (4 * 1of8) would give 2048 pins consuming 7 prop pins.
3. With sets of 4 MCP23017s, (64 pins), the third address pin could be used as a chip select. And a simple shift register to output the 32 chip selects.
Duane J
The real answer is it depends. Further up this thread, fanout is mentioned, but if you are cascading these to create a very large number of inputs your fanin is one for the serial in and fanout is one for Q/Qh. With the exception of the SH/LD pin which is the parallel load and will have a fanin of one For the selected Logic Family, more or less depending what type is driving it. If you used say a 7406 open collector inverter that should drive quite a few of these lines. Same for clk and inhibit lines. Perhaps as critical will be the amount of time you will allow for reading all of the sensors via the shift register as you will need N*tck sec of time to read in all bits cascaded. You would have to pulse the parallel load line then shift n times to get the inputs. Also, there is no reset pin on these so you need to completely read out the register to return to a known state for all latches.
So hopefully I have not beaten the obvious to badly, but short answer is your cascade will be limited by the fanout of the chip driving clk and sh/ld. Drive these using say an AS and you should do okay. But you can look at the data sheets and calculate fanins and fanouts. Can the driving outputs sink or source the amount of current required by the sum of the driven inputs. Also watch out for the effects of capacitance at the high frequency end. Since you will be clocking these in parallel, propagation delay probably won't be a problem. Just how much time you can allow to shift all positions. That time less a fudge factor divided by the number of bits should get a good ballpark minimum clock frequency.
From a table in "The Well Tempered Digital Design, R. B. Seidensticker" 74xxx can drive 10 74xxx or 40 74LS inputs. 74ALS, only 2 7400 inputs (book says 2.5, but never seen a half input).
FF
Instead of having a single hub with thousands of inputs, why not make up intermediate hubs, maybe with a small microcontroller similar in capability to the SX line.
Let the intermediate hubs each input a much smaller number of inputs, say 32 to 64, combine the readings into a data packet, then forward that data packet to your main hub.
If the intermediate hubs could also forward data packets from other hubs then you'd be able to make up a net of these hubs, expanding any area with more intermediate hubs anytime you needed more inputs at any one location.
This would reduce a large problem to a much more manageable size, but be expandable to to the size you eventually need.
I must apologize for not getting back to this thread much quicker.
@Duane
I understand your point, however I was just going with the terminology and stated limitation from the product information page. In reality the MCP23017 sounds like a nice chip. In defense of my use of the word, please refer to:
Hopefully I will have some time in the future, to discover the possibilties that can be achieved with CPLDs and FPGAs. I see now that Leons topic was FPGAs and not CPLDs.
@David B
Actually, that is exactly what I intend to do.
I forgot to respond to your last post. I appreciate the info. Thanks Frank
Bruce