Compilerfehler Programm springt aus der Initialisierung zum Start zurück

das die Returnadresse am Stack überschrieben wird habe ich mir auch 
schon gedacht, das seltsame ist ja nur, dass der veraenderte code nichts 
mit der initialisierung zu tun hat.

der watchdog in der main-Routine vor dem Aufruf der USB initialisierung 
deaktiviert.

ich habe dafür eigentlich keine isr geschrieben, aber im lufa stack 
könnte da etwas enthalten sein. wie kann ich den tatsaechlichen fehler 
denn finden?

Außerdem werden die Interrupts erst nach der Initialiserung der Hardware 
mit

1

sei();

 aktiviert.

82,3% des SRAM sind verbraucht.

Wie groß ist denn der Stack der die Rückkehradressen speichert? Ich 
liege doch richtig, dass das ein FILA Speicher ist? Also wie ein Stapel 
Teller. Ein Stack halt. Dabei würde die 9 Rückkehradresse bei 8 
Speicherplaetzen verworfen werden.

Seltsamerweise kehrt das Programm bis zur ersten Aufgerufenen Subroutine 
zurück. Dann faengt der µC von vorne an anstatt zur letzten 
Absprungadresse zu gehen.

Mir ist gerade die Idee gekommen im Hauptprogramm ein Label MAIN 
einzufügen und dann aus der Subroutine am Ende der Subroutine ein goto 
MAIN einzufügen, aber das wird vom Compiler wegopimiert.

> 82,3% des SRAM sind verbraucht.

Mach RAM frei. Und wenns nur vorübergehend zur Fehlerbestätigung ist.

in wie fern soll das den Fehler beheben?

ich hab keine ahnung warum, aber jetzt springt das programm richtig.

kanns sein, dass der compiler durch die optimierung durcheinanderkommt 
wo der die variablen ablegt?

> in wie fern soll das den Fehler beheben?

Du hast (bzw. hattest) höchstwahrscheinlich (jetzt praktisch bestätigt) 
einen Pufferüberlauf, im Speziellen eine Begegnung der dritten Art von 
Heap und Stack. Dadurch wird (wurde) vermutlich der "letzte" Stackframe 
beschädigt mit dem Ergebnis dass das return ins Nirvana springt.

80% belegter RAM sind definitiv zu viel, da hieße es höllisch aufpassen, 
was vor sich geht - und jedes Byte einzeln zählen. Deswegen vermeidet 
man das einfach B-)

Ergo: Schaufel mehr RAM frei, sonst gibts bald wieder einen Zusammenstoß 
- und der ist dann möglicherweise nicht so einfach zu finden.

A. K. schrieb:
> Sorry, aber 99% aller postulierten Compilerfehler sitzen vor dem
> Bildschirm. Ja, es gibt sie und hier im Forum wurden auch schon welche
> gefunden. Aber ohne konkrete Anhaltspunkte den Compiler beschuldigen
> weil man selber nicht durchblickt, das ist nicht angebracht.

Tut mir leid, aber als C Programmierer der neu auf AVR ist darf ich wohl 
einen Fehler im Compiler annehmen. Da ist einem nicht von Anfang an klar 
das bei 80 % RAM Auslastung Fehler auftreten können.

Jedenfalls würde ich gerne wissen, wie ich den verfügbaren RAM ganz 
nutzen kann, bzw. mehr davon?

Bernhart schrieb:

> Tut mir leid, aber als C Programmierer der neu auf AVR ist darf ich wohl
> einen Fehler im Compiler annehmen.

Gerade dann ist es besonders unwahrscheinlich, daß der Fehler beim 
Compiler zu suchen ist.

> Da ist einem nicht von Anfang an klar das bei 80 % RAM Auslastung Fehler
> auftreten können.
>
> Jedenfalls würde ich gerne wissen, wie ich den verfügbaren RAM ganz
> nutzen kann, bzw. mehr davon?

Du hast offensichtlich das Problem noch gar nicht verstanden.
Dein Programm verhält sich so komisch, weil du bereits mehr nutzt, als 
eigentlich vorhanden ist.

Bernhart schrieb:
> 82,3% des SRAM sind verbraucht.
>
> Wie groß ist denn der Stack der die Rückkehradressen speichert?

So groß wie nötig. Der Stack fängt defaultmäßig am Ende des RAM an und 
wächst dann nach unten, zur Not auch in den schon durch Variablen 
belegten Teil des RAM. Der speichert übrigens nicht nur 
Rücksprungadressen.

> Ich liege doch richtig, dass das ein FILA Speicher ist? Also wie ein
> Stapel Teller. Ein Stack halt.

Ähm, ja, der Stack ist ein Stack ;-)
"FILA" kenne ich aber nur als Turnschuh-Marke. Den Stack kenne ich als 
"LIFO" ("Last In, First Out).

> Dabei würde die 9 Rückkehradresse bei 8 Speicherplaetzen verworfen
> werden.

Es wird nichts verworfen. Bei einem Funktionsaufruf wird die 
Rücksprungadresse gespeichert, PUNKT.
Genauer: Die Adresse der nächsten Instruktion wird der Stelle im RAM 
gespeichert, auf die der Stackpointer zeigt. Dann wird der Stackpointer 
dekrementiert.

nein, ich verwende keinen einzigen String. ca 30 % des RAMs belegt der 
LUFA USB Stack. Die 5 % sind für einen 8 Bit 16 Kanal LED Dimmer und die 
restlichen 48 % waeren für automatisches Faden der LEDs in beliebiger 
Geschwindigkeit unabhaengig von einander. Aber das bedarf sowiso noch 
einiger Optimierungsarbeit. Der Fehler ist aufgetreten, als ich die 
Funktion von 1 LED auf alle 16 umgeschrieben habe. Diese LED Show 
befindet sich noch im Entwicklungsstadium und ist erst zu 70% fertig.

Als Controller verwende ich den AT90USB162 mit 512 Byte RAM.

Wie groß ist denn in der Regel der Stack? in welchem Speicherbereich des 
RAMs befindet der sich für gewöhnlich?

Bernhart schrieb:
> Wie groß ist denn in der Regel der Stack? in welchem Speicherbereich des
> RAMs befindet der sich für gewöhnlich?

Die Mühe, dir das zu erklären, habe ich mir nicht gemacht, damit du es 
nicht liest.

haben Atmel 8 bitr µCs nicht eine Stack irgenwo auf der Hardware wie 
manche PICs?

Ja, die AVRs, die kein RAM haben, also der ATtiny11.
Alle anderen AVRs haben den Stack im RAM.

Hc Zimmerer schrieb:
> Annehmen darfst Du alles; ausgeschlossen ist es ja nicht.
> Veröffentlichen wird es nur ein C-Programmierer, der eher nicht nur bei
> AVRs Anfänger ist.  Das Netz ist voll von Compilerfehlern, bei denen die
> Fehlerursache zwischen Tastatur und Rückenlehne zu finden war (zu ca.
> 99,9%).  Nach einiger Zeit lokalisiert man die Fehlerquelle von selbst
> dort und sieht das als normalen Teil des Debugging.

Am Anfang habe ich auch einen Fehlervon mir vermutet, aber als ich den 
Assamblercode gesehen habe, habe ich gewusst, dass der Fehler nicht 
direkt dem Codestück kommt, bei dem er Auftritt. Bei der Programmierung 
auf Betriebssystem Basis muss man sich über so etwas ja eher wenig 
gedanken machen.

Aber dass 20 % des RAMs für den Stack und den HEAP drauf gehen finde ich 
schon eher viel. Das Meiste wird vermutlich eh der Heap verbrauchen.

> Aber dass 20 % des RAMs für den Stack und den HEAP drauf gehen finde ich
> schon eher viel.

Das sind ca. 100 Bytes.

> Das Meiste wird vermutlich eh der Heap verbrauchen.

Kannst du auf dynamischen Speicher nicht verzichten?

@ Rolf Magnus:
Danke für die Info, das 20% von 512 ca. 100 ist haette ich mir nicht 
denken können.

Ich brauche für meinen Code gar keinen dynamischen Speicher. Ich 
vermute, dass der LUFA USB Stack aber etwas brauchen könnte.

juchu, was täten wir nur ohne die ganzen Anfänger, die die vielen Bugs 
in den Compilern finden!?! Nicht auszudenken, wenn die alle unentdeckt 
blieben, weil nur Profis den Compiler benutzten...

delicious_cake schrieb:
> Danke für die Info, das 20% von 512 ca. 100 ist haette ich mir nicht
> denken können.

Wenn man aus der PC-Ecke kommt, wo der Speicher typischerweise mehrere 
Millionen Mal so groß ist, denkt man evtl. in anderen Dimensionen. Ich 
wollte nur sicher sein, daß dir bewußt ist, wie viel diese 20% 
eigentlich sind.

> Ich brauche für meinen Code gar keinen dynamischen Speicher. Ich
> vermute, dass der LUFA USB Stack aber etwas brauchen könnte.

Das sollte sich ja einfach rausfinden lassen. Für den Stack alleine 
wären 20% schon sehr viel, außer wenn du sehr tiefe Aufrufhierarchien 
oder viele lokale Variablen hast. Ungünstig implementierte ISRs können 
auch viel Stack brauchen.

Hc Zimmerer schrieb:
> Wie groß ist denn Dein data-Bereich?

der Databereich hat 43% Auslastung. Es sollen aber noch einige 
funktionen dazu kommen. Kanns durch eine hohe Auslastung des Data 
Bereichs auch zu Problemen kommen?

Hc Zimmerer schrieb:
> An den TE:  Hast Du denn initialisierte Variable, die sich nie ändern
> (Beispiel wäre ein Array aus konstanten Werten)?  43% Data ist nicht
> wenig, frisst viel SRam und legt den Verdacht nahe, dass es sich um
> solche Konstanten handelt.
>
> Falls ja, freunde Dich mal mit <avr/pgmspace.h> an.


alle Konstanten sind bei mir von Anfang an als defines implementiert. 
Und der PWM Table zum LED Faden efindet sich ebenfalls von Anfang an im 
Flash memory.

Wie ich die Größe des Data-Bereichs verringern kann, habe ich mir noch 
nicht überlegt. Aber mir ist eingefallen, dass für jede einzelne Bool 
Variable ein ganzes Byte verbraucht wird. Wenn ich die Bool Variablen zu 
wirklichen Bools umschreibe die nur mehr true und false sein können, 
spare ich bestimmt an die 100 Byte Sram ein.

Wie ich das umsetzen kann weiß ich bereits. Dann habe ich aber immer nur 
8 Variablen pro Byte. Hat jemand vielleicht schon einen Vorschlag wie 
ich das Umsetzen kann, dass eine beliebige Anzahl an Bools in einer 
Variable steht die wie ein Array ansprechbar ist. Ich arbeite mit sehr 
vielen solcher Arrays und die beliebige Definition der Größe waere sehr 
angenehm. Ich habe an eine unitxx_t Variable gedacht, bei der man die 
Größe selbst festlegen kann. Halt leider nur bis 64. Ich haette es aber 
gerne bis 256.

PS: diese Bool implementierung sollte natürlich auch möglichst schnell 
arbeiten.

@ Karl heinz Buchegger:

Danke. Das Beispiel ist nicht schlecht gewaehlt.

delicious_cake schrieb:
> Aber mir ist eingefallen, dass für jede einzelne Bool
> Variable ein ganzes Byte verbraucht wird. Wenn ich die Bool Variablen zu
> wirklichen Bools umschreibe die nur mehr true und false sein können,
> spare ich bestimmt an die 100 Byte Sram ein.

Hast du wirklich über 100 bool-Variablen in deinem Programm, die 
gleichzeitig im Ram existieren müssen?

delicious_cake schrieb:
> alle Konstanten sind bei mir von Anfang an als defines implementiert.
> Und der PWM Table zum LED Faden efindet sich ebenfalls von Anfang an im
> Flash memory.

Kannst du mal zeigen, wie deine defines sicherstellen, daß da keine 
Konstanten im Ram liegen, und den Codeteil mit der PWM-Tabelle im Flash?

Oliver

Oliver schrieb:
> Hast du wirklich über 100 bool-Variablen in deinem Programm, die
> gleichzeitig im Ram existieren müssen?

wo sollen die bools denn sonst liegen? eine aendert den zustand z.B. mit 
31,25 Hz. wenn ich die im eeprom ablege oder im flash dann bin ich 
ziehmlich schnell bei 100.000 (eeprom) bzw. 10.000 (flash) schreibzyklen 
angekommen. und dann geht nix mehr auf der adresse. die anderen andern 
sich höchsten jede sekunde einmal.

Oliver schrieb:
> Kannst du mal zeigen, wie deine defines sicherstellen, daß da keine
> Konstanten im Ram liegen, und den Codeteil mit der PWM-Tabelle im Flash?

1

//selbsterstellter PWM Tabelle

2

uint8_t pwm_time[256]   PROGMEM =

3

4

{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,

5

1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,

6

2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,

7

3,3,4,4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,

8

5,5,5,5,6,6,6,6,6,6,6,6,7,7,7,7,7,7,8,

9

8,8,8,8,8,9,9,9,9,9,10,10,10,10,10,11,

10

11,11,11,12,12,12,12,13,13,13,14,14,14,

11

14,15,15,15,16,16,17,17,17,18,18,18,19,

12

19,20,20,21,21,21,22,22,23,23,24,24,25,

13

26,26,27,27,28,28,29,30,30,31,32,32,33,

14

34,35,35,36,37,38,39,39,40,41,42,43,44,

15

45,46,47,48,49,50,51,52,53,55,56,57,58,

16

60,61,62,64,65,66,68,69,71,72,74,76,77,

17

79,81,83,84,86,88,90,92,94,96,98,100,103,

18

105,107,109,112,114,117,119,122,125,127,

19

130,133,136,139,142,145,148,152,155,158,

20

162,165,169,173,177,180,184,189,193,197,

21

201,206,210,215,219,224,229,234,239,245,250,255};

22

23

#define EE_LED_VALUE_ADDR      100 // eeprom byte address where the brightness-settings will be saved

24

#define EE_FADE_TIME           100+PWM_CHANNELS // eeprom byte address where the settings will be saved

delicious_cake schrieb:
> Oliver schrieb:
>> Hast du wirklich über 100 bool-Variablen in deinem Programm, die
>> gleichzeitig im Ram existieren müssen?
>
> wo sollen die bools denn sonst liegen?

Lol.. die Antwort klingt etwa wie:

"Hast du wirklich einen Elefanten in deiner Garage?"
"Ja natürlich. Wo soll ich den denn sonst lassen?"

Karl heinz Buchegger schrieb:
> 42% von 512 Bytes sind immerhin 220 Bytes. Und das für 16 popelige LED?

ich weiß nicht wie oft ich schon gesagt habe, dass noch nicht fertig 
bin. erst kommen alle funktionen rein, dann wird optimiert. und wenn 
zwischen drin ein Fehler auftauch wird der gleich behoben. Nur mit dem 
RAM Problem habe ich nicht so schnell gerechnet. Jetzt muss ich halt 
schon vorher etwas aufraeumen.

@ Karl heinz Buchegger:

das ist mir alles klar. deshalb bringe ich jetzt ja alles in ordnung 
bevor ich mich an weiter sachen wage. Dass mir der Speicher ausgehen 
könnte, wenn die fading funktion so wie sie ist/war fertig ist, dessen 
war ich mir bewusst. Aber von 80% RAM "Grenze" konnte ich doch nichts 
ahnen, wenn man mit so etwas noch nie zu tun hatte. immoment ist das 
faden so aufgebaut, dass sie für bis zu 64 LEDs verwendet werden kann. 
mein µC hat halt nur nicht so viele IOs und ich verwende sie für 16. So 
sehe ich einerseits was ich verbessern muss und andererseits lerne ich 
probleme zu beheben.