atmega168pa programmieren

[Stephan B. (stbu)]

Hallo Forum,

ich komme mit einem atmega168pa nicht klar. Ich wollte ein auf einem 
atmega8 schon laufendes Programm - mal eben - auf diesem in Gang setzen. 
Letztlich läuft irgendwie gar nichts.

Inzwischen habe ich ein simples Testprogramm geschrieben und geflasht.

#include <avr/io.h>

int main(void)
{

   DDRC = 0xff;
   PORTC = 0x00;

   while(1) {
   }

}

avr-gcc -mmcu=atmega168 -Wall -DF_CPU=1000000UL  -Os  -Wall   -I/usr/lib/avr/include  -c main.c -o obj/Release/main.o
avr-g++ -L/usr/lib  -o bin/Release/Testprojekt.elf obj/Release/main.o   -mmcu=at90s2313 -Wl,-Map=bin/Release/Testprojekt.elf.map,--cref  
Output size is 3,36 KB
Running project post-build steps
avr-objcopy -O ihex -R .eeprom -R .eesafe bin/Release/Testprojekt.elf bin/Release/Testprojekt.elf.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin/Release/Testprojekt.elf bin/Release/Testprojekt.elf.eep.hex
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)

Die fuses habe ich nicht verändert:

Testprojekt$ avrdude -P /dev/ttyS0 -c stk500 -p m168p -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h

avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e940b

avrdude: reading lfuse memory:
Reading | ################################################## | 100% 0.00s
avrdude: writing output file "<stdout>"
0x62

avrdude: reading hfuse memory:
Reading | ################################################## | 100% 0.00s
avrdude: writing output file "<stdout>"
0xdf

avrdude: reading efuse memory:
Reading | ################################################## | 100% 0.00s
avrdude: writing output file "<stdout>"
0x1

avrdude: safemode: Fuses OK
avrdude done.  Thank you.

Der atmega168pa steckt in einem STK500, PC0 ist mit LED0 verbunden.

Ich habe erwartet, daß die LED einfach leuchtet, sie blinkt jedoch mit 
einigen Hz.

Für mich sieht das aus, als würde der Controller ständig einen reset 
machen. Nicht ganz das, was ich wollte.

Habt Ihr einen Rat für mich?

Gruß,
Stephan

[Detlef Freckel (Gast)]

Stephan Busch schrieb:
> -mmcu=at90s2313

ist kein mega168pa

[Stephan B. (stbu)]

Detlef Freckel schrieb:
> Stephan Busch schrieb:
>> -mmcu=at90s2313
>
> ist kein mega168pa

... wie peinlich, beim Kopieren zu wenig nachgedacht, gehört dort 
ohnehin nicht hin.

Neuer Versuch, leider gleiches Ergebnis:

avr-gcc -Wall -mmcu=atmega168p -DF_CPU=1000000UL  -Os  -Wall   -I/usr/lib/avr/include  -c main.c -o obj/Release/main.o
avr-gcc -L/usr/lib  -o bin/Release/Testprojekt.elf obj/Release/main.o   -Wl,-Map=bin/Release/Testprojekt.elf.map,--cref  
Output size is 965,00 bytes
Running project post-build steps
avr-objcopy -O ihex -R .eeprom -R .eesafe bin/Release/Testprojekt.elf bin/Release/Testprojekt.elf.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin/Release/Testprojekt.elf bin/Release/Testprojekt.elf.eep.hex
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)

[Detlef Freckel (Gast)]

Stephan Busch schrieb:
> Neuer Versuch, leider gleiches Ergebnis:

Im Debugger kann man das Verhalten der HEX-Datei auf Funktion 
überprüfen. Versuch das mal.

[Michael (Gast)]

Stephan Busch schrieb:
> Für mich sieht das aus, als würde der Controller ständig einen reset
> machen.

Was sagt der Simulator zu dem Thema und was treibt dein Watch Dog so?

[Stephan B. (stbu)]

Ja, bisher habe ich beim AVR weder mit Debugger noch mit Simulator 
gearbeitet. Da muß ich mich denn wohl mal schlau machen.

Simulavr unterstützt leider den Controller nicht. Womit macht Ihr das?


Inzwischen habe ich jetzt folgendes merkwürdiges Verhalten erzeugt: Im 
Programm eine Zeile eingefügt, um einen ggf. aktiven Watchdog langsamer 
zu machen:

WDTCSR |= (1 << WDP3);

Ergebnis: Programm arbeitet wie vorgesehen. Ausgeschaltet, 
eingeschaltet, Programm geht nicht mehr, auch nicht nach reset. Nur 
einige der PORTC-Pins sind low. Neu geflasht, geht das Programm wieder. 
Das ist reproduzierbar nach Spannungsverlust so. Die Zeile aus dem 
Programm habe ich wieder entfernt, das Verhalten bleibt, das Blinken 
kehrt auch nicht wieder.

Ich glaube, ich sehe den Wald vor lauter Bäumen nicht. Für heute reicht 
es mir.

Gruß,
Stephan

[Detlef Freckel (Gast)]

Stephan Busch schrieb:
> Womit macht Ihr das?

In der IDE von WinAVR ist das bereits integriert. Ich benutze für kleine 
Projekte ISIS von Proteus, das ist baer kostenpflichtig :-).

[Stephan B. (stbu)]

Liebe Leute,

es ist wie immer: Das Problem sitzt vor der Tastatur.

Erst zu unkonzentriert ein Projekt geändert, dann ein Programm 
halbherzig kopiert und dann auch noch einen guten Rat nicht verstanden.

Detlef Freckel schrieb:
> ist kein mega168pa

Ich hatte "-mmcu=at90s2313" aus dem Aufruf des loaders entfernt, hätte 
jedoch "-mmcu=atmega168" statt dessen einsetzen müssen.

Kaum macht man es richtig, schon geht es. Immer wieder verblüffend.

Danke für Euren Rat,
Stephan