Cascaded 4040 (rev.)

G

georgedb

New Member
Hi,
I wanted to check the working of a cascaded 4040, as I need to have more address lines and a 4040 can only address A0 - A11 (or Q1 - Q12). My idea was to connect A11 to the CLK-input of a next 4040. While searching for a similar question, I came across https://www.electro-tech-online.com/threads/cascade-4040-ripple-counter.152204/ (closed, it is 7y old...).

The TS pictured exactly what I had in mind, but a moderator fixed an error in it. I'm trying to understand what was fixed... I'd say as soon as Q12 becomes '1', this is the input for the CLK of the 2nd 4040 and Q1 there becomes the new Q12 (and becomes '1'). I'd say what the moderator fixed is that and A11 becomes '1' AND A12 becomes '1' at the same time. I don't understand this, can someone please explain what I'm missing?

Cheers,

George
 
Sort by date Sort by votes
Nothing was missing or changed in the wiring except a label.

It was false to exclude the Q12 output in the label for A11.

You could call it Q1 to Q12 or A0 to A11, then Q13 to Q24 or A12 to A23
or anything you want. Just don't skip the cascaded last stage in the numbering sequence.

 
Upvote 0 Downvote
I'm afraid I still don't understand...
Your picture is the original picture of the TS? But where was the Q12 output excluded in the label for A11. I'd say A11 is Q1 of the next 4040.

I'd say the picture adapted by the moderator is faulty: the moment Q12 is activated (A11), at that same time Q1 of the next 4040 (A12) is activated (become "1").... I'm afraid I'm still missing the point.
 
Upvote 0 Downvote
Here is a side by side comparison of posts 1 and 2 from that thread. Notice the different position of labels A11 and higher.


A11 is the output from Q12 of U2. A12 is the output from the first divide by 2 stage of U3.

Please also look at and make sure that you understand the comments about ripple from posts 4 and 5 of that thread.
 
Upvote 0 Downvote
georgedb said:
...the moment Q12 is activated (A11), at that same time Q1 of the next 4040 (A12) is activated (become "1").... I'm afraid I'm still missing the point.
Click to expand...

A low-to-high transistion doesn't cause the cd4040 to do anything. All actions happen when the input goes from high-to-low.

Therefore, the second chip first sees an event when A11(Q12) goes low. The correction is correct.
 
Upvote 0 Downvote
ZipZapOuch said:
A low-to-high transistion doesn't cause the cd4040 to do anything. All actions happen when the input goes from high-to-low.

Therefore, the second chip first sees an event when A11(Q12) goes low. The correction is correct.
Click to expand...
I think that it the only plausible explanation! The moment Q12 of U2 transitions from '1' to '0', this is the clock change of U3 that transitions Q1 of U3 from '0' to '1'. I think it is clear now ;-)
 
Upvote 0 Downvote
It was just a labelling error. But if you plan to use this Async counter to decode multiple outputs to define a unique count, that would be a mistake even with one IC. Due to the asynchronous cascading delays, it would result in metastable errors (glitches).

To avoid those errors, you must use synchronous counters. However, if you only need a large count from a single output, that would be OK Each stage counts up on negative input transitions and Qn goes high after 2^n-1 input negative edges and Qn goes low after 2^n pulses. Hence why someone tried to show this by equating Q1 to A0 but then slipped up on A12 but also erred implying one could use these as A# labels for address compare or count unique values.

The states are only valid after all registers settle in the cascade which is undefined in the datasheet but you can estimate it by using the prop. delay for one stage and multiply it by the last stage used and factor delay by Vcc and temperature effects.
 
Last edited:
Upvote 0 Downvote
I think it was more than a labelling error, I think the TS who drew the original picture, made the same mistake as I did.

I'm not sure if I understand the concept synchronous and asynchronous when it regards a counter like the 4040. Would there be a better alternative?

My goal is to have just a simple clock input for the 4040 to generate the addresses from 0000000000000 to 1111111111111 in order to read every byte from an old ROM. As there are not enough outputs on a 4040, I was searching for a solution (cascading 2 4040's). A simple Arduino does not have so many inputs / outputs (clock, reset, 8 x data, 13 address). This seemed a solution and it is not timing critical. I'd say with some delay after generating each address, things should become stable?
 
Upvote 0 Downvote
I'd say with some delay after generating each address, things should become stable?

No this is false. You must wait for some predetermined propagation delays in each stage.

This can be made OK but some timing delay conditions.

If you take the 14th single output or Q2 on the 2nd IC, this can work if you slow down the clock.

But only if you use 12th counter output, Q12 as Clk2 in IC2 and Q1 Q2 become Q13, Q14.

Thus after Q14 goes high (some 5us after the clock edge), you must stop the clock process immediately and say "done". (or something like that)

The delay from Q14 going high after CLK1 went low depends on the IC delay. 14 stages each with delay shown below as 360 ns max. @ 5V, 25'C or Tdelay = 5 us. MAX.

This means your clock cannot go high for 5us before you stop the input clock count.

1. you must use the negative clk edge to latch the data into the Arduino ( or invert and use rising edge),
2. you must reduce the clock speed to a 10 us cycle or 100 kHz and both Arduino and 4040 clock on the same edge or something similar to prevent the race or metastable glitch and thus prevent memory transfer errors latch the data into the Arduino one < 180 ns so the Memory state stays the same from the previous edge and the memory is latched immediately in the Arduino.


Async. means Not Sync'd which means like a stadium "wave" and not every register is clocked by the same input rather from the previous stage only
.
Synchronous counter means every register uses the same input clock to sample the previous stage and uses many more gates.

There is a 10x faster version using 74HC4040 IC's but you are not in any hurry since I suspect this is a 1-timer\_ and we want a "controlled race condition" to be error free.
 
Last edited:
Upvote 0 Downvote
Do you want to use a serial input from the EPROM using 2 PISO registers or latch 2 bytes in parallel then MUX to 8 ports or what ??

There are easier ways called EPROM readers.
 
Upvote 0 Downvote
Thnx for the thorough explanation! I understand the concept and the delays when it regards an asynchronous counter like the 4040, but with all kinds of delays, I'm sure I'll be able to read valid data. I don't even mind waiting 500ms between every byte that needs to be read. Indeed it is a one time only solution.
 
Upvote 0 Downvote
danadak said:
What else is in design besides these counters ?


Regards, Dana.
Click to expand...
The idea is that the Arduino provides the clock, and maybe some logic to put the ROM in a certain mode in order to read the 8 data bits. With a serial interface, I can store the bits and once I have them electronically, I can process them in every possible way (make a .bin file, make a .hex file, etc.). So, as I currently look at it, partwise there is nog much more that needs to be used.
 
Upvote 0 Downvote
Tony Stewart said:
Do you want to use a serial input from the EPROM using 2 PISO registers or latch 2 bytes in parallel then MUX to 8 ports or what ??

There are easier ways called EPROM readers.
Click to expand...
I just connect the 8 data lines of the ROM to 8 inputs of the Arduino (I need to check for logic levels 3V3 vs. 5V).
There might indeed be (EP)ROM readers that could read these ROMs, but it is also the fun of trying to master this with parts I already have. I have one ROM of which I have a .bin, so I can easily check if my solution works.
 
Upvote 0 Downvote
If Q14 goes high, the ROM transfer is complete and the Q1 to Q13 addresses are back to 0's
If you want, check by read and compare with 1st byte to confirm you are still sync.
If using 3.3V on CD4040, then RdsOn increases sharply with prop. delay so choose > 10us read delay after each -ve clk pulse.
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

F
  • Question
Please help break the cascaded boost?
Replies
3
Views
3K
Flyback
F
  • Question
LM3915 cascaded dot/bar mode switch
Replies
2
Views
3K
humanNPC
C
  • Article
Grundig RR315 no fast forward/reverse but output fixed
Replies
0
Views
610
carolmaille
C
  • Question
Extending reversing sensors
Replies
8
Views
3K
camerart
J
  • Question
Reverse engineering an membrane keypad
Replies
9
Views
2K
Pommie
P
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…