Austausch Atmga16 gegen Atmega644

Ich habe ein kleines problem was ich nicht verstehen...
Ich möchte für eine Anwendung ein Olimex ProtoBoard P40-USB verwenden..um mal schnell das neu gelieferte Protoboatd zu testen habe ich einen Atmega644 draufgesteckt(Pinkompatible mit Atm 16/32) und die von Olimex Blinkcode verwendet...Nur ging diese mit dem 644er nicht, wohl aber mit dem 16 oder 32er. Hier mal der Code:

Code:

---


/*    Sample program for Olimex AVR-P40-USB with ATMega16 processor
 *    Blink Led
 *    Compile with AVRStudio+WinAVR (gcc version 3.4.6) */

#define    __AVR_ATmega644__    1  // CPU Typ Angeben
#ifndef F_CPU
#define F_CPU    8000000    // 8 MHz
#endif

#include "avr/io.h"

void PORT_Init()
{
    PORTB = 0b00000000;
    DDRB  = 0b00000001;        //set Led as output
}

int main()
{
    unsigned int i;
    PORT_Init();
   
    while (1)
    {
        PORTB = PORTB | 0b00000001;
        for (i=50000; i; i--);    // Zeitschleife
        PORTB = PORTB & 0b11111110;
        for (i=50000; i; i--);    // Zeitschleife
    }
}


******************************************************************************
/*    Sample program for Olimex AVR-P40-USB with ATMega16 processor
 *    Blink Led
 *    Compile with AVRStudio+WinAVR (gcc version 3.4.6) */

#define    __AVR_ATmega644__    1
#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>
void PORT_Init()
{
    PORTB = 0b00000000;
    DDRB  = 0b00000001;        //set Led as output
}

int main()
{

    PORT_Init();
    while (1)
    {
       
        PORTB = 0b11111110;
      _delay_ms(1000);
        PORTB = 0b00000001;
        _delay_ms(1000);
    }
}
******************************************************************************

---

Bei Atmega 16/32 gehen oberer und unterer Code, beim 644 nur der untere, beim oberen habe ich "dauerlicht"

es ist zwar nicht lebendbedrohlich, aber ich kann mir das nicht erklären warum das so ist. Da ich das Board ja mit einem 644 oder gar mit einem 1284p bestücken möchte , will ich Fehler im Vorfeld ausmärzen , nicht das ich mich später dumm und dähmlich suche...

Die Fuses stimmen , alle kontrolliert.. (soweit ich diese für richtig halte... ;) )

Weiss wer einen Rat ??

Gruss und Dank Gerhard

Zitat:

---

Zitat von oderlachs

aber ich kann mir das nicht erklären warum das so ist.

---

Ich hätte da einen ganz heißen Tipp: Die Optimierung im Compiler hat zugeschlagen. Die Schleife im oberen Programm tut effektiv nichts. Nach ihrer Ausführung ist der Speicherinhalt und Zustand des µCs unverändert. Damit kann der Compiler ganz rausnehmen - Und das tut er bei eingeschalteter Codeoptimierung auch. Ich schätze, dass du den unteren Code mit Optimierung übersetzt hast, den oberen aber ohne.

Mit solchen Tricks legst du dich effektiv selbst hinein. Es gibt für solche "kritischen" Aufgaben nicht ohne Grund fertige Lösungen in der avr-libc.

mfG
Markus

Danke Marcus für den Tip !
ich habe mal alle Optimierungseinmstellungen im AVR-Studio durch ...keine Änderung..bleibt wie es ist...bleibt eben Chipabhängig ob es funnzt. Habe aber auch darin keine Erfahrung und mich noch nie damit befasst... default ist -OS eingestellt.


Anhang 28281

Nun ja ich kann ja meinen Code ATMega644 freundlich schreiben, nur hat es mich verwundert , dass ein solcher Effekt aufgetreten ist...

Gerhard

Zitat:

---

Zitat von oderlachs

...keine Änderung..bleibt wie es ist...bleibt eben Chipabhängig ob es funnzt.

---

Sonderbar. Die Moral von der Geschicht': Einfache Warteschleifen funktionieren (ohne Inline-Assembler-Magie) nicht. Wie geschrieben, die mitgelieferten Funktionen nutzen ist zuverlässiger und "sauberer".

mfG
Markus

Nun ja , ich hätte diesen "Mangel" (???) nie entdeckt, da aber das Board gerade frisch aus UK ankam wollt ich es schnell testen...den org. TestledCode von Olimex genommen, da ja als AVR-Projekt angeboten wird und los...
Da ich zur Zeit mit Atmega644 hantiere und den zur Hand hatte kam dieser auf die Fassung...das Andere ist bekannt...
Normalerweise schreibe ich benötigten Code selber, da weiss man, oder auch nicht(?) ;) , was man verbrochen hat wenn s nicht geht..

Gruss und Dank für alles Überlegen und Helfen
Gerhard

Ich bin gerade noch über einen anderen Fehler gestolpert: #define __AVR_ATmega644__
Makros dieser Art bitte niemals selbst definieren. Das passiert intern durch Compiler/avr-libc, wenn du das machst können alle möglichen und unmöglichen Dinge kaputt gehen.

Evtl. kommt das Problem auch von daher.

Nachtrag: Ich habe das ganze im Schnelldurchgang getestet. Bei mir (Ubuntu 12.04, avr-gcc 4.5.3) zeigt sich unabhängig vom AVR bei beiden Blöcken das jeweils erwartete Verhalten. Die leere Schleife wird wegoptimiert, das Delay findet sich im Assembler-Listing. Auf eine Simulation habe ich aufgrund der Eindeutigkeit verzichtet.

mfG
Markus

Ach ja: <avr/io.h>, nicht "avr/io.h" (oberer Codeblock). Alles in spitzen Klammern sucht der Compiler bei den angegebenen Suchpfaden selbst, alles in Anführungszeichen ist eigentlich relativ zum Pfad an dem sich die Quelltextdatei befindet.

Danke Markus für alle Deine Mitarbeit und Überlegungen, ich habe das auch schon mit den #include ".." bemerkt und geändert...aber der Compiler bzw AVR-Studio hätt auch gemeckert wenn die io.h nicht zu finden wäre.
Mir ist es ja nur so komisch, das es mit andern µC Typen geht und mit dem 644 nicht...wär ja mal interessant zu wissen warum , aber wollen wir uns damit nicht aufhalten...
Damit ich mit meinem Programm weiter komme hab ich nun einen ATM32 aufgesteckt und sitzt an der Sache mit der LCD ausgabe,
die mir nicht so gelingen möchte..aber habe auch nicht sooo die Zeit dafür..es ist Gartenzeit für Hobbygärtner ;)

Ich könnte ja auch fertige libs aus dem web nehmen, aber ersten möchte ich mal selber was schreiben, besonders weil man dabei viel lernt und die Sache auch "hoffentlich" versteht...

Da ich im Projekt Usart, I2C, ADC , 4Bit-LCD benötige , One-Wire eigendlich auch, ist es schon ein grosses Projekt, für mich gesehen und da will ich mich Stück für Stück rantasten..so sollte auch dann gleich mit dem ATM644 angefangen werden ummgenügend Speicher für Code zu haben...

Sonntags-Gruss und Danke

Gerhard