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.
Ich war mal wieder woanders mit meinen Gedanken... Der Chip um den es sich dreht heißt: at90s2313
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
Der Fehler tritt fast unabhängig von der Dateigröße auf. Im Anhang befindet sich ein ganz simpler Code zum testen.
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
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.
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
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).
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?
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.
Ach so:
> outp(255,DDRB);
Bitte
DDRB = 255;
schreiben. outp()/inp() sind ,abgekündigt'.
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.
> 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...
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.
>-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...
@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.
... 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???
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.