Hi, habe ein Problem beim Programmieren des Atmega2560.
Ich nutze AVR Studio 5 als Entwicklungsumngebung und My Smart USB MK2
als Programmieradapter.
Ich kann meinen Mikrocontroller auch wunderbar programmieren, aber
sobald mein Code größer wird als ca. 10,2 kByte läuft das Programm nicht
mehr.
Das Programm lässt sich in den Controller mittels USB->ISP übertragen,
dieser verhält sich aber absolut unlogisch und führt das Programm nicht
mehr schlüssig aus.
Kennt jemand as Problem?
Lieben Gruß,
Elena
Was verstehst du denn nicht?
Ich übertrage 10 kB Quellcode -> Übertragung erfolgreich ->
Mikrocontroller tut seinen dienst.
Ich übertrage 10,2 kB Quellcode -> Übertragung erfolgreich ->
Mikrocontroller spinnt !?!?
Fehler im Quellcode können ausgeschlossenen werden. Habe den Code mal
nur mit sinnlosen Arrays auf 10,2 aufgeblasen und nichts am
Programmfluss geändert. Trotzdem tritt der Fehler auf.
Ein gescheiter Betreff erhöht die Zahl der Antworten.
http://www.mikrocontroller.net/articles/Netiquette> sobald mein Code größer wird als ca. 10,2 kByte läuft
Deine Einstellungen gründlich kontrolliert? Wenn ja welche?
Hi
Bist du sicher, das dein Programm im Flash liegt ? Wenn ich da von
"sinnlosen Arrays" lese, assoziere ich automatisch Ram. Da ist dann das
Verhalten logisch, weil du dem Stack irgendwann einmal seine Freiheit
nimmst und es ein kleiner Krieg zwischen Variable und Stack wird.
Allerdings ist so eine Aussage nur zuverlässig abzugeben, wenn man sich
im Quältext vergewissert hat, das dem so ist. Na ja, vielleicht kann dir
die NSA helfen, die hat sicherlich bereits das Programm gesichtet....
Gruß oldmax
Nicht alles beim AVR landet nur im Flash. Einiges davon wird beim Start
vom Startupcode ins RAM kopiert. Besonders wenn du Initialisierte Arrays
hast.
Ohne einen Auszug aus dem Code zu sehen ufert das wieder in
Kaffeesatzleserei aus.
Elenchen schrieb:> Bin davon ausgegangen, die landen im Flash. Stimmt des nicht???
Teils, teils. Das liegt zuerst im Flash wird dann aber ins RAM kopiert.
Der AVR ist eine Aiken Maschine wo Code und Daten erstmal getrennt sind.
#include <pgmspace.h>
prog_uint8_t matrix_0[8][8] = {
schreib das mal so.
>> Bin davon ausgegangen, die landen im Flash. Stimmt des nicht???
Nein, das stimmt nicht.
Was lässt dich davon ausgehen, dass dieses Array im Flash sein sollte?
D.h. Genau genommen existiert das Array sogar 2 mal :-)
Einmal im Flash, damit dann von dort zur Laufzeit das richtige Array des
Programms erzeugt werden kann und mit den vorgegebenen Werten
initialisiert wird. Denn die müssen ja auch von irgendwo her kommen.
Aber für dich als Programmierer liegt das Array erst mal im SRAM und
verbraucht somit dort Platz.
Karl Heinz schrieb:> D.h. Genau genommen existiert das Array sogar 2 mal :-)> Einmal im Flash, damit dann von dort zur Laufzeit das richtige Array des> Programms erzeugt werden kann und mit den vorgegebenen Werten> initialisiert wird. Denn die müssen ja auch von irgendwo her kommen.>> Aber für dich als Programmierer liegt das Array erst mal im SRAM und> verbraucht somit dort Platz.
Da sollte aber der Compiliervorgang mit einer Fehlermeldung abgebrochen
werden.
Martin Kreiner schrieb:> Da sollte aber der Compiliervorgang mit einer Fehlermeldung abgebrochen> werden.
Noe, warum. Das macht der Compiler ja von sich aus. Er legt das Array
initialisiert im Flash an. Dort kannst du aber nicht direkt zu greifen
beim AVR (Code und Daten getrennt). Also kopiert der Startupcode diese
Daten dann ins RAM. Erst da kannst du zugreifen.
Willst du das im Flash addressieren brauchst du dafuer
"pgm_read_byte(x)"
Sonst kommst du beim AVR nicht an die Daten im Flash ran. Deshalb legt
der Compiler das teil 2 x an.
Helmut Lenzen schrieb:> Martin Kreiner schrieb:>> Da sollte aber der Compiliervorgang mit einer Fehlermeldung abgebrochen>> werden.>> Noe, warum. Das macht der Compiler ja von sich aus. Er legt das Array> initialisiert im Flash an. Dort kannst du aber nicht direkt zu greifen> beim AVR (Code und Daten getrennt). Also kopiert der Startupcode diese> Daten dann ins RAM. Erst da kannst du zugreifen.
Alles soweit richtig. Der Compiler weiß aber hierdurch:
sehr genau, wie viel SRAM belegt werden muss.
Helmut Lenzen schrieb:> Willst du das im Flash addressieren brauchst du dafuer> "pgm_read_byte(x)"> Sonst kommst du beim AVR nicht an die Daten im Flash ran. Deshalb legt> der Compiler das teil 2 x an.
Brauchst du mir nicht zu sagen, ich weiß das.
Martin Kreiner schrieb:> Alles soweit richtig. Der Compiler weiß aber hierdurch:> sehr genau, wie viel SRAM> belegt werden muss.
Und?
Es ist ihm trotzdem egal, selbst wenn das Array global wäre.
Denn der Compiler sieht nicht das komplette Programm, weiß also nicht,
wieviel SRAM in Summe verbraten wird. Das sieht erstmalig der Linker.
Gut, der könnte einen Fehler auswerfen, aber eigentlich ist so etwas
nicht die typische Aufgabe eines Linkers. ZUmindest dann nicht, wenn es
sich wie bei avr-gcc um einen allgemeinen Linker handelt, der von einem
AVR bis hoch zu einem Supercomputer benutzt wird.
Aber: Nachdem das Programm fertig ist, gibt es ja die Möglichkeit, dass
die Toolchain die belegten Speichergrößen ausgibt. Und da steht dann
drinnen, dass zb das SRAM mit 98% belegt wurde, oder gar mit 105%. Und
dann weiß man als Entwickler: huch, ich habe es übertrieben.
Nur muss man sich halt diese Statistik auch mal ansehen.
Wegen ...
1
uint8_tmatrix_0[8][8]....
lausigen 64 Bytes brauchst du nicht auf irgendeine Compiler-Meldung
hoffen.
Karl Heinz schrieb:> Und?> Es ist ihm trotzdem egal, selbst wenn das Array global wäre.>> Denn der Compiler sieht nicht das komplette Programm, weiß also nicht,> wieviel SRAM in Summe verbraten wird. Das sieht erstmalig der Linker.> Gut, der könnte einen Fehler auswerfen, aber eigentlich ist so etwas> nicht die typische Aufgabe eines Linkers. ZUmindest dann nicht, wenn es> sich wie bei avr-gcc um einen allgemeinen Linker handelt, der von einem> AVR bis hoch zu einem Supercomputer benutzt wird.
Aha, der Karl Heinz hat die Goldwaage gefunden. Schön. Ob Compiler,
Linker wie auch immer.
Karl Heinz schrieb:> Aber: Nachdem das Programm fertig ist, gibt es ja die Möglichkeit, dass> die Toolchain die belegten Speichergrößen ausgibt. Und da steht dann> drinnen, dass zb das SRAM mit 98% belegt wurde, oder gar mit 105%.
Aha. Genau das meinte ich mit Compiliervorgang. Ok, sprachlich nicht
100% exakt.
Karl Heinz schrieb:> Nur muss man sich halt diese Statistik auch mal ansehen.
Wer diese Fehlermeldung im Studio übersieht, der braucht ganz dringend
eine starke Brille.
Karl Heinz schrieb:> Wegen ...uint8_t matrix_0[8][8] ....> lausigen 64 Bytes brauchst du nicht auf irgendeine Compiler-Meldung> hoffen.
Du bist eben auch nur ein Compiler: Du kennst den restlichen Code nicht.
Elenchen hat ja geschrieben: "Die Arrays...."
Martin Kreiner schrieb:> Aha, der Karl Heinz hat die Goldwaage gefunden. Schön. Ob Compiler,> Linker wie auch immer.
Entweder wir geben korrekte Erklärungen, oder wir lassen es.
Wenn du eine derartig einfache Nomenklatur schon als unwichtig
empfindest, dann will ich gar nicht wissen, wo du noch daneben haust, wo
es dann tatsächlich wichtig wäre, zwischen den Dingen korrekt zu
unterscheiden. Compiler und Linker, sowie deren Aufgaben unterscheiden
zu können, ist nichts esoterisches, sondern hat ganz praktische
handfeste Auswirkungen beispielsweise bei der Zuordnung von
Fehlermeldungen und den daraus abgeleiteten Rückschlüssen auf die
zugrunde liegenden Codeprobleme.
Es gibt schon genug hier im Forum, die mit Halbwissen agieren.
Karl Heinz schrieb:> Entweder wir geben korrekte Erklärungen, oder wir lassen es.
Ich werde mich bemühen, wirklich.
Karl Heinz schrieb:> Wenn du eine derartig einfache Nomenklatur schon als unwichtig> empfindest, dann will ich gar nicht wissen.........
...ja, hast ja Recht.
Deklariere deine sinnlosen Arrays mal mit __flash (modernen GCC
vorausgesetzt), dann bleiben die auch nur da. Ansonsten musst du mit
<pgmspace.h> und PROGMEM hantieren. Beides wird im C-Tutorial erklärt.
Die 10 KB wirken so erstmal ziemlich willkürlich, ich hätte Fehler durch
einen nicht unterstützten Programmer eher weiter oben (>50 KB) erwartet.
Das klingt wirklich eher nach RAM- als nach Flashproblem.
Wirf einen Blick ins Linkerfile und notfalls einen Debugger auf den
Controller.
Hi
Da müssen schon sehr viele sinnlose Arrays existieren, um 8 k SRam zu
sprengen oder dein Stack läuft durch rekursive Aufrufe aus dem Ruder. Es
sind keinesfalls 10 k Programm, die eine ordentliche Funktion in der von
dir beschriebenen Art verhindern. Na ja, grobe Programmierfehler lass
ich jetzt mal außen vor.
Gruß oldmax
