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
:
Bearbeitet durch Admin
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.
Die Arrays liegen folgendermaßen im Quellcode:
1 | uint8_t matrix_0[8][8] = { |
2 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
3 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
4 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
5 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
6 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
7 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
8 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
9 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111}; |
Bin davon ausgegangen, die landen im Flash. Stimmt des nicht???
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
:
Bearbeitet durch User
Wo das Array liegt laesst sich im Linkfile herauslesen. Allenfalls wird ein *.LST file produziert. Das waere dann mit einem Editor lesbar.
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.
Elenchen schrieb: > Die Arrays liegen folgendermaßen im Quellcode: > >
1 | > uint8_t matrix_0[8][8] = { |
2 | > ... |
3 | >
|
> > 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:
1 | uint8_t matrix_0[8][8] = { |
2 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
3 | 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, 0b11111111, |
4 | 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.
Martin Kreiner schrieb: > sehr genau, wie viel SRAM belegt werden muss. Aber nur wenn das Array global ist!!!
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_t matrix_0[8][8] .... |
lausigen 64 Bytes brauchst du nicht auf irgendeine Compiler-Meldung hoffen.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Bitte 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.