Forum: Compiler & IDEs compilerangaben?


von M. Gerlach (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Schon x-mal geschrieben.

Kurz: .bss + .data = static RAM allocation
      .text + .data = ROM allocation

Denk an den Stack, der braucht auch RAM.

von M. Gerlach (Gast)


Lesenswert?

@jörg,

tschuldigung wenn ich nochmal nachfrage was die einträge
.stab
.stabstr
bedeuten.

danke
m.g.

von M. Gerlach (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von M. Gerlach (Gast)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von M. Gerlach (Gast)


Lesenswert?

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

von M. Gerlach (Gast)


Lesenswert?

@jörg,

hier also das zweite main.

danke

m.g.

von M. Gerlach (Gast)


Lesenswert?

da hab ich wohl irgend einen fehler gemacht! sind beide nicht
mitgekommen.

falls interesse besteht versuch ichs nochmal.

m.g.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von M. Gerlach (Gast)


Angehängte Dateien:

Lesenswert?

@jörg

mit dem main-file läufts.

von M. Gerlach (Gast)


Angehängte Dateien:

Lesenswert?

@jörg

mit dem main-file läufts nicht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Sorry, du musst das schon nachvollziehbar machen.  Weiß der
Geier, was alles in dem Dutzend include-Files passiert.

von M. Gerlach (Gast)


Lesenswert?

was würde denn dazu beitragen ohne das ganze projekt durch die leitungen
zu schieben?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Irgendwas, mit dem es nachvollziehbar ist.  Das schließt
eine geschlossene Compilierfähigkeit ein.

von Rolf Magnus (Gast)


Lesenswert?

Zuerst mal solltest du rausfinden, welcher von den ganzen Headern das
Problem verursacht.

von M. Gerlach (Gast)


Lesenswert?

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.

von M. Gerlach (Gast)


Lesenswert?

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

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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

von Peter Dannegger (Gast)


Lesenswert?

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

von M. Gerlach (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.