So the c.o. is a side effect of the architecture?
Yes, and how the flip-flops are connected in a ring to circulate a pattern of ones and zeroes. I haven't verified this, but the pattern is supposed to be a Grey Code, which means on each clock transition only one bit in the pattern changes. Not that you should care: the end-user does not have access to the internal states of the five flip-flops, only their decoded states 0, 1, 2, ... 7, 8, 9 plus the carry output.
If you wanted to use this as a decade counter, would you then have to simply watch and trigger on the rising edge between bit 9 and 0?
It
is a decade ring counter, decoded for your pleasure and convenience. Connect the carry output (pin 12) to the clock input (pin 14) of the next decade. You can continue this indefinitely for as many stages as desired. However, with this method the stages are clocked as ripple counters, and you may not want this for long count lengths because the counters are more susceptible to noise. Extra external logic
could be used with the clock-inhibit input to disable the extra counters and clock them, in parallel with the input clock to the first decade counter, but only during decade transitions. I don't know that anyone has actually gone to this much trouble to ensure synchronous internal bit transitions across multiple counters, but it is certainly something to consider if there is a long counter chain where the carry output remains in a vulnerable-to-noise low state for extended periods of time. Besides clock skew, which limits the upper counting frequency, susceptibility to noise on a "clock" line with a long cycle time is a big disadvantage of ripple-carry clocking of successive counters.
Imagine, if you will, that you have a very low-level light sensor, a photo-multiplier tube perhaps, that responds to single photon events. You count these events with a string of CD4017B decoded decade counters arranged for ripple-carry clocking. The count accumulates for a specified interval, typically a few seconds to perhaps several hours. The final count is a function of the light intensity you are measuring. What are the chances that during this counting interval a noise pulse will advance one of the more significant digits of the counter? With a good design and layout, perhaps the chances are small. But if it is important to obtain an accurate count over a long period of time, it would be better to disable the more significant counter digits until it is actually necessary for them to change on the next (relatively narrow) clock pulse. There are synchronous counters (both binary and decade) that make it easy to do this.
Another common application for the 4017 is to extend the "walking ones" output to more stages. The
TI datasheet,
Fig. 19 - Cascading the CD4017B, has an example of one way to do this. TI does It by inhibiting the clock to the first stage when it reaches a count of 9. Thus the first stage counts 0, 1, 2, ... 7, 8, 9 and stops on 9. The common clock line for the remaining 4017s is passed through an AND gate to allow each of those stages to be clocked, but only when the preceding stage has reached a count of 9. Thus each additional stage will count 0, 1, 2, ... 7, 8, 9 and stop on 9. As each 4017 stage reaches its count of 9, this is fed back to raise the active-high clock inhibit input to a high state, disabling that particular 4017. The last stage has its decoded "9" output fed back to the reset input of the first stage, causing it to change from 9 to 0. The decoded "0" output of the first stage is applied as a reset to the next stage, which repeats the process by resetting the next stage, and so on until this ripple-propagated reset reaches the last stage. There may be some problems with this design as the internal flip-flops of the ring counter could come on with random states, requiring some sort of power-on reset to ensure all stages are reset to zero before beginning counting. Notice too that the "0" count is not used in subsequent stages, so each stage has only eight distinct outputs: 1, 2, 3, 4, 5, 6, 7, and 8. The "0" state is always on until that stage is clocked, and the "9" state stays on when it is reached until that stage is reset.
If you are thinking of using the CD4017B to implement the "21" game that
@Rich Man offered up in
this thread... well, I can think of better things to do with my time. But you could steer twenty outputs of three counters through small-signal diodes to enable "computer" clock pulses that would advance the display the requisite number of times, each time the "computer" makes its move. In other words, wire the diodes to implement the logic on the stepper "locking deck" in the image that
@73's de Edd posted in reply #7 to that thread.
Ummm... is the sawdust collector operational yet?
Hop
