ATmega resettet dauernd

[Mathias O. (m-obi)]

Morgen,

ich hab mal wieder mein Pollin-Board rausgekramt um ein wenig zu 
"spielen".
Dabei will ich mich mal bei IRMP + ENC28J60 versuchen.
Ich hab nun ein seltsames Verhalten, dass sich anscheinend der µC 
dauernd resettet. Ich hab mal ein Beispielcode geschrieben, womit das 
reproduzierbar ist. Das schnelle Blinken was am Anfang ist, macht er 
dauernd und das langsame Blinken in der Schleife macht er garnicht, da 
bleibt konstant die LED an. Achja es ist ein ATmega16 @ 16Mhz. 
Wahrscheinlich seh ich wieder den Wald vor lauter Bäumen nicht.

#ifndef F_CPU
    #define F_CPU 16000000UL
#endif

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <stdlib.h>
#include <stdio.h>
#include "uart.h"
#include "irmpconfig.h"
#include "irmp.h"

#define BAUD 19200UL

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

#define US (1000000 / F_INTERRUPTS)


void timer1_init(void);

static int UARTsendstream(char c, FILE *stream);

static FILE uart_str = FDEV_SETUP_STREAM(UARTsendstream, NULL, _FDEV_SETUP_WRITE);


int main(void){
    IRMP_DATA irmp_data;

    uart_init(UART_BAUD_SELECT(BAUD, F_CPU));
    stdout = &uart_str;

    DDRD |= (1 << PD5)|(1 << PD6);

    PORTD |= (1 << PD5);
    _delay_ms(400);
    PORTD &= ~(1 << PD5);
    _delay_ms(200);
    PORTD |= (1 << PD5);
    _delay_ms(400);
    PORTD &= ~(1 << PD5);
    _delay_ms(1000);

    irmp_init();
    timer1_init();
    sei();

    while(1){
        PORTD |= (1 << PD6);
        _delay_ms(500);
        PORTD &= ~(1 << PD6);
        _delay_ms(500);
    }
}

void timer1_init(void){
    OCR1A = (F_CPU / F_INTERRUPTS) - 1;
    TCCR1B = (1 << WGM12)|(1 << CS10);

    TIMSK = 1 << OCIE1A;
}

static int UARTsendstream(char c , FILE *stream){
    uart_putc(c);
    return 0;
}

ISR(TIMER1_COMPA_vect){
    (void) irmp_ISR();
}

[Stefan F. (Gast)]

Kommentier diese Zeilen mal aus:

    irmp_init();
    (void) irmp_ISR();

Wenn es dann geht, liegt der Fehler im Code dieser Library bzw. 
irgendwelche Voraussetzungen sind nicht erfüllt, die sie zum 
Funktionieren benötigt.

[Mathias O. (m-obi)]

Ne immer noch nicht. Warum sollte auch die Lib ausgerechnet bei mir 
nicht funktionieren. Bei Anderen läuft sie ja.

Edit:
Wenn ich

timer1_init();

und

sei();

auskommentiere, funktioniert es.

[tictactoe (Gast)]

Vielleicht compiliert der Compiler für den falschen Controller, sodass 
der Interruptvektor für COMPA am falschen Index steht?

Ist vielleicht der Watchdog eingeschaltet?

[Mathias O. (m-obi)]

Also es ist -mmcu=atmega16, somit stimmt das.

Wo kann man denn den Watchdog ausschalten?

[kif (Gast)]

Füg mal das am Ende ein:

ISR(BADISR_vect) { }

und kommentier das "sei()" und "timer1_init()" wieder ein!

[Oliver S. (oliverso)]

Mathias O. schrieb:
> Wo kann man denn den Watchdog ausschalten?

Da, wo man ihn auch einschaltet...

Überprüf mal die Fuses..

in 99% aller Fääle kommt das gezeigte Verhalten durch einen Interrupt 
ohne zugehörige ISR. Da es funktioniert, wenn du das sei 
auskommentierst, such halt mal, welche Interrupts alle freigegeben sind.

Oliver

[spess53 (Gast)]

Hi

>Wo kann man denn den Watchdog ausschalten?

Hast du den denn eingeschaltet?

>Wenn ich
>timer1_init();
>und
>sei();
>auskommentiere, funktioniert es.

Dann hat es auch nichts mit dem WD zu tun.

MfG Spess

[Frank M. (ukw) (Moderator)]

Mathias O. schrieb:
> Also es ist -mmcu=atmega16, somit stimmt das.
>
> Wo kann man denn den Watchdog ausschalten?

Ein ähnliches Problem hatte mal einer mit ATmega16 und STK500.

Schau mal hier:

  Beitrag "ATMega16: Interrupt mit Timer1"

Da war's jedenfalls der Watchdog, Lösung steht am Ende des (kurzen) 
Threads auch dabei.

Was mich aber wundert: Sobald Du timer1_init() und sei() rausnimmst, 
funktioniert es? Dann müsste es auch gehen, wenn Du nur sei() 
rausnimmst. Kannst Du das mal testen?

Bekommst Du beim Übersetzen irgendwelche Compiler-Warnungen?

Der Code ist ja nicht vollständig, es fehlen ja noch die uart-Routinen. 
Benutzen diese vielleicht Interrupts - eingeschaltet durch uart_init() - 
mit falschem Interrupt-Vektor? Dann solltest Du aber eine Warnung vom 
Compiler erhalten.

[Mathias O. (m-obi)]

Also mit dem disablen des Watchdogs ist es auch nicht besser.
Die Uart-Routinen sind von Fleury. Die haben sich auch schon mehfach 
bewährt.
Die Fuses sind 0xFE(low) 0xC9(high).
Warnungen bekomme ich keine.

[Oliver S. (oliverso)]

Mathias O. schrieb:
> Warum sollte auch die Lib ausgerechnet bei mir
> nicht funktionieren. Bei Anderen läuft sie ja.

Na ja, das könnte man jetzt kommentieren...

Egal, häng halt mal eine kompletten kompilierbaren Code hier an.

Oliver

[kif (Gast)]

Oliver S. schrieb:
> Mathias O. schrieb:
>> Warum sollte auch die Lib ausgerechnet bei mir
>> nicht funktionieren. Bei Anderen läuft sie ja.
>
> Na ja, das könnte man jetzt kommentieren...
>
> Egal, häng halt mal eine kompletten kompilierbaren Code hier an.
>
> Oliver

Wenn es einfach funktionieren soll, dann füg das in den Code ein:
ISR(BADISR_vect) { }

und es wird funktionieren.

Es wird irgendein Interrupt ausgelöst bei dem keine ISR definiert ist, 
dann springt das Programm jedesmal an den Anfang wenn das entsprechende 
Interrupt ausgelöst wird.

[Mathias O. (m-obi)]

So hier ist mal ein kompilierbarer Code.

#ifndef F_CPU
    #define F_CPU 16000000UL
#endif

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include "irmpconfig.h"
#include "irmp.h"


void timer1_init(void);

int main(void){
    DDRD |= (1 << PD5)|(1 << PD6);

    PORTD |= (1 << PD5);
    _delay_ms(400);
    PORTD &= ~(1 << PD5);
    _delay_ms(200);
    PORTD |= (1 << PD5);
    _delay_ms(400);
    PORTD &= ~(1 << PD5);
    _delay_ms(1000);

    timer1_init();
    sei();

    while(1){
        PORTD |= (1 << PD6);
        _delay_ms(500);
        PORTD &= ~(1 << PD6);
        _delay_ms(500);
    }
}

void timer1_init(void){
    OCR1A = (F_CPU / F_INTERRUPTS) - 1;
    TCCR1B = (1 << WGM12)|(1 << CS10);

    TIMSK = 1 << OCIE1A;
}

ISR(TIMER1_COMPA_vect){
    (void) irmp_ISR();
}

[Frank M. (ukw) (Moderator)]

> #ifndef F_CPU
>     #define F_CPU 16000000UL
> #endif

Das ist schon mal Käse. Damit kannst Du nicht gewährleisten, dass die 
anderen Module (uart, irmp) mit der gleichen F_CPU compiliert werden.

Setz dies als Compiler-Option im Makefile oder Projekt für alle 
C-Dateien.

> #include "irmpconfig.h"
> #include "irmp.h"

Du benutzt hier einen 2 Jahre alten IRMP. Hole Dir bitte die aktuelle 
Version, siehe IRMP. Bei aktuellen Versionen darfst Du auch nur noch 
irmp.h "includieren".

Woran erkennst Du eigentlich, dass der ATmega resettet wird? Fängt er 
(wie am Anfang) an zu blinken?

Folgende Fragen hast Du vergessen, zu beantworten:

Reicht auch das Auskommentieren von sei() alleine, damit der ATmege 
läuft?

Funktioniert das Programm mit

ISR(BADISR_vect)
{
}

auch bei eingeschaltetem sei()?


P.S.
Du schriebst, dass der Fehler auch ohne Aufruf von irmp_init() und 
irmp_ISR() auftritt.

Dann hast Du aber nicht das minimalste Programm gepostet. Das wäre 
nämlich ohne die beiden Aufrufe und ohne die irmp-Includes und ohne 
irmp-Source-Dateien gewesen. Teste das bitte nochmal.

[Mathias O. (m-obi)]

Minimalistisch sieht es so aus.

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
//#include "irmp.h"

#ifndef F_CPU
#error F_CPU unkown
#endif

#define F_INTERRUPTS 15000

void timer1_init(void);

int main(void){
    DDRD |= (1 << PD5)|(1 << PD6);

    PORTD |= (1 << PD5);
    _delay_ms(400);
    PORTD &= ~(1 << PD5);
    _delay_ms(200);
    PORTD |= (1 << PD5);
    _delay_ms(400);
    PORTD &= ~(1 << PD5);
    _delay_ms(1000);

    //IRMP_DATA irmp_data;

    //irmp_init();
    timer1_init();
    sei();

    while(1){
        PORTD |= (1 << PD6);
        _delay_ms(500);
        PORTD &= ~(1 << PD6);
        _delay_ms(500);
    }
}

void timer1_init(void){
    OCR1A = (F_CPU / F_INTERRUPTS) - 1;
    TCCR1B = (1 << WGM12)|(1 << CS10);

    TIMSK = 1 << OCIE1A;
}

ISR(TIMER1_COMPA_vect){
    //(void) irmp_ISR();
}

Funktioniert auch nicht.
Wenn ich sei(); auskommentiere funktioniert es.

Das resetten merke ich daran, dass er das schnelle Blinken vom Anfang 
(PD5) macht.

Das

ISR(BADISR_vect)
{
}

ändert auch nix.

[Karl H. (kbuchegg)]

> Also mit dem disablen des Watchdogs ist es auch nicht besser.

Wie jetzt?
War der aktiviert oder nicht?


> Wenn ich sei(); auskommentiere funktioniert es.

Dann bleibt nicht mehr viel.
Normalerweise würde ich jetzt sagen: du compilierst für den falschen 
Prozessor.

[Konrad S. (maybee)]

Karl Heinz schrieb:
> Normalerweise würde ich jetzt sagen: du compilierst für den falschen
> Prozessor.

Oder evtl. unterschiedliche µCs für Kompilieren und Linken angegeben?

[Frank M. (ukw) (Moderator)]

Mathias O. schrieb:
> Minimalistisch sieht es so aus.

Bin jetzt auch ratlos. Das Ding müsste auch mit sei() laufen.

Kannst Du mal die Kommandos kopieren und hier einfügen, die beim 
Kompilieren bzw. Linken durchgeführt werden?

[Oliver S. (oliverso)]

"Hängen bleiben" würde das wohl auch, wenn der Prozessor nicht mit 
16Mhz, sondern nur mit 1MHz laufen würde. Die oben genannten Fuses sind 
aber auch richtig.

Oliver

[Mathias O. (m-obi)]

Na toll. Hab es jetzt geschafft. In Code::Blocks gibt man den mmcu in 
den Buildoptions an. Ich hab ihn allgemein beim Projekt angegeben, dann 
kann man ihn aber auch noch angeben bei debug und release. Ich hab ihn 
jetzt mal release auch noch angegeben, sowie F_CPU.
Und siehe da es funktioniert.
Der Output sieht nun so aus.

avr-gcc.exe -mmcu=atmega16 -DF_CPU=16000000UL  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c main.c -o obj\Release\main.o

Danke nochmal an alle für die Hilfe. Ich kam mir echt schon bescheuert 
vor.
Wenn es ne Kaffekasse geben würde, würde ich da jetzt was reinschmeissen 
;)

[Frank M. (ukw) (Moderator)]

Mathias O. schrieb:
> Hab es jetzt geschafft.

Gratulation.

Fällt Dir hier was auf?

  -mmcu=atmega16 -DF_CPU=16000000UL  -mmcu=atmega16 -Os -DF_CPU=16000000UL

Da ist was doppelt gemoppelt.

> Wenn es ne Kaffekasse geben würde, würde ich da jetzt was reinschmeissen
> ;)

Ich hol mir den Kaffee auch ohne Kasse.... nämlich jetzt! :-)

[Konrad S. (maybee)]

Es wäre noch interessant zu wissen, wie die Aufrufe vorher aussahen, 
einmal beim Kompilieren von main.c und einmal beim Linken des Programms.

[Mathias O. (m-obi)]

Guten Morge,

so langsam fühle ich mich echt verarscht. Ich wollte jetzt den UART 
ansprechen und wollte die Lib von Fleury verwenden. Sobald ich wieder 
sei(); drin habe, macht er nur das Blinken vom Anfang und geht nicht in 
die Schleife rein.

#include <stdlib.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

#include "uart.h"

#define UART_BAUD_RATE 9600UL


int main(void){
    DDRD |= (1 << PD5)|(1 << PD6);

    PORTD |= (1 << PD5);
    _delay_ms(100);
    PORTD &= ~(1 << PD5);
    _delay_ms(300);
    PORTD |= (1 << PD5);
    _delay_ms(100);
    PORTD &= ~(1 << PD5);
    _delay_ms(300);
    PORTD |= (1 << PD5);
    _delay_ms(100);
    PORTD &= ~(1 << PD5);
    _delay_ms(800);

    uart_init(UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU));

    sei();

    uart_puts_P("Hallo\n");

    while(1){
        uart_puts_P("Test\n");
        PORTD |= (1 << PD6);
        _delay_ms(500);
        PORTD &= ~(1 << PD6);
        _delay_ms(500);
    }
}

Ich frage mich warum das so ein Krampf ist. Als ich das zuletzt vor 
Monaten mit einem mega8 gemacht habe funktionierte alles.
Ich hab jetzt auch nochmal einen anderen mega16 genommen, aber der zeigt 
das selbe Verhalten.
Ich bin echt ratlos.

[tictactoe (Gast)]

Mathias O. schrieb:
>     uart_puts_P("Hallo\n");

Wahrscheinlich sollte das

      uart_puts_P(PSTR("Hallo\n"));

lauten, oder täusch ich mich?

[Mathias O. (m-obi)]

dafür gibts ja
#define uart_puts_P(__s)       uart_puts_p(PSTR(__s))
im header.

[Ellen Moore (Gast)]

Mal ne Frage. Welches Board ist das? Beim AVR Net-IO gabs Versionen mit 
Problemen mit der Spannungsversorgung ... nur so als Anregung.

[MWS (Gast)]

Mathias O. schrieb:
> uart_init(UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU));

Schreib doch mal 16000000UL statt des F_CPU rein.

[Mathias O. (m-obi)]

Ich hab das normale Pollin-Board. 4,82V mess ich am mega.
Auch mit 16000000UL direkt klappt es nicht. Wenn F_CPU nicht stimmen 
würde, würde es doch auch nicht im richtigen Takt blinken oder?

[MWS (Gast)]

Mathias O. schrieb:
> würde es doch auch nicht im richtigen Takt blinken oder?

Auch richtig. Kannst Du den Code simulieren und die Register 
untersuchen? So wie jetzt stocherst Du im Nebel.

In der uart.c der Fleury Lib sind conditional defines drin, um auf die 
verschiedenen µCs anzupassen. Wenn da das Symbol des Prozessors (s.o.) 
nicht klar ist, könnt's zu Problemen kommen.

Da sollten aber Meldungen vom Compiler kommen, was steht in der Ausgabe?

[lmao (Gast)]

Mathias O. schrieb:
> Guten Morge,
>
> so langsam fühle ich mich echt verarscht.

Das Problem sitzt meist vorm Rechner

[Mathias O. (m-obi)]

lmao schrieb:
> Mathias O. schrieb:
>> Guten Morge,
>>
>> so langsam fühle ich mich echt verarscht.
>
> Das Problem sitzt meist vorm Rechner
Soweit bin ich auch schon gekommen.


Ausgabe sieht so aus:

-------------- Build: Release in IRMP (compiler: GNU AVR GCC Compiler)---------------

avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c main.c -o obj\Release\main.o
avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c uart.c -o obj\Release\uart.o
avr-g++.exe -LD:\opencv\build\x86\mingw\lib  -o bin\Release\IRMP.elf obj\Release\main.o obj\Release\uart.o   -Wl,-Map=bin\Release\IRMP.map,--cref  
Output size is 2.98 KB
Running project post-build steps
cmd /c "avr-objdump -h -S bin\Release\IRMP.elf > bin\Release\IRMP.lss"
avr-objcopy -R .eeprom -R .fuse -R .lock -R .signature -O ihex bin\Release\IRMP.elf bin\Release\IRMP.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.eep
avr-objcopy --no-change-warnings -j .lock --change-section-lma .lock=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.lock
avr-objcopy --no-change-warnings -j .signature --change-section-lma .signature=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.sig
avr-objcopy --no-change-warnings -j .fuse --change-section-lma .fuse=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.fuse
srec_cat bin\Release\IRMP.fuse -Intel -crop 0x00 0x01 -offset  0x00 -O bin\Release\IRMP.lfs -Intel
srec_cat: bin\Release\IRMP.fuse: 1: file contains no data
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)

[Oliver S. (oliverso)]

Mathias O. schrieb:
> avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c main.c -o
> obj\Release\main.o
> avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c uart.c -o
> obj\Release\uart.o
> avr-g++.exe -LD:\opencv\build\x86\mingw\lib  -o bin\Release\IRMP.elf
> obj\Release\main.o obj\Release\uart.o
> -Wl,-Map=bin\Release\IRMP.map,--cref

Für einen avr ist der Lib-Pfad völlig unsinnig, dafür fehlen da ein paar 
der sonst üblichen Optionen. Bist du sicher, daß deine IDE auch 
tatasächlich AVR-Programme erezugen kann, und dafür richtig eingestellt 
ist?

Lass dir mal mit MFile ein makefile erezugen, und compiler damit. Oder 
pack deine Sourcen ins AVR-Studio, und lass das mal kompilieren.

Oliver

[Mathias O. (m-obi)]

Habs es entfernt. Hab nun

-------------- Build: Release in IRMP (compiler: GNU AVR GCC Compiler)---------------

avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c main.c -o obj\Release\main.o
avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c uart.c -o obj\Release\uart.o
avr-g++.exe  -o bin\Release\IRMP.elf obj\Release\main.o obj\Release\uart.o   -Wl,-Map=bin\Release\IRMP.map,--cref  
Output size is 2.78 KB
Running project post-build steps
cmd /c "avr-objdump -h -S bin\Release\IRMP.elf > bin\Release\IRMP.lss"
avr-objcopy -R .eeprom -R .fuse -R .lock -R .signature -O ihex bin\Release\IRMP.elf bin\Release\IRMP.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.eep
avr-objcopy --no-change-warnings -j .lock --change-section-lma .lock=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.lock
avr-objcopy --no-change-warnings -j .signature --change-section-lma .signature=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.sig
avr-objcopy --no-change-warnings -j .fuse --change-section-lma .fuse=0 -O ihex bin\Release\IRMP.elf bin\Release\IRMP.fuse
srec_cat bin\Release\IRMP.fuse -Intel -crop 0x00 0x01 -offset  0x00 -O bin\Release\IRMP.lfs -Intel
srec_cat: bin\Release\IRMP.fuse: 1: file contains no data
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)

Wenn er keine AVR-Programme erzeugen würde, warum blinkt dann die Led 
wie im Programm vorgegeben?
Irgendwas scheint mit dem Interrupt im UART nicht zu funktionieren.

Wenn ich statt

void uart_putc(unsigned char data)
{
    unsigned char tmphead;


    tmphead  = (UART_TxHead + 1) & UART_TX_BUFFER_MASK;

    while ( tmphead == UART_TxTail ){
        ;/* wait for free space in buffer */
    }

    UART_TxBuf[tmphead] = data;
    UART_TxHead = tmphead;

    /* enable UDRE interrupt */
    UART0_CONTROL    |= _BV(UART0_UDRIE);

}/* uart_putc */

das so verwende

void uart_putc(unsigned char data)
{
    while
    (!(UCSRA & (1<<UDRE)))
    {
    }
    UDR = data;

}/* uart_putc */

funktioniert es.

[Frank M. (ukw) (Moderator)]

Mathias O. schrieb:
>     UART0_CONTROL    |= _BV(UART0_UDRIE);

Das sieht so aus, als ob der Interrupt zu UART0_UDRIE nicht passt. Der 
müsste eigentlich so aussehen:

ISR(USART_UDRE_vect)
{
  ....
}

Aber: Wenn er denn wirklich falsch wäre, dann müsste der Compiler auch 
eine Warnung ausgeben, dass der Interrupt-Handler-Name falsch wäre (so 
ähnlich jedenfalls). Ausserdem glaube ich nicht, dass ein derartiger 
Schnitzer im Fleury-Source ist.

Sehr merkwürdig das ganze.

[MWS (Gast)]

Wenn Du das Hex-File postest, schau' ich mal rein, was los ist.

[Frank M. (ukw) (Moderator)]

MWS schrieb:
> Wenn Du das Hex-File postest, schau' ich mal rein, was los ist.

Die ersten paar Zeilen aus der lss-Datei (Interrupt-Vektor-Tabelle) 
wären lesbarer und deshalb interessanter ;-)

[Mathias O. (m-obi)]

Danke schonmal

[MWS (Gast)]

Frank M. schrieb:
> Die ersten paar Zeilen aus der lss-Datei (Interrupt-Vektor-Tabelle)
> wären lesbarer und deshalb interessanter ;-)

Die Tabelle seh' ich auch so und die ist Murks, da stehen an den 
Vektoren RJMPs statt JMPs drin, der letzte Teil der IVT ist Müll. Der 
Stackpointer wird auf 0x025F initialisiert, müsste beim ATM16 auf 0x045F 
sein. Da stimmt das Target nicht.

[Mathias O. (m-obi)]

D.h. was genau? Wo muss ich was ändern? Ich arbeite mit Code::Blocks.

[Karl H. (kbuchegg)]

?

avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c main.c -o obj\Release\main.o
avr-gcc.exe  -mmcu=atmega16 -Os -DF_CPU=16000000UL     -c uart.c -o obj\Release\uart.o
avr-g++.exe -LD:\opencv\build\x86\mingw\lib  -o bin\Release\IRMP.elf obj\Release\main.o obj\Release\uart.o   -Wl,-Map=bin\Release\IRMP.map,--cref

einmal avr-gcc und dann avr-g++ ?
Auch fehlt mir in der Linker Anweisung die Angabe vom Mega16

Poste doch mal dein makefile. Da scheint ein ordentlicher Wurm drinnen 
zu sein.

[Frank M. (ukw) (Moderator)]

Mathias O. schrieb:
> avr-g++.exe  -o bin\Release\IRMP.elf obj\Release\main.o
> obj\Release\uart.o   -Wl,-Map=bin\Release\IRMP.map,--cref

Bei mir steht da immer noch mindestens ein "-mmcu=xxxxxx".

Außerdem wundere ich mich, warum zum Linken avr-g++ statt avr-gcc 
aufgerufen wird.

Edit: Karl Heinz war schneller :-)

[Mathias O. (m-obi)]

Code::Blocks generiert es selber, ich finde keins.

[kif (Gast)]

Hast du mal von Atmel Studio gehört?

Kostet nichts.

[Mathias O. (m-obi)]

Super endlich. Hab in den Linker settings noch -mmcu=atmega16 angegeben 
und nun funktioniert es endlich richtig alles.
Ihr seid einfach klasse und sooooo geduldig.

[MWS (Gast)]

Mathias O. schrieb:
> Ich arbeite mit Code::Blocks.

Das hab' ich gelesen, kenn' mich mit Codeblocks aber nicht aus.

Vielleicht compilierst Du auch etwas anderes, als dass Du auf den µC 
brennst, vergleich' dich mal die Erstellungs-/Änderungszeiten der 
beteiligten Dateien. Im Hex-Code werden Befehle ausgeführt, die nicht im 
C-Code wie oben zu finden sind:

in  r24,p11
ori  r24,k60
out  p11,r24 --> DDRD |= (1 << PD5)|(1 << PD6);

cbi  p11,b3 --> ? (löscht Bit3 in DDRD)

sbi  p12,b5 --> PORTD |= (1 << PD5);

ldi  r24,kFF
ldi  r25,kE1
ldi  r26,k04
L002E:
subi  r24,k01
sbci  r25,k00
sbci  r26,k00
brne  L002E --> _delay_ms(100);

[Konrad S. (maybee)]

Mathias O. schrieb:
> Super endlich. Hab in den Linker settings noch -mmcu=atmega16 angegeben
> und nun funktioniert es endlich richtig alles.

Das hättest du schon gestern haben können. :-)

Konrad S. schrieb im Beitrag #3601753:
> Oder evtl. unterschiedliche µCs für Kompilieren und Linken angegeben?

Konrad S. schrieb im Beitrag #3602476:
> Es wäre noch interessant zu wissen, wie die Aufrufe vorher aussahen,
> einmal beim Kompilieren von main.c und einmal beim Linken des Programms.

[Mathias O. (m-obi)]

@MWS: Ich hatte zwischeinzeitlich nochwas geändert/hinzugefügt. Wollte 
das er erst was sendet per UART wenn ich einen Taster drücke.

@Konrad: Ja ja. Im nachinein ist man immer schlauer ;). Aber ich 
verspreche Besserung.