Post by thread:[PIC]: LED Blip on Power Up

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

> >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

> 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

At 01:00 PM 18/01/2002 +1100, you wrote: {Quote hidden}>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 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

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_OUTdwaynerTakeThisOuTplanet.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

on 18/1/02 4:33 PM, Dwayne Reid at .....dwaynerKILLspam@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

> 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

on 18/1/02 1:27 PM, David VanHorn at dvanhornKILLspamCEDAR.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

At 01:32 PM 1/18/02 +1100, Sean Alcorn - Avion Sydney wrote: >on 18/1/02 1:27 PM, David VanHorn at .....dvanhornKILLspam.....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

> 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

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

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.

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}> > > > >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: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

>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_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body