How to fix low LED light?

Go To Last Post
36 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've connected the LED diode to a 1K resistor. When I tested it out on a breadboard it worked fine, the LED was very bright. Now, when I soldered it to the board, the LED light is poor. The connection is the same, with no changes. I don't know where is the problem. Everything else works fine, so that means the connection between components is good. Could the problem be in the tin or paste I use? Does anyone have an idea?

Btw, everything is connected to a 5V power supply. I measured voltage in some points on board, and it is about 4,65-4,75V. What else can I do to find an error?

This topic has a solution.
Last Edited: Thu. Nov 18, 2021 - 09:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SMarc wrote:

...The connection is the same, with no changes....

 

If that is the case then the LED will have the same brightness. So, as it is different that means...

 

1) your resistor is not the value you think it is

2) your LED is different

3) your PCB is not the same as the breadboard not matter what you think.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

4) the LED is pulsed, like PWM.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

When discussing H/W issues, a clear picture and a schematic will do wonders for us to help you diagnose the problem.

Gook luck

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

If you want something you've never had...

...you must be willing to do something you've never done!

Lets go Brandon!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

when I soldered it to the board,

Or, if it is connected to a micro's I/O pin, then perhaps the internal pull-up resistor was activated instead of making the pin an output.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) your resistor is not the value you think it is

2) your LED is different

I am using the same resistor and the same LED I used on the breadboard.

 

When discussing H/W issues, a clear picture and a schematic will do wonders for us to help you diagnose the problem. There is a schematic and board picture.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

Or, if it is connected to a micro's I/O pin, then perhaps the internal pull-up resistor was activated instead of making the pin an output.

 

JC 

 

+1

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or, if it is connected to a micro's I/O pin, then perhaps the internal pull-up resistor was activated instead of making the pin an output.

How can I fix that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well at least 50% of the supplies are not connected.

you should connect all supply connections with decoupling caps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Write to the pin's Data Direction Register (DDR).  Set that pin as an output.

 

Personally, I think they're right - a pin set as an input with a weak pullup (like what the AVR does) will glow very dimly as you have them wired up.  I typically turn LEDs on by pulling them low, but that's just me being an olde farte from back in the days when chips had different source/sink current capabilities.

  S.

 

Edited to add:  And yes, hook up ALL the chip's VCC and GND pins.  The internal connections are not designed to haul all the current everywhere - that's why they have lots and lots of VCC and GND pins!

Last Edited: Tue. Apr 13, 2021 - 10:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitalDan wrote:

DocJC wrote:

Or, if it is connected to a micro's I/O pin, then perhaps the internal pull-up resistor was activated instead of making the pin an output.

 

JC 

 

+1

But he said that this worked on a breadboard but not on the circuit board so the software must be doing the right thing mustn't it ?

Last Edited: Tue. Apr 13, 2021 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When, Mr. Lawson, was the last time you heard someone say "But I only changed this one thing!" and you believed them?  frown  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the change seems to have been from one set of hardware to another? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the change seems to have been from one set of hardware to another? 

There are no changes in the software. I just changed the board, so it has to be a problem with the hardware. 

 

you should connect all supply connections with decoupling caps.

I wired up all supply pins, and nothing has changed. 

 

Does anyone else have an idea of what could it be?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lift the ends of the LED resistors closest to the chip and simply apply Gnd or Vcc to them and see how brightly they shine (hopefully the LEDs not the resistors!!). This tells you whether it's anything to do with the AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With proper power and ground capacitors, does it still work on the breadboard?

Does it work correctly, i.e. do known inputs give you the desired output?

Did the compiler complain about unintialized variables?

Can you get simpler code to work correctly in both cases?

Moderation in all things. -- ancient proverb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...and in future, use an IC socket...

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Generally on the AVR, when a normally-bright LED appears very dim, it is often because the anode is connected to Vcc (+5 or +3.3) on the prototype and is disconnected from Vcc on the board-under-test.  The LED is being powered through the internal pull-up resistor when the cathode is taken to ground.   Check for a cold solder joint or missing solder connection at the LED's anode.

Last Edited: Tue. Apr 13, 2021 - 03:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lets troubleshoot your h/w:

1) use jumper to connect reset pin to gnd. this will hold micro in reset mode and all port pins are floating.

2) use another jumper from vcc to each port pin with an LED connected, does the led light up bright?

Repeat #2 for each LED, do all the LED's light up ok? 

If so, then H/W is ok.

If  not, then check solder connections and that LED polarity is correct, fix and repeat the above 2 steps. check the LED ground connections too.

 

Write a small test program that:

Sets all the four port pins to outputs. DDRn = 0x0F; 

then loop forever lighting one LED at a time for one second, turn off LED, then shift to the next, rinse and repeat.

 

That should identify any bad connections to port pins.

 

Jim

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

If you want something you've never had...

...you must be willing to do something you've never done!

Lets go Brandon!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lift the ends of the LED resistors closest to the chip and simply apply Gnd or Vcc to them and see how brightly they shine (hopefully the LEDs not the resistors!!). This tells you whether it's anything to do with the AVR.

I just tried that and the LED is bright. So the problem is in the microcontroller?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:

With proper power and ground capacitors, does it still work on the breadboard?

Does it work correctly, i.e. do known inputs give you the desired output?

Did the compiler complain about unintialized variables?

Can you get simpler code to work correctly in both cases?

 

It works on the breadboard with the same voltage and capacitors. The code works fine, it gives the desired results, just the LED is not bright. 

 

1) use jumper to connect reset pin to gnd. this will hold micro in reset mode and all port pins are floating.

When I connect reset to ground the program won't even recognize the microcontroller.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Write a small test program that:

Sets all the four port pins to outputs. DDRn = 0x0F; 

then loop forever lighting one LED at a time for one second, turn off LED, then shift to the next, rinse and repeat.

I tried this code:

int main(void)
{
    DDRB=0xFF;
	DDRB   |= (1 << PB0);

    while (1)
    {
	    _delay_ms(1000);
		PORTB &= ~(1 << PB0);
		_delay_ms(1000);
		PORTB |=  (1 << PB0);
    }
}

And the LED is bright. I am really confused. Is there a problem with the sensor? Or is it a code problem? But if it worked on a breadboard it should work now.

 

Last Edited: Wed. Apr 14, 2021 - 10:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SMarc wrote:

Or is it a code problem?

 

Who knows? We can't see your code.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Who knows? We can't see your code.

 

 

int main(void)
{
    DDRB=0xFF;
	DDRA=0x00;
	

	while (1)
	  {
		for (uint8_t i=0; i<4; i++)
		 {
			if((PINA &(1<<i)) ==0)
			 {
				    PORTB |= (1<<i);
				    PORTB &= ~(1<<i);
			  }
		    }
			}
}

Here is the code I use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SMarc wrote:

			if((PINA &(1<<i)) ==0)

That's a digital test, but you have analogue (potential divider) inputs connected to PA0-3.

 

Perhaps your inputs are noisy, so you are seeing noise on the outputs (LEDs) ?

 

Take a step back - just blink the LEDs to confirm that they are working.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a digital test, but you have analogue (potential divider) inputs connected to PA0-3.

 

Perhaps your inputs are noisy, so you are seeing noise on the outputs (LEDs) ?

 

Take a step back - just blink the LEDs to confirm that they are working.

I tried the same code with a switch and it gives the same result-poor LED light. 

I tried blinking the led and it worked, the LED is bright. When it doesn't depend on the input it works properly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just tried it without integer i- uint8_t i(used to indicate the number of sensors and diodes) and it works well.

int main(void)
{
    DDRB=0xFF;
	DDRA=0x00;

	while (1)
	  {
		if((PINA &(1<<0)) ==0) //I used the first bit insted of i
		{
		        PORTB |= (1<<0);
			PORTB &= ~(1<<0);
		}

	  }

}

Can I somehow change the code to work for other LEDs as well?

Last Edited: Wed. Apr 14, 2021 - 11:21 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SMarc wrote:

		if((PINA &(1<<0)) ==0) //I used the first bit insted of i
		{
		        PORTB |= (1<<0);     <<---- turns the LED on
			PORTB &= ~(1<<0);    <<---- immediately turns it off again!
		}

 

EDIT

 

So Jim was right:

 

in #4, ka7ehk wrote:
4) the LED is pulsed, like PWM.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Apr 14, 2021 - 11:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So wouldn't you at least:

#define F_CPU 123456UL // put actual CPU speed here
#include <util/delay.h>
#include <avr/io.h>

int main(void)
{
    DDRB=0xFF;
	DDRA=0x00;

	while (1)
	  {
		if((PINA &(1<<0)) ==0) //I used the first bit instead of i
		{
		    PORTB |= (1<<0);
		    _delay_ms(100);
		    PORTB &= ~(1<<0);
		    _delay_ms(50);
		}

	  }

}

Personally I am not a great fan of the ==0 test so I'd probably go with:

if (!(PINA & (1 << 0)))

or perhaps even:

if (bit_is_clear(PINA, 0))

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

SMarc wrote:

Brian Fairchild wrote:

Who knows? We can't see your code.

 

 

int main(void)
{
    DDRB=0xFF;
	DDRA=0x00;

	while (1)
	  {
		for (uint8_t i=0; i<4; i++)
		 {
			if((PINA &(1<<i)) ==0)
			 {
				    PORTB |= (1<<i);
				    PORTB &= ~(1<<i);
			  }
		    }
			}
}

Here is the code I use.

It isn't clear to me whether you want the same state of PINA's low nibble reflected on PORTB, or the inverse state.  You can avoid the if statement and the for loop with a simple copy as follows:

while(1) {
    // Copy low nibble of PINA to low nibble of PORTB
    // while preserving the high nibble of PORTB
    PORTB = (PORTB & 0xF0) | (PINA & 0x0F);
}

Or, if you want the inverse state:

while(1) {
    // Copy low nibble of the inverse of PINA to low nibble of PORTB
    // while preserving the high nibble of PORTB
    PORTB = (PORTB & 0xF0) | (~(PINA) | 0x0F);
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But we're still left with the issue that you're feeding a digital input from an analogue source, which is OK when the input is "definitely high" or "definitely low" - but is going to cause trouble when it's "somewhere between" ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I guess that somewhere you lost a else in the code so you either set a bit or clear it :)

 

that you take a bit at the time should work, just not speed optimal, but first it need it to work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a classic example of where an oscilloscope (or a cheap logic analyser)  or a debugger would have shown you the problem immediately.

 

#IndispensableTools 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

SMarc wrote:

 

		if((PINA &(1<<0)) ==0) //I used the first bit insted of i
		{
		        PORTB |= (1<<0);     <<---- turns the LED on
			PORTB &= ~(1<<0);    <<---- immediately turns it off again!
		}

 

So apparently this was the problem. I would never assume because it was working on the breadboard. Thank you all for your help! It would take a while before I would remember to look for a bug in the code.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for feeding back.

 

SMarc wrote:
it was working on the breadboard.

Then the code and/or the hardware must have been different.

 

It would take a while before I would remember to look for a bug in the code.

They key thing about small embedded microcontroller systems like this is that it's not just about hardware, and not just about software - it's all about the two working together.

 

This is why it's so important to have some decent hardware test equipment - see #33 - as well as software debug facilities.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Locked after spam.

Topic locked