Searching \ for '[PIC]: LED Blip on Power Up' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=led
Search entire site for: 'LED Blip on Power Up'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: LED Blip on Power Up'
2002\01\17@210252 by Sean Alcorn - Avion Sydney

flavicon
face
Hi all,

My 5th little PIC project is working fine thanks in part to all the
wonderful help I have received on this list. I had a lot of trouble on this
one, but decided to work it all out myself (no matter how frustrating it
got) and it's paid off for me. Stupid mistakes really - a BCF instead of a
BSF - D'ohh!

I have a slight glitch in this application which I do not think I can avoid
with software, but I thought I would bounce it off the list to see if there
are any suggestions.

Once again, I have a PIC12C508A (just love those little guys) with an LED
driven from VCC to Pin2 (GP5) and a relay driven with an NPN transistor on
Pin3 (GP4). Pins 4~7 are used as inputs.

So, given the above configuration, when I want the LED to be ON, I need the
drive GP5 Low and when I want the relay ON, I need to drive GP4 High. When
this application starts up, I need both the relay and the LED to be OFF

The beginning of my code (after initial equates etc.) is;

MOVLW   B'00001111'
TRIS    GPIO
MOVLW   B'00100000'
MOVF    GPIO
GOTO    CONFIG

This is as soon as I can set GP5 high, but I still get a very obvious 'blip'
of the LED. This application uses existing hardware, but I was considering
to invert the logic of the LED.

Before doing that however, I just wanted to ask if I was doing anything
wrong? The state of the port(s) on power-up is not known right? But they
seem (from my limited experience) more likely to be low than high. Can I get
the pin driven high any sooner or would I have better results by simply
inverting the logic for the LED and driving the Pin High when I want the LED
on?

Thanks in advance,

Sean Alcorn

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\01\17@212452 by David VanHorn

flavicon
face
>
>Before doing that however, I just wanted to ask if I was doing anything
>wrong? The state of the port(s) on power-up is not known right?

It SHOULD be an input, and not driving at all.

>  But they
>seem (from my limited experience) more likely to be low than high. Can I get
>the pin driven high any sooner or would I have better results by simply
>inverting the logic for the LED and driving the Pin High when I want the LED
>on?


Put a pull-down resistor out there, and see what happens.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\01\17@212737 by Jinx

face picon face
> My 5th little PIC project is working fine thanks in part to all the
> wonderful help I have received on this list.

Oh sure, I came for the technical help thing but stayed
for  the dress code

I'm not very familiar with the 508 (and its manual is currently
missing, presumed buried in paperwork) but do the POR
conditons of the F84 apply to the 508 ? If the pins are in
undefined states on power-up and the power-up timer (PWRT)
and oscillator start-up timer (OST) are in effect, that would
extend that undefined period, giving you the blips. Perhaps
a pull-up in parallel with LED might cure it

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\01\17@214953 by David Duffy

flavicon
face
At 01:00 PM 18/01/2002 +1100, you wrote:
{Quote hidden}

I normally set the GPIO first and then do the TRIS. This avoids the blips
although unless the clock is *very* slow, I wouldn't think that you could
visibly see the LED blip when the delay is only a few cycles anyway.

>This is as soon as I can set GP5 high, but I still get a very obvious 'blip'
>of the LED. This application uses existing hardware, but I was considering
>to invert the logic of the LED.

Maybe there is something else in the hardware that's not obvious without
a circuit that is causing it. Anything else hooked to GP5 ?

>Before doing that however, I just wanted to ask if I was doing anything
>wrong? The state of the port(s) on power-up is not known right? But they
>seem (from my limited experience) more likely to be low than high. Can I get
>the pin driven high any sooner or would I have better results by simply
>inverting the logic for the LED and driving the Pin High when I want the LED
>on?

Regards...

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\01\18@022417 by Dwayne Reid

flavicon
face
At 01:00 PM 1/18/02 +1100, Sean Alcorn - Avion Sydney wrote:
>Hi all,
>
>So, given the above configuration, when I want the LED to be ON, I need the
>drive GP5 Low and when I want the relay ON, I need to drive GP4 High. When
>this application starts up, I need both the relay and the LED to be OFF
>
>The beginning of my code (after initial equates etc.) is;
>
>MOVLW   B'00001111'
>TRIS    GPIO
>MOVLW   B'00100000'
>MOVF    GPIO
>GOTO    CONFIG
>
>This is as soon as I can set GP5 high, but I still get a very obvious 'blip'
>of the LED. This application uses existing hardware, but I was considering
>to invert the logic of the LED.

2 things.

1) even given the code above, you should NOT be able to see the LED
blip!  Its only on for a couple of usec - no way is your eye going to see it.

2) the easy way to fix the problem is to set the desired state of the port
pins while they are still inputs, then use TRIS to set the DDR.  No glitch!

I'd take a few minutes and try to see why you can see the glitch, then
apply the above fix.

dwayne



Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@045256 by Sean Alcorn - Avion Sydney

flavicon
face
on 18/1/02 4:33 PM, Dwayne Reid at .....dwaynerKILLspamspam@spam@PLANET.EON.NET wrote:

Dwayne,

> 1) even given the code above, you should NOT be able to see the LED
> blip!  Its only on for a couple of usec - no way is your eye going to see it.
>
> 2) the easy way to fix the problem is to set the desired state of the port
> pins while they are still inputs, then use TRIS to set the DDR.  No glitch!
>
> I'd take a few minutes and try to see why you can see the glitch, then
> apply the above fix.

See my later posts. The blip is not visible on plastic parts. Only windowed
types. No change to code or hardware.

Regards,

Sean

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@053943 by Jinx

face picon face
> See my later posts. The blip is not visible on plastic parts. Only
> windowed types. No change to code or hardware

AFAIK the JW and P parts use the same wafer and should be
identical. Try something more opaque on the window. Even a
little square of tin foil under the tape. Adhesive foil is best as
the glue doesn't go gooey like it does on masking tape. If you
haven't got adhesive foil on a roll, try the write-protects in a box
of 5 1/4" floppies

You haven't got a bent pin somewhere that's not in contact
with the socket ? eg 0V or MCLR

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@151919 by Sean Alcorn - Avion Sydney

flavicon
face
on 18/1/02 1:27 PM, David VanHorn at dvanhornspamKILLspamCEDAR.NET wrote:

Hi Dave,

How is the big sale to Asia going?

>> Before doing that however, I just wanted to ask if I was doing anything
>> wrong? The state of the port(s) on power-up is not known right?
>
> It SHOULD be an input, and not driving at all.

You mean the state on power-up?

>> But they
>> seem (from my limited experience) more likely to be low than high. Can I get
>> the pin driven high any sooner or would I have better results by simply
>> inverting the logic for the LED and driving the Pin High when I want the LED
>> on?
>
>
> Put a pull-down resistor out there, and see what happens.

OK, But given what you have said above, inverting the logic would also do
the trick, would it not?

Regards,

Sean

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@153952 by David VanHorn

flavicon
face
At 01:32 PM 1/18/02 +1100, Sean Alcorn - Avion Sydney wrote:
>on 18/1/02 1:27 PM, David VanHorn at .....dvanhornKILLspamspam.....CEDAR.NET wrote:
>
>Hi Dave,
>
>How is the big sale to Asia going?

Progressing.. Having my PC down for most of the week hasn't helped.

> >> Before doing that however, I just wanted to ask if I was doing anything
> >> wrong? The state of the port(s) on power-up is not known right?
> >
> > It SHOULD be an input, and not driving at all.
>
>You mean the state on power-up?

Yes.


> > Put a pull-down resistor out there, and see what happens.
>
>OK, But given what you have said above, inverting the logic would also do
>the trick, would it not?

Nope.
If the pin is floating on boot, then it can assume any state.
This is done so that the designer can set it to any state he wants, using
external resistors.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@155243 by Jinx

face picon face
> OK, But given what you have said above, inverting the logic
> would also do the trick, would it not?

IMHO the resistor should take the pin to the LED's off-state,
ie pull the pin high if LED (anode to Vcc, cathode to pin)
current is sink, pull the pin low (LED anode to pin, cathode
to 0V) if current is source.

A pull-down with the way you have the LED now (sink) will
use unnecessary power, as the off-state is with the pin high.
A pull-up will immediately tie the pin high when power is
applied, effectively putting both a and k of the LED at 5V,
so there should be no blip

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@174506 by David VanHorn

flavicon
face
At 09:49 AM 1/19/02 +1300, Jinx wrote:
> > OK, But given what you have said above, inverting the logic
> > would also do the trick, would it not?
>
>IMHO the resistor should take the pin to the LED's off-state,
>ie pull the pin high if LED (anode to Vcc, cathode to pin)
>current is sink, pull the pin low (LED anode to pin, cathode
>to 0V) if current is source.
>
>A pull-down with the way you have the LED now (sink) will
>use unnecessary power, as the off-state is with the pin high.
>A pull-up will immediately tie the pin high when power is
>applied, effectively putting both a and k of the LED at 5V,
>so there should be no blip

I misunderstood, I thought he had an inverting buffer between the LED and
the PIC.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\18@234307 by Jinx

face picon face
> I misunderstood, I thought he had an inverting buffer between
> the LED and the PIC

Considering all the right answers and advice you give, it's
just a blip

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\01\19@023250 by David VanHorn

flavicon
face
At 05:18 PM 1/19/02 +1300, Jinx wrote:
> > I misunderstood, I thought he had an inverting buffer between
> > the LED and the PIC
>
>Considering all the right answers and advice you give, it's
>just a blip

:)

After too many emails in a day, they all begin to look the same.
Eudora says I get 900,000+ emails a year (I think it's math is off a little)

Still, it's important to run these problems down, and not let them slide.
I don't accept unintended I/O actions in my products.
A glitch like that could easily ruin the head of the printer I'm working on.

So, I set up the hardware to disable it when the CPU is tri-stated, and I
add a safety feature of an output that has to be turned on, definitely,
from the processor before power is applied to the printhead. This one leaks
a lot of current (relatively speaking) so even the AVR pullups won't turn
it on, it takes a real high.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\19@090809 by Roman Black

flavicon
face
It's good practice to keep all PIC pins in a
"safe" state until the power supply has had time
to stabilise. I use about 500mS on most things.
Then set the pins to IN/OUT as desired.

The "safe" state can be high impedance, with
pull downs on the pins (pull ups NOT advised
on floating pins) or my preference, whenever it
can be done is set pins to outputs and keep them
low, obviously all external devices are kept
OFF with a logic low.

Deliberately setting all IN/OUTs after the
500mS delay should prevent many of the start up
glitches that can occur. :o)
-Roman


David VanHorn wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\01\20@174029 by David Duffy

flavicon
face
>At 09:49 AM 1/19/02 +1300, Jinx wrote:
>> > OK, But given what you have said above, inverting the logic
>> > would also do the trick, would it not?
>>
>>IMHO the resistor should take the pin to the LED's off-state,
>>ie pull the pin high if LED (anode to Vcc, cathode to pin)
>>current is sink, pull the pin low (LED anode to pin, cathode
>>to 0V) if current is source.

Dwayne wrote:
>I *still* don't get it!  Why is a pull-up or pull-down resistor needed at
>all?  The port pin is an INPUT after reset and thus is high impedance.

There's nothing to get - The pull up/down resistor is *not* required if it's
just an LED being driven by the PIC pin. I think some posters thought
that it was driven by a buffer which was fed from the PIC pin. You're not
going nuts!  It sounds like light getting into the JW package was maybe
the culprit. It really would be best for him to track it down though. Things
like that can come back to bite if left unresolved. :-)
Regards...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...