Hallo Leute, ich programmiere mit pn2 und avrgcc3.3 in C einen ATmega. Kann mir mal bitte jemand erklären was diese Angaben section size addr .text 11428 0 .data 182 8388704 .bss 211 8388886 .noinit 0 8389097 .eeprom 0 8454144 .stab 20700 0 .stabstr 5703 0 Total 38224 des compilers genau bedeuten? Was landet davon auf dem controller und wo? danke. m.g.
Schon x-mal geschrieben. Kurz: .bss + .data = static RAM allocation .text + .data = ROM allocation Denk an den Stack, der braucht auch RAM.
@jörg, tschuldigung wenn ich nochmal nachfrage was die einträge .stab .stabstr bedeuten. danke m.g.
@jörg ich habe noch nicht gesagt warum mich das interessiert. mein programm läuft seit total von 30257 auf 38224 gestiegen ist nicht mehr. oder bilde ich mir das ein? danke m.g.
.stab und .stabstr enthalten die Debuginformationen. Die "total"-Angabe ist bei einem Microcontroller zu nichts zu gebrauchen. Ich vermute mal, du wirst an stack overflow leiden. Dafür helfen die Zahlen nur Ansatzweise (Größe RAM - static RAM = Platz für Stack und Heap), du musst vor allem ein Gefühl dafür bekommen, wie viel Stack die einzelnen Funktionen so brauchen.
@jörg, und wie ist es zu erklären, dass unter diesen umständen .data 182 8388704 .bss 211 8388886 mein mega32 an stack-overflow leidet? m.g.
Das musst du dich doch aber selbst fragen und nicht mich. Schließlich kenne ich deinen Code nicht. Man kann sich beliebig große Variablen in den Stack nageln, wenn man nur will...
@jörg, bisher dachte ich immer header und stack haben ohne funktionsaufruf absolut nichts miteinander zu tun. wie ist dann, wenn es sich wirklich bei meinem problem um ein stack-overflow dreht zu erklären, dass ich nur durch das einfügen bzw. weglassen von header-files das problem provozieren oder beheben kann? also etwas konkreter. in meiner völligen verzweiflung habe ich einen test geschrieben, der mir zeigen soll ob der controller eine aktion ordnungsgemäss oder fehlerhaft durchzieht. es geht darum, dass der controller daten aus dem eeprom holen soll, diese umrechnet und in einer struktur ablegt. den test dazu habe ich in zwei verschiedene main-files gepackt. es ist nun tatsächlich so, dass der test in der einen variante läuft und in der anderen nicht. wobei der unterschied zwischen beiden lediglich die header sind. die mains an sich sind absolut identisch. oder hab ich da einen trugschluss begangen? ich schicke die beiden mains mal mit. zuerst das wos schiefgeht. in einer weiteren nachricht das das läuft. ich hoffe das ist ok. m.g.
da hab ich wohl irgend einen fehler gemacht! sind beide nicht mitgekommen. falls interesse besteht versuch ichs nochmal. m.g.
Erstens, du benutzt eine steinalte Compilerversion. Das würde ich an deiner Stelle ändern. Zweitens: du hast natürlich Recht, normalerweise sollte eine Headerdatei keinen Speicher benötigen, aber das hängt natürlich ganz und gar von der Headerdatei ab. Das Beispiel wäre sicher hülfreich.
Sorry, du musst das schon nachvollziehbar machen. Weiß der Geier, was alles in dem Dutzend include-Files passiert.
was würde denn dazu beitragen ohne das ganze projekt durch die leitungen zu schieben?
Irgendwas, mit dem es nachvollziehbar ist. Das schließt eine geschlossene Compilierfähigkeit ein.
Zuerst mal solltest du rausfinden, welcher von den ganzen Headern das Problem verursacht.
das ist eben leider nicht so einfach möglich ohne das projekt völlig auseinanderzunehmen. es gibt offensichtlich nur probleme wenn ich das projekt in vollem umfang compiliere. sobald ich teile (keine bestimmten!) herauslöse verschwinden die schwierigkeiten. und wie schon in einem anderen thread erwähnt beginnt es damit, dass der controller anfängt falsch zu rechnen. aber ich versteh schon bei so einem diffusen problem ist ferndiagnose schwierig. da werde ich wohl weiter schattenboxen müssen. ich danke für die unterstützung. m.g.
@rolf das is schon klar. nur ist das eben nicht so einfach, weil ich das ganze projekt natürlich stück für stück aufgebaut habe. das heisst die funktionen die ich zuletzt eingebunden habe sind weitgehend unbedingt auf die anwesenheit der "basisfunktionen" angewiesen. ich kann zwar wie schon erklärt die probleme durch abspecken beeinflussen, nur bin ich mir dabei nicht sicher ob die funktion der funktion das problem ist oder ihre pure anwesenheit. m.g.
Hi dann solltest du eben nicht "Schattenboxen" sondern systematisch vorgehen. Als erstes würde ich an deiner Stelle prüfen wie weit der Stack nach unten kommt. Wie man einen ganz guten Schätzwert dafür ermittelt wurde hier schon mehrfach erläutert. Matthias
Wenn man eine Möglichkeit für Debugausgaben hat, kann man den Stack auch zur Laufzeit ermitteln lassen und hat dann den realen Wert. Ich füge dazu die folgende Funktion in meine Quellen ein. Diese Funktion geht aber nur, wenn man kein malloc() benutzt. Mit malloc() wird das erheblich komplizierter und auch die Gefahr von Speicherproblemen ist erheblich größer.
1 | #include<io.h> |
2 | |
3 | typedef unsigned char u8; |
4 | typedef unsigned short u16; |
5 | |
6 | #define FREE_MARK 0x77
|
7 | |
8 | extern u8 __bss_end; // lowest stack address |
9 | |
10 | extern u8 __stack; // highest stack address |
11 | |
12 | |
13 | u16 stack_size( void ) // available stack |
14 | {
|
15 | return (u16)&__stack - (u16)&__bss_end + 1; |
16 | }
|
17 | |
18 | |
19 | u16 stack_free( void ) // unused stack after last |
20 | call
|
21 | {
|
22 | u8 flag = 1; |
23 | u16 i, free = 0; |
24 | u8 * mp = &__bss_end; |
25 | |
26 | for( i = SP - (u16)&__bss_end + 1; i; i--){ |
27 | if( *mp != FREE_MARK ) |
28 | flag = 0; |
29 | free += flag; |
30 | *mp++ = FREE_MARK; |
31 | }
|
32 | return free; |
33 | }
|
Peter
Hallo Leute, dank allen die sich am forum beteiligt haben. für die dies interessiert hier die lösung: der neue mega32l ist defekt. anzunehmen ist ein ram-fehler. m.g.
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.