Problem mit AVR Studio 4 - Fehler beim Compilieren

[Olle_Filzlaus]

Hallo,

ich bin dabei gerade von Bascom auf C umzusteigen. C hatte ich mal in der Schule und hoffe das es mir dadurch etwas leichter Fällt :-)

Na jdenfalls habe ich das AVR Studio installiert und der hat ja automatische auch WinAVR installiert. Das Verzeichniss der Includes eingestellt und dann habe ich diese kleine Programm geschrieben.



/* erstes Programm */

#include <avr/io.h>

int main (void)
{

ddrb = 0xff; //Alle Pins von Port B als Ausgänge
Portb = 0xff; //Portb0 und Portb1 = High, Rest Low

while(1)
{
//leere Schleife
}

return 0; //Wird nie erreicht, ist aber nötig
}


Anschließend wollte ich es Compilieren und dann kan folgender Fehler:



make: *** No rule to make target `../main.c', needed by `main.o'. Stop.


DAs Makefile sieht folgender Maßen aus:



################################################## #############################
# Makefile for the project erstes_Programm
################################################## #############################

## General Flags
PROJECT = erstes_Programm
MCU = atmega16
TARGET = erstes_Programm.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 -DF_CPU=8000000UL -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 += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS +=


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


## Include Directories
INCLUDES = -I"C:\WinAVR\avr\include"

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

## Objects explicitly added by the user
LINKONLYOBJECTS =

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

## Compile
main.o: ../main.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 $< $@

%.lss: $(TARGET)
avr-objdump -h -S $< > $@

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

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

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


Ich konnte erstmal kein Fehler finden. Ich denke mal der liegt im DEtail und das habe ich noch nicht so richtig raus :-)

Wäre nett wenn ihr mir helfen könntet.

thx Arno

Edit: Habe jetzt mal be Google geuscht und herausbekommen das es ein Fehler in der Version 4.1.1 von AVR sTudio gibt. Hba eaber Version 4.1.2 drauf. Andere Sachen die ich gefunden habe gehen auch nicht.

[jar]

Portb = 0xff; //Portb0 und Portb1 = High, Rest Low

ist schon mal ein Widerspruch in sich FF ist nie 2 so und der Rest anders ...


while(1)
{
//leere Schleife
}

geht eh nicht, leere oder while schleifen brauchen immer was, manchmal reicht ein ;, aber nicht wenn compiler optimierung on ist, so doof sind die compiler nicht, da wird die leere while auch leerer code, also sicherheitshalber immer dummy_var=0;

@Roboter-Spezialist, hmm, der Code lässt nicht darauf schliessen

scnr, dummer Scherz von mir nicht böse gemeint, helfe gerne wenn ich kann

ich bin ja auch Neuling, 10 jahre nicht geproggt und seit einer Woche mit dem Atmel wieder angefangen

hätte etwas code wenn du deine SW erst mal prüfst und in ordnung bringst hier noch mal richtig einstellst, dann prüfe ich den code bei mir und schick dir die makefiles

[Olle_Filzlaus]

Ups, Tippfehler, sollte eigentlich heißen:

Portb = 0x03

Ich habe das Beispiel aus dem AVR-Tut abgeschrieben. ICh weiß, zu blöd zum tippen.

Zu dem Fehler. Ich habe im netz jetzt soweit geforscht, dass es scheinbar an der Cygwin Datei von Windows liegt. Das ist ne Datei die es erlaubt Linux basierende Software in Windows zu laufen zu bewegen. Die wird aber von M$ nicht aktuallisiert. Werde deswegen mal ne neuere VErsion von der Cygwin einspielen. Mal shen was es bringt.

Wegen dem Roboterspezialist: Ich habe wie hier geschrieben bisher in Bascom gearbeitet. Dort fand dich es nur ziehmlich umständlich wenn man I2C benutzt.
Deswegen und weil ich denke das ich mit C mehr erreichen kann als in Basic jetzt der Umstieg auf C. Denke mal das ist man etwas näher an der Hardware und versteht einige achen die einem sonst Bascom abgenommen hat besser.

Ausserdem kann ich mir diesen Rang nicht aussuchen, den gibt es einfach ab ne bestimmten anzahl von postings.

cu arno

[jar]

Zu dem Fehler. Ich habe im netz jetzt soweit geforscht, dass es scheinbar an der Cygwin Datei von Windows liegt. Das ist ne Datei die es erlaubt Linux basierende Software in Windows zu laufen zu bewegen. Die wird aber von M$ nicht aktuallisiert. Werde deswegen mal ne neuere VErsion von der Cygwin einspielen. Mal shen was es bringt.

Wegen dem Roboterspezialist....Ausserdem kann ich mir diesen Rang nicht aussuchen, den gibt es einfach ab ne bestimmten anzahl von postings.
cu arno

ersteres ist eine gute Idee, immer die neuste und wenn möglich gleich win exe suchen

letzteres weiss ich doch, war nur ein doofer scherz von mir

ich mach ja auch reichlich fehler, z.b. var init vergessen, sucht man sich ein wolf....

aber nun läuft meine HW und SW bald wie geplant

[Olle_Filzlaus]

Hallo,

naja, bei mir ist es das problem das ich auf arbeit nicht installieren darf. Ich muss rausbekommen warum das nett geht und dann muss ich das ändern. Wenn ich soweit bin gehe ich zu unseren Hardwareleuten, die sind nett aber ständig auf achse, und lasse das beheben.

Deswegen der versuch das irgendwie ohne admin rechte hinzubekommen^^

werde aber bescheid geben wenn ich den fehler habe, versuche das mal zu hause.

thx Arno

[Olle_Filzlaus]

So, habe das zu hause mal getestet. Da läuft alles ohne Probleme.

Ausser das mein Programm oben nicht geht.

AVR Studio 4 hat wieder ne andere Syntac.



#include <avr/io.h>
//#define F_CPU 8000000
//#include <avr/delay.h>


int main()
{

DDRB |= 0xff; //Alle Pins als als Ausgänge setzen
PORTB |= 0x03; //Ausgänge setzen


/*
while(1)
{
nop
}
*/

return 0;
}



thx arno

Edit: Ok, das obere Programm geht auch. Habe gelesen das die Syntac geändert wurde, komisch

[bluebrother]

also wenn das "nop" kein Makro ist (was es nicht sein sollte, weil Makros i.a. großgeschrieben werden) und das abschließende Semikolon enthält wird der Code so nicht funktionieren.