|
Anzeige
|
For-Schleife funktioniert nur 3x
Gast
#354786
Ich habe in meinem Main-Programm folgende for-Schleife:
int i;
for(i=0;i<5000;i++){
if(FIFOP_SET && !FIFO_SET) {
fputs("FIFO overflow: flushing RXFIFO\r\n", uart);
...
}
if(FIFOP_SET){
fputs("FIFOP=1\n", uart);
}
if(!(FIFOP_SET)){
fputs("FIFOP=0\n", uart);
}
if(i==4999){
printf("i= %d ", i);
i=0;
}
}
diese Schleife wird immer genau 3x ausgeführt. Warum??
Gast
#354787
Die Antwort habe ich nicht, aber ein Vorschlag: Du kannst nach jeder
Funktion die aufgerufen wird eine Ausgabe machen (ich weiss jetzt nicht
wo dein printf angezeigt wird, ist ja auch nur ein Beispiel)
for(i=0;i<5000;i++){
if(FIFOP_SET && !FIFO_SET) {
fputs("FIFO overflow: flushing RXFIFO\r\n", uart);
printf("#Zeile %i durchlaufen\n", _LINE_);
...
}
printf("#Zeile %i durchlaufen\n", _LINE_);
if(FIFOP_SET){
printf("#Zeile %i durchlaufen\n", _LINE_);
fputs("FIFOP=1\n", uart);
}
printf("#Zeile %i durchlaufen\n", _LINE_);
usw. dann siest du wo das er hängen bleibt. Eventuell auch noch i
ausgeben.
mfg Andreas
Gast
#354788
Hallo,
mit den code den du hier gepostet hast sollte es eigentlich gehen. aber
leider sieht man nicht was noch passiert im Code oder was du geplant
hast, da du nicht alles gepostet hast. Zudem fällt auch auf das hier
einige Konstruktionen sind die nicht ganz so einleuchtend sind und auch
übersichtlicher gehen. Vor allem stört die Kontruktion:
if(i==4999){
printf("i= %d ", i);
i=0;
}
Das in einer for-scheife zu finden ist nicht ganz okay, man sollte hier
lieber gleich ne while()-scheife nehmen. Aber nix des so trotz wäre der
fehlende Code noch sehr hilfreich.
CA
Gast
#354789
Habe den Code jetzt so abgeändert:
while(i<5000){
if(FIFOP_SET && !FIFO_SET) {
fputs("FIFO overflow: flushing RXFIFO\r\n", uart);
cc_strobe(CC2420_SFLUSHRX);
cc_strobe(CC2420_SFLUSHRX);
ENABLE_FIFOP_INT;
}
if(FIFOP_SET){
fputs("FIFOP=1", uart);
printf(" i= %d\n ", i);
}
if(!(FIFOP_SET)){
fputs("FIFOP=0", uart);
printf(" i= %d\n ", i);
}
i++;
if(i==4999){
printf("i= %d ", i);
i=0;
}
}
und erhalte immer folgende Ausgabe:
FIFOP=0 i=0
FIFOP=0 i=1
FIFOP=0 i=2
und dann geht es wieder von vorne los.
Der Rest des Codes ist nur eine Initialisierungsfunktion, die bis dahin
abgeschlossen ist.
Gast
#354790
hm ... schauts schwer aus, jetzt ist die frage ob i noch woanders benutzt wird, oder gar lobal definiert ist, und obs der richtige type ist. Aber wenn das programm eh immer in einer schleife laufen soll geht auch ein while( 1 ) ... dann wird while nie abgebochen. Benutzt du intrrupts ? benutzt du da eine variable i ? CA
Gast
#354791
i verwende ich nur intern in einer anderen Fkt als in einer For-Schleife, habe das Programm aber auch mit der Variable u probiert, die läuft dann erst bis 2 wie oben und nach ein paar automatischen Resets nur noch bis 1!
Gast
#354792
Das oben ist ja nur ein Testauszug aus meinem Programm, da mein komplettes Programm gar nicht funktioniert und ich wissen möchte/muss, woran es liegt. Nun habe ich mein wirkliches Prog. mit AVR Studio gedebugged und bin auf folgendes komisches gekommen. m Der Code bleibt an dieser Zeile hier stehen: if(FIFOP_SET && !FIFO_SET) {... in der H-Datei: #define FIFOP_SET bit_is_set(PORTE, PE4) #define FIFO_SET bit_is_set(PORTD, PD6) und dass obwohl ich sehe (mit dem Oszi und bei den Pins im AVRStudio), dass FIFOP auf 5V liegt und FIFO auf 0V, also ist die Bedingung doch erfüllt?! Was kann das nur sein?????
Gast
#354793
Bist Du sicher, dass Du PORTE und PORTD abfragen willst, oder vielleicht eher PIND und PINE?
Gast
#354794
...oder sind das Ausgänge? Siehst Du jetzt das Problem mit dem unvollständigen Code? Man muss jedes Detail extra nachfragen...
Gast
#354795
schaut doch einfach in den asm code........
Gast
#354796
Also, wenn ich nun im AVR-Studio debuggen will, seh ich nicht mehr wo er im Code ist, sondern nur noch das Disassembler-Fenster. Wie kann ich es machen, dass er wieder im c-Code debuggt?? Sorry, wenn ich mich so blöd stell.
Gast
#354797
Jetzt würde es mich doch mal interessieren, wie Du das printf eingebunden hast. Dein Programm läuft ja mit voller Geschwindigkeit durch. Wenn die "printf" und "puts" in einen Buffer für die Ausgabe über die serielle Schnittstelle schreiben, dann kommt die serielle Schnittstelle mit der Ausgabegeschwindigkeit da natürlich nicht mit. Das Programm würde also viele Daten in den Ausgabepuffer schreiben - bis der eventuell überläuft, den Stack kaputt schlägt und Dein Programm abstürzt bzw. wieder von vorne beginnt.
Gast
#354798
Hallo Frank, ich bin totale Anfänderin und das was du schreibst klingt mir total logisch! und ich glaube, dass das wahrscheinlich auch die ganze Zeit mein Fehler ist. Mein Programm bricht nämlich immer wieder ab bzw. bleibt irgendwo stehen. Ich versuche es jetzt ohne diese Ausgaben (printf und puts) und dafür debugg ich mit dem AVR Studio. Danke für den Hinweis!!!
Gast
#354799
.. da bin ich mal gespannt, ob's ohne printf's usw. dann geht. Viel Erfolg Du kannst immer noch zu PlanB wechseln:
Schmeiss mal alles aus deinem Pgm raus. Du beginnst
bei 0
int main()
{
int i;
for(i=0;i<5000;i++){
}
}
Das muss klappen.
Dann beginnst du, sukzessive wieder die Funktionalitaet
von vorher einzubauen. Der erste Schritt könnte sein:
int main()
{
int i;
for(i=0;i<5000;i++){
i++;
if(i==4999){
printf("i= %d ", i);
i=0;
}
}
}
usw, usw.
Solange bis der Effekt wieder auftritt. Wenn du den Effekt
wieder siehst, analysierst du mal, was du als letztes
eingebunden hast, und wie das ganze mit dem Rest vom Pgm
interagiert.
Ach ja: Wenn Variablen ohne ersichtlichen Grund ihre Werte ändern, dann liegt das meist an irgendwelchen Array- Überläufen. Halt also die Augen nach solchen Dingen offen. zb. int i; char Test[5]; int j; i = j = 0; Buffer[5] = 'a'; Die Wahrscheinlichkeit ist hoch, dass jetzt entweder i oder j nicht mehr den Wert 0 enthalten.
Gast
#354802
So ins Blaue: Watchdog-Timer an, der ständig ein Reset ausführt? Antwort schreiben |
Anzeige
|
