mikrocontroller.net

Forum: Compiler & IDEs Speicherproblem


Autor: Arthur Dent (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo in die Runde,
ich habe ein Problem mit meinem Speicher und komme einfach nicht drauf 
wo der Fehler liegen könnte...

Ich habe ein Programm geschrieben dem man über die serielle 
Schnittstelle befehle geben kann.
Bis hierhin läuft alles prima!!! Jetzt ist das Programm gewachsen und 
ich habe ein paar konstante Texte eingebaut (=>FLASH).
Ab dann ist mein Programm immer mal wieder abgestürzt...

Daraufhin habe ich das Programm mal runtergekocht und festgestellt, dass 
ich mit der Größe meines Empfangsbuffers (RAM) den Absturz provozieren 
kann.

Ich komme übrigens über keine Speichergrenzen:

AVR Memory Usage:
-----------------
Device: atmega128

Program:    6734 bytes (5.1% Full)
(.text + .data + .bootloader)

Data:       3203 bytes (78.2% Full)
(.data + .bss + .noinit)

Wenn man in terminal.c RX_BUFFER_SIZE0 auf 20 setzt und befehl1 schickt 
klappt alles!!!


Ich weiß mir jetzt ehrlich keinen Rat mehr. Vielleicht kann mir ja 
jemand helfen...

Ach so Ich habe einen AT-Mega128 und nutze  die WINAVR-IDE 20060421

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich komme übrigens über keine Speichergrenzen:
>
> AVR Memory Usage:
> -----------------
> Device: atmega128
>
> Program:    6734 bytes (5.1% Full)
> (.text + .data + .bootloader)
>
> Data:       3203 bytes (78.2% Full)
> (.data + .bss + .noinit)

Das heist noch nicht viel.
Denn zur Laufzeit kommt im Data-Bereich noch einiges dazu.
Irgendwo müssen ja auch die in Funktionen lokal definierten
Variablen erzeugt werden, bzw. irgendwo muss ja auch die
Rücksprungadresse aus Funktionen heraus gespeichert werden.

All das kommt zur Laufzeit noch im Data-Bereich dazu.
Und wenn dieser Speicher nicht reicht .... dann überschreiben
sich die Dinge gegenseitig.

Ich hab mir dein Projekt nicht angeschaut, weiss also nicht
ob du tatsächlich einen Stack Overflow hast oder nicht.
Deine Symptome klingen aber danach.

Also: Im Data Bereich noch mehr Speicher einsparen!

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die "commands[]" Variable benötigt reichlich Stack.
Wirklich 1800 Bytes UART Puffer nötig?
"const" Variablen landen bei WinAVR nicht im ROM.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Generell: Beim PC mag es sinnvoll sein, grosse Datenmengen in den Stack 
zu legen. Bei Controllern ist davon eher abzuraten. Schon weil man nicht 
merkt, wieviel Speicher ein Programm so benötigt - wie eben hier.

Autor: Arthur Dent (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JA!!!!!!!!!!!!!!!!!!!!!!!!

Das scheint es gewesen zu sein
Ich bin eigentlich davon ausgegangen das ein const dafür sorgt das diese 
„variable“ ins ROM/Flash geschrieben wird, aber scheinbar mitnichten…

Mein Programm scheint jetzt soweit wieder zu funktionieren, nachdem ich 
mir im tutorial den Artikel über das Flash angeschaut habe.

An dieser Stelle erst einmal ein großes Danke für die Hilfe. Wäre ich 
alleine nie drauf gekommen. Und nun hoffe ich mal das ich mich nicht zu 
früh gefreut habe ;-)

An dich noch mal A.K.: klar war die Konstante und der UART Buffer riesig 
aber sonst trat der Fehler ja nicht auf, ich wusste eben nicht wo der 
Fehler ist und ein Beispielprogramm ist ja immer besser zu analysieren…

Ach ja, warum nutzt eine Variable eigentlich den Stack??? Ich dachte der 
wäre nur für Funktionsaufrufe bzw. Rücksprünge da…

Danke noch mal und Gruß in die Runde

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich dachte der wäre nur für Funktionsaufrufe bzw. Rücksprünge da…"

Normalerweise liegen da auch alle "auto" Variablen, also alle lokalen 
Variablen ohne anderweitige Kennzeichnung wie "static" und die 
Parameter, sofern sie nicht in Registern landen. Soweit die 
Prozessorarchitektur das hergibt.

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

Bewertung
0 lesenswert
nicht lesenswert
> Ich bin eigentlich davon ausgegangen das ein const dafür sorgt das
> diese variable ins ROM/Flash geschrieben wird, aber scheinbar
> mitnichten

Geht beim AVR nicht (nicht ohne weiteres), weil er auf Grund seiner
Harvard-Architektur besondere Befehle braucht, um aus dem ROM statt
dem ROM zu lesen.

Autor: fieser, klugscheissender Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>um aus dem ROM statt dem ROM zu lesen.
hmmm...
Eins davon soll wohl RAM heissen... ;-)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
>> Ich bin eigentlich davon ausgegangen das ein const dafür sorgt das
>> diese variable ins ROM/Flash geschrieben wird, aber scheinbar
>> mitnichten
>
> Geht beim AVR nicht (nicht ohne weiteres), weil er auf Grund seiner
> Harvard-Architektur besondere Befehle braucht, um aus dem ROM statt
> dem ROM zu lesen.


Geht eigentlich schon, nur ist der Compiler nicht ausreichend darauf 
spezialisiert anstelle von ld eben lpm zu verwenden (Warum eigentlich ? 
Bei anderen IOs geht es ja auch, da bei einigen AVRs einige IOs über 
lds/sts anstelle von in/out angesprochen werden müssen. Könnte man dem 
Compiler nicht einfach mitteilen, dass const Variablen in einer anderen 
Section liegen und die eben mit lpm angesprochen wird ?)

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

Bewertung
0 lesenswert
nicht lesenswert
Nein, es geht nicht ohne weiteres.  Zumindest nicht, ohne dass man die
Zeiger selbst von 16 auf 24 bits aufbläht, um das Speicherattribut
zusätzlich unterzubringen (wobei GCC sowieso keine 24-bit-Zeiger
kann).

> Könnte man dem
> Compiler nicht einfach mitteilen, dass const Variablen in einer anderen
> Section liegen und die eben mit lpm angesprochen wird ?)

Wie machst du das, wenn du einen Zeiger auf die Variablen an eine
Funktion gegeben hast?

Der Automatismus könnte also bestenfalls halbherzig sein wie z. B.
beim IAR.  Automatismus, solange die Variable im gleichen Scope
liegt, besondere Funktionen nötig, wenn du es an Funktionen 
weiterreichst.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Automatismus, solange die Variable im gleichen Scope
> liegt, besondere Funktionen nötig, wenn du es an Funktionen
> weiterreichst.

Und das wiederrum wäre eine denkbar schlechte Lösung.
Identischer Code funktioniert einmal und in einer
Funktion wieder nicht. Ich hör schon die Newbies schreien :-)

Autor: Arthur Dent (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, es gehört sich ja wohl auch noch mal 'nen Tip zu geben wie man 
sein Problem gelöst hat.

Deswegen, falls jemand ein gleiches Problem hat, such doch mal nach 
printf_P hier im Forum...

Gruß und nochmal danke

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.