Society of Robots - Robot Forum
Software => Software => Topic started by: dellagd on July 13, 2009, 02:50:43 PM
-
hey guys, I'm trying to get this prog compiled, but I get this error(its in the pic, at the bottom, just zoom in). how do I get rid of it?
-
looks like you names something wrong....
now for code revision (I like the practice ;) )
while(0) will not do anything.... because 0 is false and any non zero value is true... so if you use 1 or "true" it should work...
the way you are turning on/off the LED's will work but there are easier ways
-
a name problem? oh and it says that it cant find SoR_Utils.h unless I use the makefile from the photovore $50 bot files
also whenever I try to compile my own prog I get this error "../LED_blinking.c: error: SoR_Utils.h: No such file or directory"
I think it might have something to do this
-
I would also try using #include "SoR_Utils.h" in stead of useing the '<', and '>' s
-
same problem
-
Use this code to get the effect you are looking for... then when compiling it make sure you set your frequency to 1MHz not 16 Htz... This code will work for really any AVR micro.... I used it on an atmega 328p with other cool stuff for the Led also like different flash patterns...
(in addition try upgrading AVR studio, and are you using vista?)
// Frequency number needed by the delay function.
// The chip is factory set to run on internal
// oscillator at 1 MHz so the value is 1000000UL
#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>
// Number of frames in the animation
#define FRAMES 8
// The animation sequence array.
// All the values are in binary for easy
// reading (1 = LED on / 0 = LED off)
// The rightmost bit is PB0 and the leftmost
// bit after '0b' is PB4.
// -> 0b[4][3][2][1][0]
char animation[FRAMES] =
{
0b00001,
0b00010,
0b00100,
0b01000,
0b10000,
0b01000,
0b00100,
0b00010
};
int main(void)
{
DDRB = 0x1F; // PB0-PB4 output
PORTB = 0x00; // Set all pins low
int i;
while(1)
{
// Loop through all the frames in the animation
for(i=0 ; i<FRAMES ; i++)
{
// Write the value from the array to the port
PORTB = animation[i];
// Wait 100 ms before going to the next frame
_delay_ms(100);
}
}
return 0;
}
-
I use a external 16mhz crystal
oh and keyword NOOB.
How would I set up the program, do I need a external makefile?
also, if I dont use the photovore makefile, I get this, for by tones of errors because of it.
../LED_blinking.c:1:23: error: SoR_Utils.h: No such file or directory
-
Check the "use external makefile" option and use the $50 makefile (which is just a general purpose makefile)
-
even if I use a atmega168?
and even if I use it, I still get make: *** No rule to make target `../leds_blinking.c', needed by `leds_blinking.o'. Stop.
-
Hmmmm...for the AtMega168 upgrade, you may want to follow this tutorial if you're using the $50 code and makefile and stuff ;)
http://www.societyofrobots.com/step_by_step_atmega168_swapout.shtml (http://www.societyofrobots.com/step_by_step_atmega168_swapout.shtml)
-
Just another thing, have you changed the fuse settings according to your oscillator? You probably should look into it if you haven't already
http://www.societyofrobots.com/microcontroller_xtal.shtml (http://www.societyofrobots.com/microcontroller_xtal.shtml)
-
Use the code I gave you and add it to an empty project called anything... you can use just the default makefile... (remember to use 16000000 hz, not 16 hz. ;) )
Good luck!!
(lol I have probably pulled my hair out for hours with those same type of stupid errors ;) )
-
ok take a look at the makefile, whats wrong with it!
###############################################################################
# Makefile for the project LED_blinking
###############################################################################
## General Flags
PROJECT = LED_blinking
MCU = atmega168
TARGET = LED_blinking.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 -std=gnu99 -DF_CPU=16000000UL -O0 -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_blinking.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
## Objects that must be built in order to link
OBJECTS = LED_blinking.o
## Objects explicitly added by the user
LINKONLYOBJECTS =
## Build
all: $(TARGET) LED_blinking.hex LED_blinking.eep LED_blinking.lss size
## Compile
LED_blinking.o: ../LED_blinking.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) $< $@
%.eep: $(TARGET)
-avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ || exit 0
%.lss: $(TARGET)
avr-objdump -h -S $< > $@
size: ${TARGET}
@echo
@avr-size -C --mcu=${MCU} ${TARGET}
## Clean target
.PHONY: clean
clean:
-rm -rf $(OBJECTS) LED_blinking.elf dep/* LED_blinking.hex LED_blinking.eep LED_blinking.lss LED_blinking.map
## Other dependencies
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)
-
Please give us more information so it will be easier for us to help you. What is wrong with it? What error do you get?
It may just be a heck of a lot easier to take the $50 robot source code, take out the photovore code in the main() loop and put in your led blinking stuff...
-
Make sure the SOR_utils.h is in the same folder as your *.c file.
-
ok good and bad news
good: I got it to build and compile a .hex file.
bad: all the board does is light up all 5 LEDS at the same time
-
ok good and bad news
good: I got it to build and compile a .hex file.
bad: all the board does is light up all 5 LEDS at the same time
have you tried changing the delay_cycles(100) to something different?
-
ok good and bad news
good: I got it to build and compile a .hex file.
bad: all the board does is light up all 5 LEDS at the same time
Are you using kpmcgurk's code or your code?
-
Hmm, how are your Leds wired?
EDIT: Stupid error by me... the code that I gave you is for B ports but you are using D ports... Change my code where is uses B to D..... Its that simple, and then my friend you will have blinking leds!!! (I hope ;) )
-
ok
is it also possible that the LEDs are drawing too much power?
EDIT: I think I edited it correctly, still no luck. Idea! lets see if its a problem with my computer, because the only program that has worked on it so far was one done by someone on another computer (he just sent me the hex file). kpmcgurk, compile your prog, and post the hex file. If it works then, then I got a computer (or settings) problem.
Just remember to edit it for ports PD0 - PD4
-
dellagd, can you post the modified code?
-
I will tomarrow, but thats not the point
I think I have a setting wrong in AVR studio that makes the programs turn out funky.
// Frequency number needed by the delay function.
// The chip is factory set to run on internal
// oscillator at 1 MHz so the value is 1000000UL
#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>
// Number of frames in the animation
#define FRAMES 8
// The animation sequence array.
// All the values are in binary for easy
// reading (1 = LED on / 0 = LED off)
// The rightmost bit is PB0 and the leftmost
// bit after '0b' is PB4.
// -> 0b[4][3][2][1][0]
char animation[FRAMES] =
{
0b00001,
0b00010,
0b00100,
0b01000,
0b10000,
0b01000,
0b00100,
0b00010
};
int main(void)
{
DDRD = 0x1F; // PB0-PB4 output
PORTD = 0x00; // Set all pins low
int i;
while(1)
{
// Loop through all the frames in the animation
for(i=0 ; i<FRAMES ; i++)
{
// Write the value from the array to the port
PORTD = animation[i];
// Wait 100 ms before going to the next frame
_delay_ms(100);
}
}
return 0;
}
-
Just as a quick test try setting your delay to a larger number. 20 times as large. If you see the "animation" pattern as a result, then it is likely a clock setting. The xtal on the bare-bones board, like the Arduino, is 16 MHz.
-
yup the
#define cpu
is set to 1 Mhz still and so the program thinks that your MCU is running at 1Mhz... but in reality it is really running at 16Mhz making the program run 16X faster.... your program is running alright, but just so fast that you can not tell the difference in the LED's blinking... (I am crossing my fingers now) ;)
-
hmm... I think you should change this:
char animation[FRAMES] =
{
0b00001,
0b00010,
0b00100,
0b01000,
0b10000,
0b01000,
0b00100,
0b00010
};
to this:
char animation[FRAMES] =
{
0d00001,
0d00010,
0d00100,
0d01000,
0d10000,
0d01000,
0d00100,
0d00010
};
But I could be wrong....
-
still, I changed it to 1000 (from delay_cycles (100)), and same problem.
can you make a hex file and send it to me, like I said in an eairlier.
-
bump! could someone compile kpmcgurk program and send me the hex file.
please ;D
-
first of all, don't bump after one day, second of all I don't think that there would be a setting in AVR studio that would make the program act the way you have described.
-
hmm... I think you should change this:
Code:
char animation[FRAMES] =
{
0b00001,
0b00010,
0b00100,
0b01000,
0b10000,
0b01000,
0b00100,
0b00010
};
to this:
Code:
char animation[FRAMES] =
{
0d00001,
0d00010,
0d00100,
0d01000,
0d10000,
0d01000,
0d00100,
0d00010
};
But I could be wrong....
that is binary it should be represented with 0b followed by 1's and 0's
-
ok, sorry :( its just that I was going on vacation very soon and wanted to finish before I did. and sonic, I tried that, and it gives me an error
-
@sonic ahh... I see, my bad.
-
but still guys , could someone send me the hex file for the other guys led blink prog for me.
I need to see if its my computer
-
Let me look through my stuff tomorrow and I'll give you code of mine that I know works.
-apc
[edit] I attached a hex file that makes an LED on PORT B3 dim up and then dim down using PWM. I used this the other day, so I think it works. I'll upload it to my chip tomorrow to make sure and confirm with you. But I'm 99% sure it works.
-
thanks, I'll try it when I get back to my board.