mikrocontroller.net

Forum: Compiler & IDEs Hex-Datei zu groß??


Autor: Julius Krebs (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte heute ein kleines Programm, welches ich zuvor mit dem
Gnu-Compiler zu einer Hex-File kompiliert habe auf einen at90s8535
übertragen. Dazu nutze ich das stk500 mit entsprechneder Software.

Die Übertragung bricht jedoch leider bei etwa einem Viertel des
Ladevorgangs ab. Bei einem Chip mit doppelt so viel Speicher (4k)
erfolgt der Abbruch erst nach der Hälfte. Bei einem noch größerem
klappt es problemlos. Daraus entnehme ich, dass der Speicher zu klein
ist.
Aber kann das sein?

Im Anhang findet ihr den Statusbericht des Compilers.

Autor: Julius Krebs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich war mal wieder woanders mit meinen Gedanken...
Der Chip um den es sich dreht heißt: at90s2313

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

meine Kristallkugel ist eben wieder angekommen. Mal sehen ob sie
korrekt kalibiriert wurde.

float-Variablen verwendet?

BTW:
Ohne Quellcode ist da ne Aussage schwer zu treffen.

Matthias

Autor: Julius Krebs (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Fehler tritt fast unabhängig von der Dateigröße auf.
Im Anhang befindet sich ein ganz simpler Code zum testen.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

OK. Mein Fehler. Du linkst die fprintf, die printf_flt und die
mathematik-Bibliothek dazu. Das solltest du nur tun wenn du wirklich
Funktionen aus diesen Bibliotheken verwendest. Du mußt also dein
makefile anpassen oder gleich neu erstellen. Weiterhin wäre -Os besser
als Optimierung geeignet als -O3.

Du kannst aber auch Jörgs makefile-Generator verwenden:
http://www.sax.de/~joerg/mfile/

Matthias

Autor: Julius Krebs (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin deinen Anweisungen gefolgt. Kompiliert habe ich dieses Mal
test.c --> Gleicher Fehler wie vorher.
Muss ich wirklich auf einen anderen Compiler umsteigen? Der bestehende
sollte doch eigentlich laufen.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

jetzt verwendest du -O0 was AFAIK gleichbedeutend mit "keine
Optimierung" ist. Das sorgt für sehr große Dateien. Verwende -Os. Du
mußt keinen neuen Compiler verwenden. Höchstens einen aktuellen
WinAVR.

Matthias

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Btw., bitte keine PDF-Dateien, wo ein gewöhlicher Text-Log genügen
würde...  Nur so, ich mache mir nicht erst die Mühe, ein PDF dafür
erst runterzuladen und anzusehen.  Nein, mein ,,Browser'' macht das
auch nicht für mich, da ich den emacs-w3m für diese Foren benutze,
anderfalls editiert man sich ja den Wolf. ;-)

Falls Du es noch nicht kennst:

kommando > logfile.txt 2>&1

schreibt alle Ausgaben in logfile.txt.  Voraussetzung: eine Unix-Shell
(keine Ausrede: auch bei WinAVR ist eine bash mit dabei) oder ein
cmd.exe von WinNT oder höher.  command.com von MS-DOS und seinen
Derivaten kann das nicht (vollständig).

Autor: Julius Krebs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
„PDF-Sache“ verstanden.

-0s, 0s, wird nicht angenommen. s allein zwar schon, doch das hilft
auch nicht weiter.
Muss bei solch einer kleinen Datei wirklich komprimiert werden; liegt
der Fehler nicht woanders?

Ich bin mir sicher, dass meine Problemstellung woanders genauso
aufgetaucht ist. Weiß keiner einen Rat?

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Ahnung, was Du machst.

$ cat test.c
#include <avr/io.h>

int main(void)
{
        outp(255,DDRB);
        for (;;){
                outp(255,PORTB);
                asm("nop");
        }
}
$ avr-gcc -Os -mmcu=at90s2313 -o test.out test.c
$ avr-size test.out
   text    data     bss     dec     hex filename
     94       0       0      94      5e test.out

Hier compiliert das Teil also auf 94 Bytes.

Auch, wenn man die Mathematik-Bibliothek (-lm) noch mit angibt, ergibt
sich keine Änderung, da keine ihrer Funktionen referenziert wird.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so:

>        outp(255,DDRB);

Bitte

  DDRB = 255;

schreiben.  outp()/inp() sind ,abgekündigt'.

Autor: Julius Krebs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich soll DDRB durch 255 ersetzten? Also das versteh ich nun wirklich
nicht.
Genauso geht es mir mit "outp()/inp() sind ,abgekündigt'"

Aber wie es aussieht, liegt es wohl doch an meinem Compiler, auch wenn
ich das nicht ganz glauben kann.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich soll DDRB durch 255 ersetzten?

Nein, Du sollst statt »outp(val, reg);« schreiben »reg = val;«.  Also
einfach eine Zuweisung.

inp() und outp() waren Krücken, die AVR-GCC mal gebraucht hat, weil
die Form der direkten Zuweisung (wie sie von Atmel überall propagiert
wird und in allen anderen AVR-Compilern schon immer drin war) anfangs
im AVR-GCC noch nicht implementiert waren.  Jetzt sind sie
implementiert, daher sind inp() und outp() einfach überflüssig.

Das ist aber natürlich nicht die Ursache Deines Problems.  Die mußt Du
schon noch selbst finden.  Und nein, der Compiler als solches ist das
nicht.  Es ist schwer vorstellbar, daß ein Übertragungsfehler
o. ä. ein Binary so weit kaputt machen, daß es zwar noch ausführbar
ist, aber totalen Unsinn zusammencompiliert.

Aber OK, ich habe mir das PDF nochmal angesehen.  Auch im zweiten PDF
ist nach wie vor »-Wl,-u,vfprintf -lprintf_flt« drin.  Damit erzwingst
Du das Einbinden der Maximalversion von printf(), obwohl Du sie am
Ende gar nicht benutzt.  Da die Maximalversion Gleitkommaroutinen
implementiert, ziehst Du Dir in der Folge noch sackweise Gleitkomma-
Unterprogramme aus anderen Bibliotheken mit rein.  Kein Wunder, daß
Dein Code locker den Rahmen Deines AT90S2313 sprengt.

Aber eigentlich hättest Du das durchaus durch einen Vergleich Deiner
recht aufwendigen und länglichen Compilerkommandozeile mit der von mir
zitierten feststellen können.  Schrittweises Analysieren all der
Optionen (Vergleich mit der Doku des Compilers, sie liegt unter Doc in
Deinem WinAVR-Verzeichnis) hätte Dir irgendwann die Erleuchtung
gebracht.

Außerdem hat Dich Matthias bereits um 17:40 auf ebendieses Problem
hingwiesen.

Nein, das Lernen, mit den vorhandenen Werkzeugen auch wirklich
umzugehen, kann Dir keiner abnehmen.  Wir können die Werkzeuge bauen
(bzw. dabei helfen), können sie dokumentieren, können Dich drauf
hinweisen -- aber gucken mußt Du schon selbst.

Sorry, wenn das jetzt ein wenig sarkastisch geworden ist...

Autor: Julius Krebs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, unter Sarkasmus versteh ich was anderes.
Aber versetz dich doch auch mal in meine Lage: Ich dachte es sein ein
simples Problem, welches bereits des Öfteren aufgetaucht ist.
Schließlich arbeite ich mit den absoluten Grundeinstellungen, welche
vermutlich auch von anderen genutzt werden. Daher dachte ich mir, weil
ich momentan ziemlich im Zeitdruck bin, stellste die Frage (nach
vorherigen Recherchen) im Forum. Und im Vergleich zu anderen Themen,
bei denen bereits ein Suchbegriff bei Google zur Erkenntnis führt, war
das hier och schon etwas spezieller.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>-0s, 0s, wird nicht angenommen. s allein zwar schon, doch das hilft
>auch nicht weiter.

Also: ich habe das gestern Zufällig im Lynx-Browser gesehen, sonst
wäre mir das auch nicht aufgefallen:
Hier ist die Rede von -Os, nicht von -0s (minus oh s, nicht minus null
s). Wenn Du das änderst, dann wird zumindest diese Option ordentlich
erkannt. Und bei dem Rest hat Jörg wohl schon alles gesagt...

Gruß,
Patrick...

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Julius:

> Aber versetz dich doch auch mal in meine Lage: Ich dachte es sein
> ein simples Problem, welches bereits des Öfteren aufgetaucht ist.

War es auch.  Es war ein Versehen, daß diese WinAVR-Version in ihrem
Makefile-Template seinerzeit die Gleitkomma-printf-Version mit
eingebunden hat (das sollte nur als Hinweis drin stehen, mit einem
Kommentarzeichen davor).

Aber das Ding ist hornalt, die aktuelle WinAVR-Version (die nun
immerhin auch schon wieder vom September 2003 ist) hatte das
beseitigt.  Du benutzt also etwas zu altes.

Außerdem war das Makefile-Template immer nur als Anregung gedacht,
sich sein eigenes Makefile zu zimmern.  Um denjenigen, die sich mit
Makefiles erstmal nicht groß befassen wollen, einen Gefallen zu tun,
habe ich dann letztlich Mfile geschrieben.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
um... buoni, realmente buoni luogo e molto utile;) 
http://www.sh8cale.org/teens

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wrote:
> um... buoni, realmente buoni luogo e molto utile;)
> http://www.sh8cale.org/teens

Mist... Wo ist denn gleich nochmal dieser verdammte "Beitrag 
Melden"-Button hin???

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.