Headerfile verursacht endlosschleife
-
Tim schrieb:
Das Ding hat ja nichtmal einen richtigen Stack
ach ja, PIC. aber hatte der nicht irgend so'n 32-einträge grossen stack für rücksprungadressen. reicht doch...
btw: solche teile haben meist eine automatische stack under- und overflow erkennung, also, Lehon, schmeiss den debugger an.
-
Ich nutz nen debugger der mir anzeigt wo er genau is und kann mit breakpoints feststellen das er sich da befindet. Werd nachher mal den uebersetzten Assemblercode genauer anschaun, vllt find ich da was.
-
Lehon schrieb:
Ich nutz nen debugger der mir anzeigt wo er genau is und kann mit breakpoints feststellen das er sich da befindet. Werd nachher mal den uebersetzten Assemblercode genauer anschaun, vllt find ich da was.
Wenn du einen vernünftigen Debugger hast, solltest du auch herausfinden können, von wo aus diese Funktion ständig aufgerufen wird.
-
kann es sein das sich dein PIC beim befehlt TRISCbits.TRISC7 = 1; aufhängt? auc hwenn es nur ne zuweisung von nem parameter ist? Wenn ja spring das progarmm nie aus der funktion raus, und die symtome sind wie bei ner endlosscheife;)
-
Undertaker schrieb:
Tim schrieb:
Das Ding hat ja nichtmal einen richtigen Stack
ach ja, PIC. aber hatte der nicht irgend so'n 32-einträge grossen stack für rücksprungadressen. reicht doch...
Jo, ich bin mir nicht sicher ob 16 oder 32.
Undertaker schrieb:
btw: solche teile haben meist eine automatische stack under- und overflow erkennung
iirc nicht.
-
Da er garnicht in die main gelangt und die anderen includes total unabhaengig von meinem headerfile sind, gehe ich sehr stark davon aus das
#include "lcd_code.h"
die datei aufruft.trisc haengt sich nicht auf, da es funktioniert, wenn es ganz normal in main.c drinsteht und der debugger anzeigt, das er weiter springt.
hab nur zum testen die einzelnen funktionen mit funktionsaufrufen am ende der befehlsliste versehen. er fuehrt dann die einzelnen sachen auch richtig aus, aber sinn des ganzen isses trotzdem nicht. heisst aber wenigstens das der code stimmt, sonst wuerde das lcd ja muell anzeigen und nich das was ich angebe.
-
Lehon schrieb:
Da er garnicht in die main gelangt und die anderen includes total unabhaengig von meinem headerfile sind, gehe ich sehr stark davon aus das
#include "lcd_code.h"
die datei aufruft.Nochmal - Ein #include ruft überhaupt keine Funktionen auf - der Präprozessor fügt an dieser Stelle nur den Inhalt der genannten Datei in deinen Quelltext ein. Deshalb hast du vermutlich irgendwo anders in deinem Quelltext eine Endlosschleife eingebaut - und dein Debugger sollte eigentlich in der Lage sein, dir anzuzeigen, wo die ist.
(bei C++ würde ich auf eine globale Variable tippen, deren Initialisierung diese Probleme verursacht)
PS: Aber Funktionsdefinitionen direkt im Header einzubauen ist kein guter Stil - selbst wenn es durch den Compiler geht, wird der Linker sich darüber beschweren, daß er plötzlich mit mehreren Definitionen konfrontiert wird.
-
Lehon schrieb:
...gehe ich sehr stark davon aus das
#include "lcd_code.h"
die datei aufruft.du #includierst das file an einer ziemlich unüblichen stelle (innerhalb der 'main'). sollte sich in der 'lcd_code.h' irgendwas befinden, das zu aktivem code expandiert, könnte das schon abstürzen. mach' mal das #include ausserhalb der 'main'...
edit: stimmt nicht, sorry, hab' mich verguckt in deinem ursprungscode
-
Was für einen Compiler verwendest du?
Läuft auf dem PIC noch irgendein Monitor?
Dass er die main() garnicht erreicht klingt mir irgendwie nach einem falschen Startup-Code...Zum Thema Stack Over-/Underflow:
After the PC is pushed onto the stack 31 times (without
popping any values off the stack), the STKFUL bit is
set. The STKFUL bit can only be cleared in software or
by a POR.
The action that takes place when the stack becomes
full depends on the state of the STVREN (Stack Overflow
Reset Enable) configuration bit. Refer to
Section 21.0 “Comparator Module” for a description
of the device configuration bits. If STVREN is set
(default), the 31st push will push the (PC + 2) value
onto the stack, set the STKFUL bit and reset the
device. The STKFUL bit will remain set and the Stack
Pointer will be set to ‘0’.
If STVREN is cleared, the STKFUL bit will be set on the
31st push and the Stack Pointer will increment to 31.
The 32nd push will overwrite the 31st push (and so on),
while STKPTR remains at 31.
When the stack has been popped enough times to
unload the stack, the next pop will return a value of zero
to the PC and sets the STKUNF bit, while the stack
pointer remains at ‘0’. The STKUNF bit will remain set
until cleared in software or a POR occurs.(Datenblatt PIC18F4x8)
Grüße,
Martin
-
ich weiss das ein #include eigentlich keine dateien aufruft sondern diese nur einbindet, aber das ganze verhalten is ja irgendwie nich normal...
in einer funktion, in der NUR variablenzuweisungen stattfinden, is einfach keine endlosschleife. und waere mir neu das irgendwas von ausserhalb das ganze verursacht. zumal er dann wenigstens die ganze datei durchlaufen muesste und nicht nur die oberste funktion.
das mit headerdatei und funktionsbeschreibung hab ich inzwischen auch geändert, aber is das selbe problem, nur das die datei etz auf .c endet.
100%ig kann ich nicht sagen das die datei durch das include geoeffnet wird, aber es gibt nur includes vor der main funktion und daher bleibt fast nix anderes uebrig.
die anderen headerdateien sind vorgefertigte und ich hab an denen nichts geaendert, nur diese eine ist von mir. daher rufen die anderen auch nicht meine auf und aehnliche funktionsnamen werden auch nicht doppelt verwendet.der stack kann doch eigentlich nur volllaufen wenn das programm ueberhaupt startet, aber soweit kommts ja nicht wirklich. er is in ner schleife bevor er irgendwas bearbeiten kann... zudem hab ich in den konfigurationen ein bit, dass im notfall den stack resettet.
Falls es dich genauer interessiert, nutze ich ein 5,7" grafikdisplay von kyocera und einen pic18f4550. Beide geräte funktionieren, wenn alle funktionen ausschliesslich in der main zu finden sind.
-
Lehon schrieb:
ich weiss das ein #include eigentlich keine dateien aufruft sondern diese nur einbindet, aber das ganze verhalten is ja irgendwie nich normal...
Allerdings - nur aus den bisherigen Fragmenten können wir auch nicht mehr herleiten als du ohnehin schon weißt: Da ist irgendwas schief gelaufen.
in einer funktion, in der NUR variablenzuweisungen stattfinden, is einfach keine endlosschleife. und waere mir neu das irgendwas von ausserhalb das ganze verursacht. zumal er dann wenigstens die ganze datei durchlaufen muesste und nicht nur die oberste funktion.
In der Funktion ist keine Schleife - und mir ist aus nicht bekannt, daß irgendeine Funktion aufgerufen werden sollte, nur weil ihr Header eingebunden wird. Soweit die Fakten.
Aber: Irgendwer ruft diese Funktion auf - und bevor wir weitermachen, solltest du den erstmal identifizieren. (wenn das vor der main() passiert, bleiben dafür nur die Initialisierungen irgendwelcher globaler Variablen als Kandidaten übrig - hast du da welche?)
das mit headerdatei und funktionsbeschreibung hab ich inzwischen auch geändert, aber is das selbe problem, nur das die datei etz auf .c endet.
100%ig kann ich nicht sagen das die datei durch das include geoeffnet wird, aber es gibt nur includes vor der main funktion und daher bleibt fast nix anderes uebrig.Und dann hast du hoffentlich nicht die #include auf den neuen Namen umgeändert
(durch die Umbenennung änderst du nichts am Inhalt der Datei oder der Art, wie der Compiler sie verwendet).
-
obwohl ich mehrmals neue projekte erstellt habe und nur den inhalt der dateien kopiert habe kam der fehler immer wieder. jetzt hats jemand andres fuer mich gemacht und bei ihm laeufts. hab daher das ganze projekt von ihm kopiert. woran das gelegen hat weiss ich trotzdem nicht.
trotzdem danke ich jedem fuer seine/ihre hilfe