Hallo hat jemand eine Ahnung, woran es liegen kann, dass beim Debuggen mit dem Pickit3 falsche Stellen im Quelltext angezeigt werden? Habe schon mehrere Sachen getestet. Neustart von MPLAB, Neustart PC, Pickit an anderem USB-Anschluss. Nichts hat geholfen. Nach einen Reset des µC steht nach ca. 3 Einzelschritten der grüne Pfeil mitten in einem Unterprogramm. Bei weiteren Einzelschritten bleibt er teilweise auch auf Leerzeilen stehen. Verwendete Umgebung: Laptop: Win7 MPLAB 8.88 HI-TECH C für PIC10/12/16 Ver. 9.83 Gibt es da eine Erklärung für? Wäre scön wenn ihr mir helfen könntet. Die c-Datei ist mit bei, soll eine Garagentorsteuerung werden. Silvio Warum wird bei der Vorschau nicht angezeigt dass die Datei ängehängt wurde? Egal, nu gibts die doppelt.
Silvio G. schrieb: > hat jemand eine Ahnung, woran es liegen kann, dass beim Debuggen mit dem > Pickit3 falsche Stellen im Quelltext angezeigt werden? > > Gibt es da eine Erklärung für? Wäre scön wenn ihr mir helfen könntet. > Die c-Datei ist mit bei, soll eine Garagentorsteuerung werden. Das liegt an der Optimierung. Dadurch entstehen im Maschinencode Konstruktionen, die sich so im C-Quelltext gar nicht wiederfinden. Und da setzt er den Breakpoint dann irgendwie oder gar nicht. Oder springt irgendwo hin, wohin du es nun absolut nicht vermutest, weil er irgendwelchen Code zusammengefasst hat. Wenn du die Optimierung abschaltest, ist das vorbei. Dann übersetzt der Compiler den Quelltext Zeile für Zeile. Aber das Ergebnis will niemand haben. mfg.
Hallo nee die Optimierung hab ich nicht abgestellt. Steht in der Standardeinstellung für die Lite-Version. Silvio
Thomas Eckmann schrieb: > Das liegt an der Optimierung. Ist mir noch nicht aufgefallen (allerdings AVR-Studio). Aber: Evtl. wird gerade eine Funktion in einer Lib aufgerufen, da hast du keinen Quelltext dazu... Kannst du durch den ASM-Code gehen?
Hallo hab ich noch nicht getestet, geht auch nicht mal schnell, da die Schaltung momentan grad nicht in Reichweite ist. Aber die ersten 30 Anweisungen sind nur Zuweisungen an einzelne Bits eines Registers oder ganze Register. Habe gerade mal den ASM-Code und das Disassambly Listing angeschaut. Der Controller macht was er soll, aber ich weiß nicht wo er die Befehle her hat. Im Programmspeicher steht folgendes: Adresse Code 000 NOP 001 GOTO 0x18 ... 018 CLRF 0x8 \ Woher kommt das? 019 GOTO 0x4FF / 01A MOVLB 0x1 \ 01B BCF 0x19, 0x7 | Das ist das was auch im Disassambly Listing steht. 01C BSF 0x19, 0x6 | Das wäre auch richtig 01D BSF 0x19, 0x5 / Die Stelle 0x4FF ist auch genau die Stelle wo er bei Debuggen hinspringt. Das sieht mir so aus, als wenn er dort die Variablen initialisiert. Aber warum hat er vor ein paar Änderungen (endschalterzustand war 1 statt 0, dementsprechend war in tasten_lesen in der Überprüfung für ende_oben und ende_unten die Prüfung für aktiv und inaktiv umgedreht) das noch richtig gemacht? Da sprang er nach dem Reset direkt zum ersten Befehl in der main. Silvio
Silvio G. schrieb: > Aber warum hat er vor ein paar Änderungen (endschalterzustand war 1 > statt 0, dementsprechend war in tasten_lesen in der Überprüfung für > ende_oben und ende_unten die Prüfung für aktiv und inaktiv umgedreht) > das noch richtig gemacht? Da sprang er nach dem Reset direkt zum ersten > Befehl in der main. Hier geht es nicht um "richtig" oder "falsch". Macht das Programm, was es soll? Ja. Dann ist es doch egal, wie der Compiler dahin kommt. Rechne 3 * 7. Du könntest jetzt wirklich multiplizieren. Du könntest aber auch 7 + 7 + 7 rechnen. Oder 3 + 3 + 3 + 3 + 3 + 3 + 3. Oder, weil du vorhin schon 2 * 7 ausgerechnet hast und das Ergebnis noch weisst, 14 + 7. Spätestens da steigt dann kein Aussenstehender mehr durch, wie du darauf kommst, das so auszurechnen. So ähnlich macht das ein Compiler auch. Die Optimierung fängt da an, wo die Weisheit, der sich selbst überschätzenden ASM-Friggeler endet. Das ist nicht einfach da durchzusteigen. Und warum macht der Compiler das? Weil es Laufzeit und/oder Speicher spart. Auch wenn es Leute gibt, denen das noch gar nicht aufgefallen ist. Compilier das mal ohne Optimierung. Dann passt das Programm möglicherweise gar nicht mehr in deinen Controller. mfg.
Hallo! Die PIC bleibt beim Debuggen "aus dem Lauf" meistens nicht genau auf dem Breakpoint stehen, da bereits der nächste Befehl in der Pipeline und bereit zur Ausführung ist. Das ist auch irgendwo dokumentiert. Ggf. ein NOP davor einfügen und den Breakpoint auf das NOP setzen. Ansonsten ist man oft schon in der aufgerufenen Funktion drin. Beim "Single Step" passiert das meiner Erfahrung nach nicht. vg Jürgen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.