Hello.


I know that pull- up or pull-down resistor is used to prevent the digital input from floating. I would like to ask you if I need to add pull down resistor on my circuit.
The API code is generated for Microcontroller to return 0 or 1 value to control the demultiplexer. Demux is active low. So, If MCU return the low(0) value then, demux will perform its job. The high (1) signal from MCI would set the demux off.



Mods Note:
Please upload the image or circuit with *.jpg, your uc.png file size of circuit as 280Kb and already to cut it and converts to the .jpg as 38KB.

 

hi,
Welcome to AAC.
If the Enable pin is permanently connected to the MCU Output pin, a pull or down not usually required.
E

 

Thanks for the reply.

Yes, the Enable pin is permanently connected to the MCU output pin. But, MCU controlled by API will return the value of 0 or 1.

 

hi,
If the MCU is an Output and the MCU is powered, the Output pin can only be Hi or Low, ie: 1 or 0... so it should never 'float'.

E

What is the Demux type.?

 

Its 1 to 8 demux. it will be used as a 1 to 8 switch.

 

hi,
Should be no problem, as I said in Post #4.
Do you have any other query.?
E

 

If mux enable is tied to GPIO, most processors these days power up with GPIO
in Hi Z state, so enable pin logic level is undefined for external mux until processor
starts executing code and there is code to set the state of the GPIO pin. Need for
pull up or pull down is important.

Regards, Dana.

 

so enable pin logic level is undefined for external mux. Need for pull up or pull down is important.

hi danadak,
I do not agree.
I have connected many demux/mux units to MCU output pins and I have never found a pull up or down is required.
The operation of the MCU program is so fast that the Output pins are set almost instantly.
E

 

hi danadak,
I do not agree.
I have connected many demux/mux units to MCU output pins and I have never found a pull up or down is required.
The operation of the MCU program is so fast that the Output pins are set almost instantly.
E

Startup times of a uP, especially ones on a xtal, in the 10's to 100 mS kinds
of range before predictable code gets executed and operation commences.

Yes, one can eliminate PU, PD, depending on whats downstream of mux.
But glitches for sure are possible with floating enable. Or floating levels on
logic inputs anywhere. In fact you get supply current spikes due to floating input
of CMOS totem pole while both N and P MOS on.

But good practice eliminates invalid logic levels. Especially in human safety
applications. An MP3 player you can get away with this, again depending
what is downstream of mux.

Regards, Dana.

 

hi danadak,
What you are effectively saying, is that every Output pin on a MCU has to have a pull up or pull down resistor, which is not correct.
I have been designing and manufacturing MCU based products for over 40 years, both for safety critical applications and general use and I have never had to fit a PU or PD on a MCU output to an on board mux/demux coder.
This applies to TTL and CMOS based MCU's

What is the source of your information.?

E

 

The devil is in the details.
Some MCUs have weak pullups on general purpose input/output pins.

One would have to analyze the consequences of a particular situation in order to determine the consequences of a floating input pin of an external component.

 

@ericgibbs

The source of the info is in startup section of UP datasheets, or
in their ancillary ap notes/faqs.

Its a fact that many processors start up with GPIO in hi Z state -

1) Cypress PSOC
2) Microchip pins configured as inputs, hi Z

https://www.microchip.com/forums/m612543.aspx
http://ww1.microchip.com/downloads/en/devicedoc/31009a.pdf

3) MSP430 TI configed as inputs, hi Z
https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/345840?MSP430-GPIO-default-state

More general info from TI on floating CMOS inputs -

http://www.ti.com/lit/an/scba004d/scba004d.pdf

NXP comments on this -

https://electronics.stackexchange.c...-gpio-glitches-on-every-power-up-how-to-solve

I have seem some processor datasheets show a xy graph of unknown GPIO
pin state vs Vdd on the part. That is older parts do not guarantee any state
for GPIO until it hits some minimum. And I have seen more modern UPs that
guarantee GPIO will not glitch on power up, but that excludes the fact they
are all inputs Hi Z after hitting min Vdd....which then can lead to unstable attached
logic unless terminated by PU or PD. Until the code flips pin to output and sets
its state.

This topic came up at FAE training, several vendors, and various seminars,
to never assume that a floating input will produce a known state in logic. To
read specific datasheets, and contact vendor if not clearly stated. I got asked
this question as an FAE by many customer EEs on many vendors and in house
engineering sessions. Starting 1973. All early NMOS and PMOS CPUs notorious
for glitch I/O on power up. Same for early CMOS. Not so much anymore, as
long as terminated properly when in temporary Hi Z state.


Regards, Dana.

 

I am only familiar with mid-range PIC's. For those devices, weak pull-ups for a pin are disabled when that pin is set to an output.

Another consideration in the generic schematic is that some pins may be "open drain" and may need a hardware weak pull-up in order to shut the attached device down.

 

Post # 11 a sim done on slow input ramp with 10 mV of system noise
at input to CMOS gate.

https://forum.allaboutcircuits.com/...s-a-toggle-on-off-switch.157636/#post-1366747


Regards, Dana.

 

Post # 11 a sim done on slow input ramp with 10 mV of system noise
at input to CMOS gate.

https://forum.allaboutcircuits.com/...s-a-toggle-on-off-switch.157636/#post-1366747


Regards, Dana.

@ericgibbs
Having done dozens of microcontroller projects, I agree with @danadak to this extent: If during power up an I/O pin being in the open-circuit state can cause undesired operation of connected circuitry, then that I/O pin ought to have its state defined, during power up, by a pull-up or pull-down resistor. If the connected circuitry can operate acceptably during power up with any state of the I/O pin, then no pull-up or pull-down may be necessary.

 

We are at a bit of a disadvantage as the MCU has not been defined. The TS specifically asked about whether adding a pull U/D resistor was required. From the perspective of PIC's, one can ensure the states of most pins in firmware.

1) WPU's are enabled upon all resets, unless turned off.
2) The recommended sequence for initializing a port is:

Note, data latches are set before port direction is defined. Assuming a typical port and the enable pin that is in question, it will be held off (i.e., high) by the default WPU while the pin is in its default state as an input. If that sequence is followed, it will enable the device upon setting TRIS. Thus, it is hard to see a requirement for additional hardware. Of course, one could mess that up too.

EDIT:
@TeeKay6 Pointed out to me via PM that during reset, there is a phase where things are a little different than before the first instruction cycle is completed and a default state is set. That is, WPU's are disabled.

I found a statement to confirm that here:
http://ww1.microchip.com/downloads/en/devicedoc/31009a.pdf

Each of the PORTB pins has a weak internal pull-up. A single control bit can turn on all the pull-ups. This is performed by clearing bit RBPU (OPTION<7>). The weak pull-up is automatically turned off when the port pin is configured as an output. The pull-ups are disabled on a Power-on Reset.

It seems to be well hidden as chapter 3 of the same instruction document says nothing about it. The DS for the 16F1829 doesn't include that statement either.

So now, I will put a wpu on any pin attached to an \( \small \overline{EN} \) for a 100 megaton bomb trigger.

 

hi Dana,
I am aware that all the I/O MCU pins, on some MCU's at start up in Hi-Z state until set by the program.
In order to ensure that ALL the pins are at the 'safe' condition for all of the peripherals connected to the MCU, would mean adding PU or PD resistors to every Output pin of the MCU.

Even if the Pull resistors were added the output pins would not be set by the program at the same instant, so these 'glitches' would occur in parts of the logic pathways.

The points put forward in post #12, demonstrate clearly that due to the wide 'spread' in switching state timings in the MCU and the connected peripheral logic, a system cannot be glitch free during the few microseconds of power boot up.

I too have been designing and building commercial MCU based systems since the early 1970's and have never had to use a pull up/down resistor on a MCU output pin connected to a Mux/Demux.

Adding PUD's on a MCU Output pin would be decided during the design phase, to suit the particular application, sticking a PUD on every pin 'just in case' s not a viable solution.

Eric

 

hi Dana,
I am aware that all the I/O MCU pins, on some MCU's at start up in Hi-Z state until set by the program.
In order to ensure that ALL the pins are at the 'safe' condition for all of the peripherals connected to the MCU, would mean adding PU or PD resistors to every Output pin of the MCU.

Even if the Pull resistors were added the output pins would not be set by the program at the same instant, so these 'glitches' would occur in parts of the logic pathways.

The points put forward in post #12, demonstrate clearly that due to the wide 'spread' in switching state timings in the MCU and the connected peripheral logic, a system cannot be glitch free during the few microseconds of power boot up.

I too have been designing and building commercial MCU based systems since the early 1970's and have never had to use a pull up/down resistor on a MCU output pin connected to a Mux/Demux.

Adding PUD's on a MCU Output pin would be decided during the design phase, to suit the particular application, sticking a PUD on every pin 'just in case' s not a viable solution.

Eric

I must be missing something, no where was there advocacy of PU/PD on ALL pins.
Just pins that can cause, due to logic and other design considerations, safety or
equipment damage or major malfunction if not terminated properly.

If a pin, glitching, does not cause any of the above no R's needed. But if it triggers
earths doomsday weapon that's probably unfortunate.

There are processor chips these days that over a ramp up of their Vdd
no, none, glitching occurs, holding their pins in TriState for the entire
power up cycle. Thats the good news. It also means that a PD is effective
on that pin, establishing a known state. Of course PU, its own terminations
ramping, inherently does not have a consistent state as its Vdd is ramping.

So one designs to these constraints.

Personally I am for setting off the doomsday weapon, I see no viable future
for the human race based on its past performance when compared to all the
other earthly creatures that do not consistently destroy their own nest as
humans have a propensity to do Take your pill Dana.


Regards, Dana.

 

OK gents, let's knock it off now.
There is no definite answer until the TS states both MCU and MUX part numbers, supplies complete schematics, and provides the total functionality of the design and application.