In college, I was always told not to leave input pins floating on a device such as a 74HCT chip. I was told that the device might behave erratically if any of its inputs are floating.
I have the PIC16F684. One of its inputs goes to the data input of a shift register, and the other goes to the clock input of the same shift register.
On the shift regsiter, there's an RC circuit on the master reset with a charge time of about a microsecond (which is plenty slow enough to have it set to all zeroes initially).
When the PIC boots up, all of its IO pins are set as inputs initially. What I'm concerned about though is that shift register's input pins must be either high or low, so I'm wondering if I'll get erratic behaviour at the very start because the pins are effectively floating?
Unless the shift register has a reset pin which you're asserting in the power-up sequence, it will probably be in an indeterminate state due to both power-up and to the floating inputs. Even if it has a reset pin connected to the PIC reset, once that reset goes inactive the chip could end up having a bit shifted into it because of the floating inputs. Once your code has set the PIC pints to outputs you can shift the proper startup data into the SR as part of your I/O initialization code. If this brief indeterminate state is unacceptable to your hardware (like it turns on the Giant Laser of Doom) then you have to add additional hardware to either keep the shift register in reset or to go between the shift register and the GLoD to keep the outputs in a safe startup state, all until the PIC is up and running and in control of things.
In my college project this year, what I did was give the shift- register's master reset a much longer RC charge time, somewhere like
50 milliseconds. This gave me enough time to boot up the PIC and set the pins to outputs.
No to play devil's advocate here, but who's to say that master reset will work properly if all the other inputs are floating? I've been told you can't rely on a chip's behaviour if any of its inputs are floating.
I still haven't figured out how long it takes the PIC16F684 to boot up so I guessed it to be about 20 milliseconds. If anyone has exact figures I'd be appreciative :-D
Yes, that would work. Just make sure you're not trying to set the SR to some startup state while the reset is still asserted. You'll either have to wait long enough to guarantee worst case that the SR reset has been de-asserted, or you'll have to read the reset signal and wait for it to de-assert.
I would be astonished if a reset pin didn't actually reset the chip, assuming only proper power to the chip. But if we're talking GLoD territory here, then you may have to prove that to your own satisfaction.
Another thing to consider is that there is a period of time at power-on when the power has not yet stabilized to a level within the guaranteed region of operation. Parts can get up to mischief during this time (and there is an often much longer duration period at power down that novice designers sometimes fail to consider). As far as the few tens of msec on power-up, it's usually not a concern (for one exception, it could greatly increase power consumption for a brief moment and cause a very low power battery powered device being supplied by a nearly dead battery to fail to start- perhaps some times and not others).
If you're concerned about it you can use pull-up or pull-down resistors. If you have a supervisory/reset circuit that is guaranteed to hold the proper state at the LOWEST possible voltage where 'trouble' can occur, then the combination of that, hardware reset on your SR and pull-up/pull-down resistors should be enough.
To use Mike's example, suppose your SR drives a relay which controls your home-built giant rooftop chemical laser focused on a nearby orphanage. The relay is guaranteed not to pull in below 3V. Your SR and supervisor is guaranteed to hold the SR outputs low above 3V, all the way up to 5V. After a couple hundred msec delay from your supervisor circuit your PIC clock will be up and running in a stable fashion, the clock and data pins will still be pulled low (say) by the resistors (and driven high-Z by the low /MCLR input controlled by the supervisory circuit, and the PIC will start up and take over driving the pins low after the program starts running and sets the ports & data direction registers (TRIS). On the way down, the supervisory circuit will immediately drive /MCLR low and drive the SR outputs low as soon as the voltage drops below its threshold (which should be higher than the minimum voltage the parts will operate at), and keeps it there at least until there's not enough voltage to pull in the laser control contactor. Of course you'd probably want to add a bit more circuitry and more safeties in an actual safety-critical system, or even if it was 'only' data that could be corrupted.
In general, simple RC circuits are not a good idea unless you don't really care if the thing works every time.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Why can't you just measure it? As soon as the CPU start executing code, toggle a pin from low to high to low. No matter what state the pin was before initialization, you will get an edge from this sequence.
Do you use an external reset of any sort? Many CPUs do not generate a reliable internal power on reset, even if the data sheet claims it does.
A couple of 100K pullups or pulldowns should eliminate your doubts. The 100K value is subject to change if the PIC pins have internal pullups of their own.
If you are driving LEDs with the Shift Registers, what difference does it make to have random outputs for a few milliseconds? Noboby can really catch it anyway.
Brilliant solution, thanks! I never really understood how pull-up and pull-down resistors work but I put thought into it just a second ago and realised how they work!
My stopwatch only measures accurate to a tenth of a second, plus my reflexes aren't quick enough to stop it accurately.
Seriously though what kind of device would I use to measure this? I'd need it to start measuring from when power was applied and get it to mark when the pin goes high.
Yes, but does it really matter. We expect something strange at startup anyway. Everytime I plug in a header, the outlet flash. Is something wrong with my heater or the outlet?
Shift registers are 'plain dumb' so even if they DO get bit-confused, they can always be flushed. Send it 8 (or whatever) clocks, and you now KKNOW what state it is in.
Read the data, and check your Reset Timeconstant. Some micros have a clock-stabalise counter, that additionally delays reset exit, others (like the 8051) are out of reset in 2 clocks, and starting your reset opcode. RC clocks havs very fast start times, Xtals, and especially Clock crystals, take longer to get going.
Well, for the devices we build at my place of work, random flashing at power-up like that would eventually put us out of business. Customers will not accept such glitches, period.
Well, the difference is that there you're switching a couple kilowatts at 100+ volts, i.e. it's quite unavoidable that there will be some sort of spark. That's a whole different story from a multi-MHz microcontroller apparently failing to keep a measly 100 mW LED from turning on for a hundred thousand CPU cycles' time.
I can't image what application would be so mission critical at power up, but I'll take your words for it. For us, we only power up the device once, when we install the batteries. The power button is really talking the uC out of standby. Our device goes into standby after 2 minuties of idle time. That way, a button cell battery can last for a few hundred days.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.