compilerangaben?

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

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

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

@jörg,

hier also das zweite main.

danke

m.g.

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

falls interesse besteht versuch ichs nochmal.

m.g.

@jörg

mit dem main-file läufts.

@jörg

mit dem main-file läufts nicht.

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

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.

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.