Riesen datensegment

...sind eventuell einige von den lokalen Variablen als static 
deklariert? ;-)

Strings?

Danke, in einer routine wird mit 2 Floats gerechnet.
Auskommentiert-> 400 byte weniger ram.
Das ist einfach nur krank ich zieh mir jetzt wieder nen gcc 3.x und hoff 
das mein geliebter fpc bald n target für den avr hat dann bin ich den 
müll mit gcc und der gnu toolchain los -.-

Ist natürlich einfacher, auf andere zu hoffen, als sich an die
Analyse eines Problems zu machen...

Falls du die 256 Bytes für irgendeine konstante Tabelle meinst, das
ist ein bekannter Bug, der mittlerweile schon repariert ist und nur
drauf wartet, dass WinAVR ein neues Release rausbringt.

Kostenlose Software benutzen und trotzdem noch meckern... ;)

Im oben verlinkenten Beitrag steht auch ein einfacher Workaround dazu.
Einfach das Codeschnipsel in den Source aufnehmen, und "gut iss".

Frank

>Ist natürlich einfacher, auf andere zu hoffen, als sich an die
>Analyse eines Problems zu machen...

hast du meine Beiträge nicht gelesen oder ignoriert ? Das Problem ist 
doch bekannt ...

>Kostenlose Software benutzen und trotzdem noch meckern... ;)

Darf man nicht allzu ernst nehmen ich erwarte nur immer recht viel vom 
gcc da alle Welt ihn nutzt und solche Probleme erwartet man dann einfach 
nicht. Bin das einfach vom fpc nicht gewohnt und wenn dann sowas im gcc 
auftaucht der zig mal verbreiteter ist enttäuscht mich das.

Christian Ulrich wrote:

> hast du meine Beiträge nicht gelesen oder ignoriert ?

Ich finde in deinen Beiträgen nicht einmal ansatzweise den Versuch
einer Analyse, was genau denn passiert wäre.  Ohne diese Analyse
kann man aber auch keine Hilfe leisten.  Wie schon geschrieben, die
Ursache von 256 Bytes in __clz_tab[] sind bekannt (und der Fehler
mittlerweile beseitigt), für den Rest müsstest du schon selbst mit
helfen.

Einfach nur meckern kann jeder.  Was ist, wenn dich den fpc (was
auch immer das sein mag, ist mir noch nicht übern Weg gelaufen) beim
nächsten Versuch mit was anderem enttäuscht?  Schnell weg, das
nächste gesucht, neue Probleme?

Naja, daran würde ich es nicht festmachen.  Pascal hat in Form von
Turbopascal die Programmierung unter CP/M durchaus revolutioniert.

Real Programmers can write FORTRAN programs in any language. ;-)

@Terminator
Schau dir erstmal an über was du da urteilst.
Pascal is ne sehr schöne und vor allem lesbare Sprache.
Aber das ist nicht Thema des Threads und ich weiss dont feed the Trolls.

Christian Ulrich wrote:

> Pascal is ne sehr schöne und vor allem lesbare Sprache.

Ich kann's nur wiederholen:

Real Programmers can write FORTRAN programs in any language.

Es ist nicht die Programmiersprache selbst, die "lesbar" ist oder
nicht, sondern das, was der Programmierer draus macht.  Man kann
unleserliche Pascal-Programme genauso verfassen wie gut lesbare
C-Programme.

> Aber das ist nicht Thema des Threads ...

Zu dem du dich allerdings offenbar nicht mehr äußern willst.  Anders
kann ich es jedenfalls nicht deuten, dass du nach wie vor nichts hier
zeigst, was man als Ursachenanalyse benutzen könnte, um dir ggf. die
notwendige Hilfe zuteil werden zu lassen.

Sorry, für mich ist das Problem erstmal erledigt gewesen es war 
anscheinend die Tabelle im Ram, die das Datensegment aufgebläht hat.

Jedoch hab ich immernoch keine Erklärung dafür wiso mein Datensegment 
überhaupt so groß ist. Ich hab max. 1K globale Variablen warscheinlich 
weit weniger. und die 4K vom Atmega64 sind zu 98% voll. Der Code ist 
recht stark gekapselt was sich jedoch nur auf den Stack auswirken sollte 
meines erachten nach.
Hat dazu jemand eine Idee ?

Und @Jörg du hast schon recht das es auch auf den Programmierer ankommt 
aber man kann z.b. in Visual Basic einfach keine lesbaren Programme 
schreiben in C ists sehr schwer. In Pascal ists nahezu unmöglich 
unleserlich zu schreiben. Tut trotsdem nichts zur Sache.

Christian Ulrich wrote:

> Ich hab max. 1K globale Variablen warscheinlich
> weit weniger. und die 4K vom Atmega64 sind zu 98% voll.

Warum mutmaßt du immer noch, statt nachzugucken?  Für sowas gibt's
Symboltabellen, die man sich ansehen kann -- aber die hast du,
nicht wir.

Wo hab ich denn bitte jemanden niedergemacht ?
Die Farge die noch übrig ist, war lediglich warum gcc lokale Variablen 
ins Datensegment wirft statt auf den Stack. Das ist nicht 
projektspezifisch.
Was hab ich nicht beschrieben ?
ich werde lediglich grantig wenn 50 Gäste sie zu feige sind sich am 
forum anzumelden die Threads mit Sachen zumüllen die überhaupt nichts 
mit der Fragestellung zu tun haben bzw die Fragesteller beleidigen. Das 
ist hier eine absolute Unart.
Wenn dazu niemand eine Idee hat ists doch ok. Es war lediglich eine 
Frage. Es fehlen auch keine Informationen wenn doch kann man die 
anfragen. Falls ich mich undeutlich ausgedrückt haben sollte tut mir das 
leid.

Ich hatte Jörgs Beitrag (3.) total übersehn ...

>Strings?

Genau so. Absoulut logisch das die im Datensegment landen und aus dem 
map file schlecht zu ersehn gewesen :|. Danke.

Christian Ulrich wrote:

>>Strings?
>
> Genau so. Absoulut logisch das die im Datensegment landen

Eine Folge der Harvard-Architektur in Verbindung mit dem C-Standard.
Der möchte ja, dass deine Strings aufrufkompatibel zu Standardfunktionen
wie strcmp() etc. sind.  Damit kann der Compiler sie nur im RAM
ablegen, denn nur dort sind sie mit beliebigen anderen const char *
Objekten austauschbar.

Tutorials für Strings (und andere Daten) im Flash-ROM sollte es
ausreichend geben.

Ja, habs schon geändert ich hab einfach nicht dran gedacht.
Wieder mal son Fall von Wald vor lauter Bäumen nicht gesehn.