74HC4051 v CD4051BE read speed

Other Hardware General Electronics
1

Greetings.

I'm working on a model railway project where I need to have a number sensors to identify which lengths of track are occupied by a loco.

To minimise the number of arduino pins I need to tie up I'm planning to use a multiplexer, either a 74HC4051 or a CD4051BE. This could later be extended wth more channels as the layout grows. The arduino will be doing a lot more than just reading these sensors so I want to minimise the time this process takes

My problem is twofold:

a) How fast I can address and read each channel -- I understand the the 74HC4051 is much faster than the CD4051BE so this would cause less overhead in the entire process. What I can't identify is how much faster.

The TI spec sheet for the CD4051BE shows a Propagation Delay Time -- Address-to-Signal OUT (Channels ON or OFF) of 450 - 720 ns for a 5v system.

Allowing for the time to write the addresses and process each reading I'm reckoning on about 1ms per channel per iteration.

Unfortunately I've looked at various manufacturers' specs for the 74HC4051 and can't find an equivalent entry for the 74HC4051. Is it likely to be of the order of ten times as fast? This will become more significant in a bigger layout with more tracks.

b) Given the time it takes from writing the third bit of the address to getting a stable output from the MUX common pin is there any way I can avoid just putting in a delay time or a timing loop while waiting for the signal to stabilize? I can't think of any. Of course, using a faster device would at least minimise this.

Albert

2

https://www.digikey.com/product-detail/en/texas-instruments/CD74HC4051E/296-12810-5-ND/475938

Look at 6.7, 6.8 of the datasheet.

Are you reading analog signals or digital signals?

3

Hello Albert,
You are worrying about the wrong thing, the speed of those chips is fast enough. The problem is how you write your code. Find the tutorial:
Demonstration code for doing several things at once
And understand it. Using millis for timing is useful too. Also in the IDE the first 5 examples under 02. Digital, not to mention the numerous similar questions and answers if you read through these fora.

Your code should have a background process that reads the inputs through the multiplexer and separate, concurrent code that deals with the results.

4

CrossRoads:
CD74HC4051E Texas Instruments | Integrated Circuits (ICs) | DigiKey

Look at 6.7, 6.8 of the datasheet.

Are you reading analog signals or digital signals?

Thanks.

Digital signals derived from processing analogue upstream.

Looking at the two data sheets they unfortunately don't word things in quite the same way, but I think that 'Inhibit-to-Signal OUT (Channel Turning ON)' (CD4051BE, 6.5) is equivalent to the entry for 'Switch turn-on (S or E)' (74HC4051, 6.7) in which case the 74HC is of the order of 10-20 times faster and with some other processing going on I would probably not need to insert a delay or use a timing loop.

Cheers

Albert

5

PerryBebbington:
Hello Albert,
You are worrying about the wrong thing, the speed of those chips is fast enough. The problem is how you write your code. Find the tutorial:
Demonstration code for doing several things at once

Google couldn't find that, but did come up with

'Demonstration code for several things at the same time' (Demonstration code for several things at the same time - Project Guidance - Arduino Forum)
Is that the one? It rapidly degenerates into a discussion of programming style preferences.

And understand it.

Using millis for timing is useful too.

That indicates that you think working at that time scale is 'fast enough'. I have reasons for wanting to be able to do readings faster than one per millisecond.

Also in the IDE the first 5 examples under 02. Digital, not to mention the numerous similar questions and answers if you read through these fora.

Your code should have a background process that reads the inputs through the multiplexer and separate, concurrent code that deals with the results.

6

'Demonstration code for several things at the same time' (Demonstration code for several things at the same time - Project Guidance - Arduino Forum)
Is that the one?

Yes, that one, it's important. Ignore any degeneration of the discussion, just learn from the initial tutorial.

Apologies for the incorrect reference, I am on holiday working on a mobile phone, which makes copying, pasting and just about everything else that's easy on a full size computer that bit more awkward.

That indicates that you think working at that time scale is 'fast enough'. I have reasons for wanting to be able to do readings faster than one per millisecond.

Perhaps you do, but unless you share them we can't take them into account. However, you mentioned locos on track and I cannot imagine any reason to read their positions on tracks at sub millisecond time intervals. How far can a loco move in 10 or even 100ms?

7

In the millisecond range, the CD4051 is perfectly adequate. In the microsecond or hundred nanosecond range it might be a problem.

But that series is obsolete; its only application is when you are switching logic voltages greater than 5 V, up to 15 V. So it isn't really a meaningful question, always use the 74HC version. :roll_eyes:

8

If you are reading analog signals the ADC speed will be your bottleneck. If you are reading digital signals use a digital device - preferably a shift register like '165.

9

Hi,
What model Arduino controller are you using and have you written code to see how fast or slow you can read an array of inputs?

Are you using delay function?

How fast is your model layout that you are worried about ns?
You may be over thinking your project.

Can you please tell us your electronics, programming, arduino, hardware experience?

Thanks.. Tom... :slight_smile:

10

PerryBebbington:
Perhaps you do, but unless you share them we can't take them into account. However, you mentioned locos on track and I cannot imagine any reason to read their positions on tracks at sub millisecond time intervals. How far can a loco move in 10 or even 100ms?

Given enough track blocks then it's the total number of readings that is the problem. In my development layout I'm only working with 8 blocks but in any non-trivial setup there would be more. Add in a possible need to debounce and a definite need to handle the times when a loco may be bridging two blocks at the time of taking a reading and needing to repeat reading that pair of blocks to allow resolution of the situation I'd rather not work on the basis of needing a millisecond per reading.

I appreciate that your reply was probably mostly intended to address my second question about avoiding timing loops or delays. I had already considered using some other process (such as reading spot sensors) as a way to make use of the time between writing the MUX address and having a stable reading. The tutorial you linked to will give me some help in planning that sort of thing.

The problem is that all the logic for controlling the operation of the layout depends on these readings of the occupation status of the track circuit blocks, plus various spot sensors. At a scale speed equivalent to about 60mph a loco can move roughly its own length in about 1/3 of a second, so I would prefer to have the entire process of taking all the readings and then making decisions and adjusting PWM settings, setting signals etc. based on them to be at worst in the 100ms range. If I can reduce the time overhead for taking each reading by changing from one multiplexer to another that is a very easy and worthwhile fix.

Albert

11

Smajdalf:
If you are reading analog signals the ADC speed will be your bottleneck. If you are reading digital signals use a digital device - preferably a shift register like '165.

I'm reading digital. The detector output is analog but this is processed to a digital signal in hardware upstream of the Mux.

Thanks

Albert

12

Thanks to everyone for the input.

13

I re-read reply #9 carefully, as I'm not sure in what ways it responds to the replies to your question. I imagine you will not want to hear this, but I believe you are still burdened with serious misconceptions about the timing requirements. For example, you say:

I had already considered using some other process (such as reading spot sensors) as a way to make use of the time between writing the MUX address and having a stable reading. The tutorial you linked to will give me some help in planning that sort of thing.

The time between writing the last (since bits are written individually with digitalWrite) MUX address bit, and having a stable reading, is in this scenario equal to zero. That's with either the CMOS or the HC part. It is because at most about 10 processor cycles can be executed during that time. It takes more than that, just to return from digitalWrite, and call digitalRead(). So, it is a distracting and unnecessary idea to "do things while" that happens. You do not need to debounce the MUX, only the inputs.

You mention debounce in passing. I suppose you visualize that each debounce must follow another, but that is not the case. If you have 1000 inputs, you can debounce them all at the same time. If the debounce interval for that is 20ms, it will take you about 20ms to debounce them all, not 20ms * 1000 = 20 seconds.

The last paragraph is puzzling, because it actually holds some hope that you realize that the MUX is not at all a problem, and offer what is generally (although vaguely) a working plan. However you state a problem there, that really isn't. It is true that the program has to monitor input states, but you seem to be vastly overestimating the difficulty of achieving that.

In the same paragraph, you seem to be re-iterating that it would be worthwhile to increase the speed of the input regime. In fact, this is completely wrong. The input logic is already orders of magnitude faster than what you need (don't tell me I don't know what you need, because I have been focusing on track occupancy projects almost exclusively for several months now). That is why you got responses talking about locomotive speeds.

If you are worried about wasting processor time while debouncing, don't. If you write non-blocking code, you can be doing basically anything while that goes on.

Changing to a faster MUX chip is neither worthwhile in the sense that it would improve the program performance in any way, because it can't. However, you will find the HC part cheaper and easier to obtain.