LED not coming on $50 robot

[greywanderer012345]

I've built the $50 robot circuit using admin's sire diagram for the 9V/4.8V battery combo. I'm using the atmega328p and the isp mkII programmer with avr studio v.4.18 and WinAVR-20100110. I wanted to test my setup before altering the servos. I am able to connect to and program the atmega328p without errors. I've written a simple program using the SoR_Utils.h header file and the LED_on() function. My source code and the makefile generated by avr studio are below. Also, I had some trouble programming the chip after it had already been successful several times, but it started working again after I got the chip to go deeper into the socket. I've pushed on it with moderate pressure, but I'm still wondering if it is all the way in the socket. I'm not sure if it's normal, but I had to bend the pins to get them into the socket at all. Here's an image of my mcu. Can someone tell me if it's not in all the way or if there is a problem with my source code? Thanks!
... ok I need to figure out how to post the image... still, here's the source code:

#include "SoR_Utils.h"

int main(void){
      configure_ports();
      LED_on();
      while(1){
      }
      return 0;
   }

makefile:
###############################################################################
# Makefile for the project LED_On
###############################################################################

## General Flags
PROJECT = LED_On
MCU = atmega328p
TARGET = LED_On.elf
CC = avr-gcc.exe

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS +=  -Wl,-Map=LED_On.map


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 --no-change-warnings


## Include Directories
INCLUDES = -I"C:\Users\Dan\Documents\AVR_Projects\LED_On\..\Photovore_V1"

## Objects that must be built in order to link
OBJECTS = LED_On.o

## Objects explicitly added by the user
LINKONLYOBJECTS =

## Build
all: $(TARGET) LED_On.hex LED_On.eep LED_On.lss size

## Compile
LED_On.o: ../LED_On.c
   $(CC) $(INCLUDES) $(CFLAGS) -c  $<

##Link
$(TARGET): $(OBJECTS)
    $(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
   avr-objcopy -O ihex $(HEX_FLASH_FLAGS)  $< [email protected]

%.eep: $(TARGET)
   -avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< [email protected] || exit 0

%.lss: $(TARGET)
   avr-objdump -h -S $< > [email protected]

size: ${TARGET}
   @echo
   @avr-size -C --mcu=${MCU} ${TARGET}

## Clean target
.PHONY: clean
clean:
   -rm -rf $(OBJECTS) LED_On.elf dep/* LED_On.hex LED_On.eep LED_On.lss LED_On.map


## Other dependencies
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)

[greywanderer012345]

This is a pic of my robot showing how far the mcu is sticking out. Should I try to push it in further? Thanks.

[rbtying]

If it's electrically connected, it's fine.  If it's not connected, push it in more. =).

[greywanderer012345]

Everything's working now. Somehow, I had connected the lead of the LED that should have gone to ground to my servo power bus. I'm glad nothing got broken, and now I can turn the LED on and off and all that, although, when I write a blinking LED program, my cycles/second are different than what admin proposes in the SoR_utils.h file. Is that weird?

[walkercreations]

So you are able to manipulate the LED using the program you posted in your original post? I would like to try it with mine.

[greywanderer012345]

I haven't tried that code again, yet. I was trying to learn more about how to program the avr myself and came up with:

#include <avr/io.h>

int main(void){
    DDRD = 0xFF; // set port D to output
    PORTD = 0xFF; // brings all PORTD pins high
    while(1){
    }
    return 0;
}

However, I think the original posted code should work, although, unless I'm reading it wrong, it's actually the function LED_off() that brings the pin. Try it both ways.

[Crunchy Theory]

So you are able to manipulate the LED using the program you posted in your original post? I would like to try it with mine.

Same here. I was never able to get the LED working and after seeing some of Admin's notes on the LED being flaky I just decided to leave it alone. Maybe I'll give it another shot.

Greywanderer, do you think you could post a closeup of the bottom of your board so I can see how you soldered your LED on?

[greywanderer012345]

Crunchy, I can't get a picture right now, but looking at the original tutorial, both the schematic and the pictures shows one of the leads on the led attached to AVCC. I'm not sure how that was supposed to work. I desoldered that lead and soldered it to GND, one pin above/below, and now my led works great. Is the tutorial correct?

[greywanderer012345]

Looking around the forum for $50 robot LED issues, I'm finding plenty of people saying that the port should be brought low, but I just don't understand how that works... One side of the LED circuit must have positive voltage, and the other side must get to negative ground, right? The LED being connected to GND and the pin through the resistor is working on mine...

[Webbot]

The design had it like this:

+5v ----- LED ---- resistor ----- ATMega pin

So if the ATMega pin is low (gnd) then current flows through the LED and it lights. If the ATMega pin is high (5v) then no current flows and the LED is off.

The reason for doing it this way around is the processors are much better at sinking current (ie being the place where the current flows into) than they are at sourcing current (ie being the place where the current flows from).

The common problem, therefore, is that most people ASSUME that it is wired like this:-
ATMega pin ------- LED ---- resistor ------ Gnd
Which increases the chances of blowing the ATMega pin if the resistor doesn't limit the current.

Based on this assumption:- then a lot of people end up connected the LED the wrong way around and hence it NEVER lights.

[walkercreations]

...

Based on this assumption:- then a lot of people end up connected the LED the wrong way around and hence it NEVER lights.

But if I wired it per your alternate schematic, all should work as advertised, correct? If that is true, then I need to find a simple program that I can load to my MCU to make the light come on.

[Webbot]

...

Based on this assumption:- then a lot of people end up connected the LED the wrong way around and hence it NEVER lights.

But if I wired it per your alternate schematic, all should work as advertised, correct? If that is true, then I need to find a simple program that I can load to my MCU to make the light come on.

Well no.
What I meant is that people often end up connecting the LED the wrong way around :

+5v --------|<|--- resistor ---- io pin

Which will never work - no matter what you do in software

[walkercreations]

I understand that, but I think what I meant to ask was that if I wired it the way you suggested in your schematic it should work, correct?

[greywanderer012345]

I see... So, my LED was not turning on because I had the leadsbackwards. I didn't realize that a pin brought low was connected to ground. I'm starting to get it a little better, now. Thanks. (Should I switch the LED leads now, or leave it so that the pin is the source, since it hasn't blown out so far...? Thanks, again...)

[VegaObscura]

The reason for doing it this way around is the processors are much better at sinking current (ie being the place where the current flows into) than they are at sourcing current (ie being the place where the current flows from).

Where did you get the information that processors are better at sinking than they are at sourcing?  Every Atmega datasheet I've ever read has given a max current rating for IO pins, and not specified whether this is sinking or sourcing.

[greywanderer012345]

Also, why is the + end of a circuit referred to as the source when electricity flows from - to +?