Problem mit Funktionsaufrufen

[PCMan]

Mal ne Frage: ich habe die c-files nicht in der Makefile angegeben. Kann das was ausmachen?

[fumir]

in einer header datei sollten eigentlich keine daten angelegt werden. bzw. sollte aus einer header datei eigentlich gar kein code entstehen (das ist natürlich nur ne richtlinie)

wenn das einbinden der headerdatei etwas mit dem fehler zu tun haben könnte, dann solltest du diese datei posten ich glaube um den fehler zu finden, müßte man wirklich alle dateien, incl. der verwendeten bibliotheken haben. dazu die hardware. kurz: man müßte das programm selbst übersetzen und debuggen können, um dir weiter zu helfen.
vielleicht findest du jemanden, der sich auskennt, und mal zu dir nach hause kommt.

solange du den fehler nicht gefunden hast, machts wenig sinn alles neu zu schreiben, denn womöglich hast du den fehler dann immer noch drin.

wenn ne datei nicht im makefile angegeben ist, dann wird sie wohl schlimmstenfalls nicht compiliert oder gelinkt. aber da make so was wie ne eigene programiersprache ist, kommts eben drauf an, was genau im makefile drinsteht, wo deine dateien abgelegt sind, etc. etc.

[PCMan]

Hmm, also ich könnte die Menüheader posten. Aber ich sage gleich: die sieht extrem s chei sse aus, erstmal ewig lang und viel zu kompliziert. Ich kann sie einbinden und sie funktioniert auch. Nur, was mich eben so verrückt macht: die header ist zwar eingebunden, aber ich habe die funktionen darin noch überhaupt nicht aufgerufen und mein Programm stürzt ab.

Hier dennoch die header im Anhang.

Für alle ineteressierten: das ganze handelt sich um ein Projekt für die Naturwissenschaftliche Informatik an der Uni.

vG Simon

[PCMan]

hm mal so ne ganz doofe Frage: kann es sein, dass mein Programm irgendwo zuviel Speicher in Anspruch nimmt? Z.B. dass der RAM überfüllt wird. Könnte die ganzen Strings aus dem Menue in's Flash-Rom packen, ist eh Unsinn, dass die im Ram rumgeistern...
Hat jemand eine Idee?
Vielen Dank,
Simon

Edit:
Aus Mikrocontroller.net:

malloc() legt Speicherblöcke im Heap an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel Heap-Fragmentierung).

Kann es sein, dass ich mit meinen ganzen Bitfeldern ungünstige Speicheradressen belege?

[PCMan]

Noch ein kleiner Nachtrag: folgende Eingabe in der Konsole ergab etwas, dass mich überrascht hat:

>avr-size -C --mcu=atmega32 main.elf

AVR Memory Usage
----------------
Device: atmega32

Program: 20242 bytes (61.8% Full)
(.text + .data + .bootloader)

Data: 2125 bytes (103.8% Full)
(.data + .bss + .noinit)

Ich sehe, dass hier etwas zu voll ist. Jetzt bräuchte ich jemand, der mir erklärt WAS da zu viel Platz belegt. Oder wenn ihr einen Link kennt, der das alles beschribt, als her mit.
vG Simon

[fumir]

zu viel zeug im RAM würde schon einiges erklären
kann nicht schaden den bedarf an RAM zu überdenken und gegebenenfalls zu reduzieren, bevor du weiter nach anderen fehlern suchst.


also so was wie dein menü gehört wirklich nicht in ne headerdatei.
änder das mal schnell in menue.c bevor noch jemand lacht

wenn du es nicht immer drin haben willst, dann mach das z.b. mit bedingter compilierung (#ifdef MENUE ... #endif oder so)

ein header enthält üblicherweise forward declarations, wird in mehrere quelltextdateien eingebunden und sollte deshalb nichts enthalten, was code oder daten erzeugt.

[fumir]

die strings der menüs sind doch konstanten und sollten daher ohnehin im FLASH landen. ins ram kämen die nur, wenn du sie in ne variable speichern würdest.

malloc oder sowas hab ich bis jetzt noch nirgens in deinem code gesehen.

im wissenbereich gibts wohl ne nette übersicht zu speicher bei avr-gcc.
die hast du dir doch angeschaut, oder?

[McJenso]

Hallo,

versuch doch mal das Programm soweit zu kastrieren, dass der Code möglichst klein wird, das Programm noch irgendwie lauffähig ist und der Fehler noch auftritt. Ob das Programm dann noch etwas Sinnvolles macht, ist dabei egal. Das hilft beim Fehlersuchen. Dann stell den GANZEN übriggebliebenen Code AM STÜCK hier rein, event. als Anhabng. Ich glaube nicht, das jemand die ganzen Schnipsel zu einem Programm zusammenfügt. Aber dann könnte man deinen Fehler vielleicht nachvollziehen.
Gruß
Jens

[PCMan]

Hallo Leute, entschuldigt die späte Antwort.
Zunächst: bitte nicht lachen. Andere sind auch nicht mit C als Muttersprache aufgewachsen. Im übrigem würde ich gerne verstehen, wieso Funktionsrümpfe NICHT in eine Headerdatei gehören, sondern in C-Files? Wenn ich die utils/delay.h aufmache, sehe ich auch Funtkionen und nicht nur Forwrds. Woher kommt diese Konvention? Was für einen Vorteil hat sie?
Dass das definitiv ein Speicherproblem sein muss ist für mich die einzige logische Erklärung. Ich habe heute auch im AVR-GCC-Tutorial von PROGMEM gelesen. leider war ich im Tutorial garnicht soweit fortgeschritten, daher war ich so "deppert" und habe einfach alle Strings belassen wie sie sind.
Weswegen ich nicht *alles* online stelle: naja es gibt headers, die zB für das IO des I2C-EEPROMs nötig sind. Und da ich dachte, die tun nix zur Sache, habe ich es einfach gelassen. Abgesehen davon sieht der Code ziemlich unschön aus und ist schlecht kommentiert. Ein Grund, weswegen er jetzt nochmal überarbeitet wird.
Ich danke euch jedenfalls vielmals für's mitdenken, bei schier unlösbaren Problemen melde ich mich wieder wie gewohnt
vG Simon

P.S.: Wenn die Speicheroptimierung vorrüber ist poste ich nochmal ob's geklappt hat.

[fumir]

wie du schon sagst ist es nur ne konvention. prinzipiell kannst du die dateien natürlich benennen und auch reinschreiben was du willst (genauso wie man das komplette c-programm auch in ne einzelne zeile schreiben kann, oder das ganze programm mit präprozessordirektiven formulieren kann), solange es dann richtig übersetzt wird.
genaugenommen ist in der sprachdefinition von c/c++ nicht mal festgelegt, das der quelltext als text in einer datei stehen muss (mit nem entsprechenden editor/system könnte das programm z.b. direkt in einer baumstruktur gespeichert werden)

von einer headerdatei (*.h) nimmt man üblicherweise an, dass sie dinge enthält, die keinen code und daten erzeugen, und das man sie deshalb in mehrerer dateien oder auch mehrfach einbinden kann, ohne das es probleme gibt.

wenn du nun also trotzdem code und daten reinschreibst, und ein anderer verwendet die datei (oder schaut sich dein programm an) dann wird er eben wahrscheinlich unzutreffende annahmen über deine datei machen, was zu problemen führen kann.

es gibt wohl ne menge verschiedene gründe für diese konvention und vermutlich kenne ich nicht mal die hälfte davon.

in c++ ists üblich template-code in die *.h zu schreiben. teilweise muss man es sogar machen. aber templates sind auch etwas anderes als normaler c/c++ sourcecode.
bei templates wird erst code erzeugt, wenn das template verwendet wird.
wenn du jedoch ne normale funktion in ne header schreibst und diese dann mehrfach einbindest, dann wird mehrfach code für diese funktion erzeugt. normalerweise will man das nicht.

du kannst die datei doch auch einfach in *.c umbenennen und mit include einbinden. dann hast du praktisch nichts geändert, aber jeder der sich das anschaut, weiß sofort, das in der datei code und daten erzeugt werden.

ansonsten bestätigen ausnahmen die regel