mikrocontroller.net

Forum: Compiler & IDEs compilerangaben?


Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon x-mal geschrieben.

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

Denk an den Stack, der braucht auch RAM.

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jörg,

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

danke
m.g.

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jörg,

hier also das zweite main.

danke

m.g.

Autor: M. Gerlach (Gast)
Datum:

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

falls interesse besteht versuch ichs nochmal.

m.g.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: M. Gerlach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@jörg

mit dem main-file läufts.

Autor: M. Gerlach (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@jörg

mit dem main-file läufts nicht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: M. Gerlach (Gast)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zuerst mal solltest du rausfinden, welcher von den ganzen Headern das
Problem verursacht.

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

#include<io.h>

typedef unsigned char  u8;
typedef unsigned short u16;

#define FREE_MARK 0x77

extern u8 __bss_end;                    // lowest stack address

extern u8 __stack;                      // highest stack address


u16 stack_size( void )                  // available stack
{
  return (u16)&__stack - (u16)&__bss_end + 1;
}


u16 stack_free( void )                  // unused stack after last
call
{
  u8 flag = 1;
  u16 i, free = 0;
  u8 * mp = &__bss_end;

  for( i = SP - (u16)&__bss_end + 1; i; i--){
    if( *mp != FREE_MARK )
      flag = 0;
    free += flag;
    *mp++ = FREE_MARK;
  }
  return free;
}


Peter

Autor: M. Gerlach (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.