Problem beim Programmieren des Atmega2560.

[Elenchen (Gast)]

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

[Zac Hobson (Gast)]

Autsch. Jetzt aber.

Die Info ist auf der mageren Seite.

[Elenchen (Gast)]

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.

[oszi40 (Gast)]

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?

[Uwe (Gast)]

Code zeigen !

[CC (Gast)]

Ist es vielleicht der RAM-Verbrauch?

[Elenchen (Gast)]

Liegt ja alles im Flash. Und der sollte 256 kB groß sein

[Martin V. (oldmax)]

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

[Helmut L. (helmi1)]

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 (Gast)]

Die Arrays liegen folgendermaßen im Quellcode:

uint8_t matrix_0[8][8] = { 
  0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111};

Bin davon ausgegangen, die landen im Flash. Stimmt des nicht???

[Einhart P. (einhart)]

Wenn ich mir dein Programmiergerät so ansehe, dann wird der Mega2560 
anscheinend nicht unterstützt.

Zitat:
Unterstützte Controllertypen:
•AT90PWM3
•AT90S1200
•AT90S2343
•AT90S4414
•AT90S4433
•AT90S8515
•AT90S8535
 •ATmega103
•ATmega128
•ATmega16
•ATmega161
•ATmega162
•ATmega163
•ATmega164P
•ATmega168
•ATmega169
•ATmega32
•ATmega324P
•ATmega328P
•ATmega329
•ATmega3290
•ATmega48
•ATmega64
•ATmega644
•ATmega8
•ATmega8515
•ATmega8535
•ATmega88
 •ATtiny12
•ATtiny13
•ATtiny15
•ATtiny2313
•ATtiny24
•ATtiny25
•ATtiny26
•ATtiny44
•ATtiny45
•ATtiny84
•ATtiny85

[Zac Hobson (Gast)]

Wo das Array liegt laesst sich im Linkfile herauslesen. Allenfalls wird 
ein *.LST file produziert. Das waere dann mit einem Editor lesbar.

[Helmut L. (helmi1)]

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.

[Karl H. (kbuchegg)]

Elenchen schrieb:
> Die Arrays liegen folgendermaßen im Quellcode:
>
>

> uint8_t matrix_0[8][8] = {
> ...
>

>
> 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.

[Martin K. (maart)]

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.

[Helmut L. (helmi1)]

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.

[Martin K. (maart)]

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:

uint8_t matrix_0[8][8] = { 
  0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111,
                   0b11111111, ..........

 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.

[Julian B. (julinho)]

Martin Kreiner schrieb:
> sehr genau, wie viel SRAM belegt werden muss.

Aber nur wenn das Array global ist!!!

[Karl H. (kbuchegg)]

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 ...

uint8_t matrix_0[8][8] ....

lausigen 64 Bytes brauchst du nicht auf irgendeine Compiler-Meldung 
hoffen.

[Martin K. (maart)]

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...."

[Karl H. (kbuchegg)]

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.

[Martin K. (maart)]

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.

[Svenska (Gast)]

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.

[Martin V. (oldmax)]

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