Hallo. Versuche gerade mit dem Studio 6.2 Simulator um zu gehen - aber, es tut sich nichts. Auf ATmega88 eingestellt. Optimierung (-O1) Zeigt beim Compilieren keinen Fehler. Sollte Ausgang PORTB 6 im Intervall von 1 Sek. zw. 0/1 endlos wechseln. Unter IO View findet keinerlei Veränderung statt. Unter Watch 1 steht dauerhaft Unknown identifier, dabei gibt es doch eine klare Zuweisung. Egal ob Debug/Einzelschritte oder /Dauerlauf. Kann es sich um eine generelle Simulator-Einstellung handeln? Innerhalb eine Sim-Anleitung konnte ich keinen Lösungsweg finden.
Angehängte Dateien:
-
Zwischenablage01.jpg
110 KB
Nimm mal Einzellschritt und lass den delay quatsch weg und blende im Zweifelsfalle den Assemblerview ein und las die Einzelschritte dort laufen nicht im C-Code.
__Son´s B. schrieb: > Sollte Ausgang PORTB 6 im Intervall von 1 Sek. zw. 0/1 endlos wechseln. Der SImulator macht den Update der simulierten Ports erst dann, wenn das Programm wieder steht. D.h. du kannst es nicht einfach laufen lassen und darauf warten, dass in der I/O View du die Bits toggeln siehst. Geh im Einzelschrittbetrieb durch. Dann tut sich auch was. > Egal ob Debug/Einzelschritte oder /Dauerlauf. Der Balken gibt an, welche Anweisung als nächstes ausgeführt wird. D.h du musst hier in der jetzigen Situation einen Einzelschritt machen, um die Veränderung danach im I/O View zu sehen.
__Son´s B. schrieb: > Sollte Ausgang PORTB 6 im Intervall von 1 Sek. zw. 0/1 endlos wechseln. Du hast wohl sonst nix zu tun in deinem Leben? Der Simulator ist schweinelangsam im Verhältnis zum RL. Wie schnell (oder vielmehr: langsam) genau, hängt von der Leistungsfähigkeit deines Hostsystems ab. Im übrigen setzt man sowieso einfach mal einen Breakpoint auf die entscheidende Stelle und ggf. (wenn man zu doof ist, den Code sinnvoll an die Simulatorumgebung anzupassen) geht man einfach mal ein Bier trinken, damit sich der simulierte PC in Ruhe an der Stelle einfinden kann... > Unter IO View findet keinerlei Veränderung statt. Solange simulierter Code läuft, passiert nirgendwo in der Simulatoroberfläche irgendetwas sinnvolles, jegliches unkontrollierte, spastische Herumgeklicke wird maximal nur zum Absturz des (recht halbseiden programmierten) Simulators führen. Wenn man wirklich was sehen will, muß man die Simulation anhalten. Entweder sinnvoll mittels Breakpoint oder (als letzter Ausweg, um zu sehen, wo der Code sich rumtreibt) mittels "Pause"-Icon. In deinem Fall landest du so garantiert in einer Zeile mit "delayXYZ". Das ist pädagogisch sogar sehr gut so: Es zeigt dir, was du möglichst meiden solltest. Denn es ist tatsächlich so: der Controller ackert hier wie verrückt, macht aber absolut nix sinnvolles. Genau diese Lehre solltest du ziehen...
__Son´s B. schrieb: > Egal ob Debug/Einzelschritte oder /Dauerlauf. Bei Blinken im Sekundentakt und Einzelschritt kannst du davor sitzen und "weiter" drücken bis du schwarz wirst. Das dauert etwas länger. Probier es mal mit Breakpoints und guck dir die Stopuhr parallel dazu an.
Mit den Optionen -O1, -O2 und -Os wird der Code optimiert. Was der Compiler erzeugt, kann ganz erheblich vom Quelltext abweichen. Das behindert Dich beim Arbeiten mit dem Simulator. Es kann sein passieren, dass du einen Einzelschritt machen willst, aber stattdessen mehrere Code-Zeilen am Stück ausgeführt werden. Zum Simulieren solltest du minimal optimierten Code verwenden, also mit -O0. Nur leider funktionieren dann die delays nicht mehr (diehe Doku der Lbrary). So oder so werden die Timings der Delay Schleifen beim Simulieren viel viel viel länger dauern, als erwartet. Also lass sie einfach weg, dann klappt es mit dem Simulieren im Einzelschritt-Modus auch prima. Das Timing-Verhalten kann man sowieso nicht simulieren.
c-hater schrieb: > mittels "Pause"-Icon. > > In deinem Fall landest du so garantiert in einer Zeile mit "delayXYZ". > Das ist pädagogisch sogar sehr gut so: Es zeigt dir, was du möglichst > meiden solltest. Das ist auch eine bewährte Profiling-Technik, wenn man gerade keinen Profiler zur Hand hat: * Auf "Pause" klicken * Aufschreiben in welcher Funktion (oder gar welcher Zeile) er sich gerade befand * Weiterlaufen lassen * wieder auf Pause Klicken und obiges mehrere Dutzend Mal wiederholen. * Danach ausrechnen wieviel Prozent der gesamten Zeit er in jeder einzelnen Funktion verbracht hat, ja sogar in welcher Zeile wenn Du genug Samples gemacht hast. Pro-Tip: Mit der selben Methode kann man auch über Monate hinweg bis auf die Minute genau ermitteln wie viele Minuten jeder einzelne Mitarbeiter pro Tag in der Kaffeeküche verbracht hat einfach indem man sich zu zufällig(!) gewählten Zeiten (Zufallsgenerator verwenden!) einige Male pro Tag einen Kaffee holen geht.
Angehängte Dateien:
-
Zwischenablage02.jpg
77 KB
Wolfgang schrieb: > Bei Blinken im Sekundentakt und Einzelschritt kannst du davor sitzen und > "weiter" drücken bis du schwarz wirst. Das dauert etwas länger. > Probier es mal mit Breakpoints und guck dir die Stopuhr parallel dazu > an. Zwischen jedem Einzelschritt habe ich ~1 Min gewartet - nichts passierte! Als Wert in PORTB wird nach wie vor dauernd unbekannte Bestimmung angezeigt, dabei habe ich den PORT doch richtig als Ausgang zu gewiesen. Breakpoint nach der ersten Zuordnung gesetzt - leider kommt hier die Fehlermeldung. Ev. doch ein Konfigurationsproblem, ein kleines Häkchen, das ich irgend wo setzten muss? Zur Zeit nerfts mich als Anfänger. In einem Jahr werde ich vermutlich über solche Kleinigkeiten lachen... Morgen geht die "Bastelei" weiter.
Du kannst dir den PORTB nicht ins Watch Fenster holen. Auch wenn 'PORTB' genau so verwendet wird und das ganze in C auch so aussieht, beim PORTB handelt es sich nicht um eine echte Variable. Wenn du den Zustand vom PORTB sehen willst: rechts im I/O View ist er doch!
:
Bearbeitet durch User
Karl H. schrieb: > Wenn du den Zustand vom PORTB sehen willst: rechts im I/O View ist er > doch! Hallo - genau da passiert leider nichts. Ins Watch-Fenster habe ich bei einem anderen Test-Programm, Variblen beobachtet, dort veränderte sich leider auch nichts - keine Inhaltsveränderung. Daher vermute ich immer noch, dass der Simulator BEI MIR nicht korrekt eingestellt ist.
__Son´s B. schrieb: > Karl H. schrieb: >> Wenn du den Zustand vom PORTB sehen willst: rechts im I/O View ist er >> doch! > > Hallo - genau da passiert leider nichts. > > Ins Watch-Fenster habe ich bei einem anderen Test-Programm, Variblen > beobachtet, dort veränderte sich leider auch nichts - keine > Inhaltsveränderung. Daher vermute ich immer noch, dass der Simulator BEI > MIR nicht korrekt eingestellt ist. Das kann sein. Welchen hast du denn ausgewählt. Der Tooltip, der auf deinem Bild sichtbar ist, deutet in die Richtung, dass du einen On-Chip Debugger ausgewählt hast. Das System informiert dich, dass das nicht funktioniert. Du kannst mit deinem Aufbau nicht dem realen IC auf die Finger sehen, sondern musst den Simulator den Chip simulieren lassen.
__Son´s B. schrieb: > Zwischen jedem Einzelschritt habe ich ~1 Min gewartet - nichts > passierte! Was soll auch passieren? Einzelschritt heißt, dass bei jedem Klick auf Schritt die nächste Operation ausgeführt wird. Ein Delay von 1Min heisst ganz grob gerechnet: 1Mhz Takt = 1.000.000 Takte / Sekunde 1Min = 1Mio * 60 sec = 600 Mio Takte Du musst also 600 Mio Einzelschritte machen, um etwas zu sehen. Glaub mir, da brauchst du mehrere Mäuse, denn die Tasten machen das nicht mit ;-) Der Simulator ist KEIN Echtzeitsimulator. Lass mal alle Delays raus und mach dann die Einzelschritte, dann siehst du auch was.
Hallo, ich habe eine Frage zum letzen Screenshot(Zwischenablage02.jpg). Die Ausführung des Simulators wurde vor der ersten Zeile von _myMetro() gestoppt: PORTB |= (1<<PB6); Damit der Simulator zu dieser Zeile kommen kann muss er erstmal einige Zeilen in der main()-Funktion durchlaufen. Konkret geht es mir um die erste Zeile: DDRB |= (1<<PB6); Mit dieser Zeile wird Bit6 des "DataDirectionRegister portB" auf eins setzen. Da es sich um die erste Zeile handelt sollten alle Bits vorher 0 gewesen sein (Ich gehe einfach mal davon aus, dass es hier keinen Bootloader o.ä. gibt). Nachdem also die erste Zeile ausgeführt wurde sollte DDRB == 0x40 sein. Ich hoffe, ihr stimmt meiner 'Analyse' bis hierher zu. Warum zeigt I/O View in diesem Screenshot immernoch 0x00 als Wert für DDRB an? CU, Jay
Der Pointer (gelber Pfeil) zeigt auf den Befehl, der beim nächsten Step ausgeführt wird. Schau dir den Assemblercode beim Debuggen mit an dann wird dir das klar. Dein Bit ist gesetzt wenn der Pointer in der nächsten Zeile ist.
Jay Low schrieb: > Warum zeigt I/O View in diesem Screenshot immernoch 0x00 als Wert für > DDRB an? Genau, dass ist was mich dauernd iritiert; egal wie weit ich das Prog laufen lasse, der Registerzustand ändert sich nie. Thomas H. schrieb: > Der Pointer (gelber Pfeil) zeigt auf den Befehl, der beim nächsten Step > ausgeführt wird. Das Foto ist nach vielen Breakpoints und Durchläufen entstanden. Egal wie weit das Prog läuft, Werte ändern sich nicht. Karl H. schrieb: > du einen On-Chip Debugger ausgewählt hast. Das System informiert > dich, dass das nicht funktioniert. Du kannst mit deinem Aufbau nicht dem > realen IC auf die Finger sehen, sondern musst den Simulator den Chip > simulieren lassen Gibt es mehrere/unterschiedliche Simulatoren im Studio 6.2? Ist bei mir ein falscher voreingestellt/angewählt? Ev.ist das die Lösung. Wie/wo schalte ich diesen um? Programmer der debuggen kann habe ich noch nicht - dauert noch ein wenig. Bis dahin möchte ich mit dem Simulator weiter lernen und verstehen. Generell verstehe ich den Studio-Simulator als Vortest-Plattform, um später Einzelbereich auf ihre Funktion zu testen. Sobald das Gesamtprog. ferig ist, wird es via Programmer im uC gespeichert und dort zum Laufen gebracht. Alex D. schrieb: > Lass mal alle Delays raus und mach dann die Einzelschritte, dann siehst > du auch was. Alle delays raus genommen >>> trotzdem keinerlei Wertänderung bei Einzelsteps.
__Son´s B. schrieb: > Wie/wo schalte ich diesen um? Was ist bei dir hier eingestellt (Bild) Die Ansicht kriegst du mittels 'Projekt - ... Properties (Alt+F7)' > später Einzelbereich auf ihre Funktion zu testen. Sobald das Gesamtprog. > ferig ist, wird es via Programmer im uC gespeichert und dort zum Laufen > gebracht. Das ist naiv. Den Simulator benutzt du als Testumgebung, mit der du dir einzelne Teilbereiche ansiehst und testest. Der Löwenanteil des Debuggings besteht darin, dass man * seine Programmiersprache beherrscht * sich langsam und in Schritten dem Endziel nähert * man lernt, aus dem tatsächlich beobachtetem Verhalten auf mögliche Programmfehler rückzuschliessen * man sich dem laufenden Programm mit geeigneten Ausgabemöglichkeiten sich Hilfen schafft, so dass einem das Programm selber beim Debuggen hilft. Es liegt in der Natur der Sache eines µC Programmes, dass es eher schwierig ist, nur mit dem Debugger alleine Problemen auf den Grund zu gehen. Für manche Dinge ist er hilfreich, bei anderen Dingen (speziell wenn es darum geht, von externer Hardware eingehenden Informationen zu bearbeiten) nützt er dir nichts. Wenn du wissen willst, warum ein PI Regler es nicht schafft, das Pendel im Gleichgewicht zu halten, hilft dir zb ein Debugger genau gar nichts. Ein Debugger ist super, wenn man ein Teilproblem für sich alleine betrachten kann. Sobald aber eingangsseitig eine gewisse zeitliche Komponente ins Spiel kommt, wird er zunehmend weniger brauchbar.
:
Bearbeitet durch User
Angehängte Dateien:
-
Zwischenablage01.jpg
89 KB
Karl H. schrieb: > Das ist naiv. NEIN, Anfängerglück... Karl H. schrieb: > Was ist bei dir hier eingestellt > (Bild) siehe Bild. Karl H. schrieb: > Den Simulator benutzt du als Testumgebung, mit der du dir einzelne > Teilbereiche ansiehst und testest. Genau so habe ich mir das gedacht. Schreiben wir gerade von dem Gleichen? Karl H. schrieb: > Ein Debugger ist super, wenn man ein Teilproblem für sich alleine > betrachten kann. Mir geht es bei meinen späteren Projekten (wenn ich´s dann mal kann) primär um logische Verknüpfungen, mit I/O Ein/Ausgängen. Gelegentlich auch ADC-Eingänge, die via Schwellwert ausgewertet werden.
Hallo, wenn du dir das Disassembly-Fenster anschaust wirst du feststellen, dass dein Simulator nur NOPs(NoOPeration) ausführt. Also nichts macht. Deshalb werden auch keine Register gesetzt. Auch wenn es sich nur um einen Simulator handelt muss dieser programmiert werden. Stell also links im Dropdownmenü bei 'Programming settings' von 'Skip programming' auf ... das andere halt. Dann sollte es auch mit der Simulation funktionieren. CU, Jay
Hi Jay - DANKE ...auf "Erase entire chip" - Funktioniert! --2-- Muss bei Simulator eigentlich immer "_delay_ms()" heraus genommen werden? --3-- Teste auch gerade etwas anderes; ich lege ein Projekt auf einem Rechner an, arbeite später aber mit 2 Rechnern (Privat/Arbeit) und vom USB-Stick. Alle unterschiedliche Rootdir. aber gleiche Projektordner (uc_projekt) Bsp: d:\xxx\yyy\uc_projekt\codeschloss_blabla\... Projekte werden aus Studio, mit "Projekt öffnen", geöffnet. Ev.kommt Studio damit nicht sauber zurecht.
Karl H. schrieb: > Es liegt in der Natur der Sache eines µC Programmes, dass es eher > schwierig ist, nur mit dem Debugger alleine Problemen auf den Grund zu > gehen. Für manche Dinge ist er hilfreich, bei anderen Dingen (speziell > wenn es darum geht, von externer Hardware eingehenden Informationen zu > bearbeiten) nützt er dir nichts. Das ist nicht ganz korrekt. Ich benutze den Simulator z.B. durchaus erfolgreich, um die Signalverarbeitung aus analogen Quellen zu debuggen. Das funktioniert ungefähr so: Vorarbeit: Originales Signal sampeln z.B. mit Audacity oder durch Simulation der analogen Peripherie mittels LTSpice generieren. In beiden Fällen hat man am Ende einfach ein *.wav-File als Signalquelle für die AVR-Simulation als Ergebnis. Nun braucht man bloß noch ein kleines Progrämmchen, was aus dem WAV- ein STI-File macht (Stimuli-Datei für den Simulator). Dieses Programm benötigt außer dem WAV-File bloß noch zwei Informationen: den Takt des simulierten AVR und die von diesem verwendete Samplerate. Mit diesen Informationen kann ein STI-File generiert werden, welches an einem (oder zwei) beliebigen GPIO-Port des simulierten AVR im richtigen Moment das jeweilige Sample als entsprechendes Bitmuster bereitstellt. Im simulierten AVR-Programm selber muß man nur noch an einer Stelle was drehen: dort wo das Sampleergebnis vom ADC in die MCU-Register eingelesen wird. Da ergänzt man im einfachsten Fall einfach dahinter zwei GPIO-Reads. Um näher am original-Timing zu bleiben, kann man alternativ auch die ADC-Reads durch GPIO-Reads ersetzen. BTW: Obiges war die Vorgehensweise für den SimulatorV1. Im aktuellen Studio ist aber nur noch der SimulatorV2 verfügbar. Problem? Nein, nicht wirklich. Es muß nur eine Sache geändert werden, das Programm, was aus WAV STI macht (neues, viel mächtigeres STI-Dateiformat). Noch cooler: Man braucht dann den Umweg über die GPIO-Ports nicht mehr, am simulierten AVR-Programm braucht also garnichts mehr speziell für den Ablauf in der Simulation angepaßt zu werden. Das ist insbesondere deswegen ziemlich geil, weil man das Zeitverhalten des Programms in der simulierten Umgebung damit nicht mehr bezüglich der Verhältnisse im RL beeinflußt. > Wenn du wissen willst, warum ein PI Regler es nicht schafft, das Pendel > im Gleichgewicht zu halten, hilft dir zb ein Debugger genau gar nichts. Ganz genau! Übrigens genausowenig wie ein Simulator (selbst mit oben beschriebener Vorgehensweise). Sobald es einen Feedback aus der Simulation oder der durch den Debugger kontrollierten echten Umgebung auf die analog-Scheiße der (ggf. virtuellen analogen) Umgebung geben müßte, scheitert beides gleichermaßen kläglich. Jeder erreichte Breakpoint bedeutet das Ende der Echtzeit (egal ob "echte" Echtzeit oder nur simulierte). Nur die Gründe sind verschieden... Genau deswegen finde ich, daß in-circuit-Debugging deutlich überbewertet wird. Was das kann, kann ein Simulator idealerweise mindestens auch oder sogar deutlich besser (Möglichkeit zum gezielten Back-Trace durch die Möglichkeit zur deterministische Wiederholbarkeit einer Problemsituation). Aber natürlich gibt es auch einen grundlegenden Nachteil: Die Simulation muß einfach mal "passen". Wenn sie die Hardware nicht korrekt abbildet, wird man u.U. auch zu falschen Schlüssen kommen. So ganz nutzlos ist also auch in-circuit-Debugging sicher nicht. Bei schweren Problemfällen kommt man meist nicht drum herum, mit beidem zu hantieren. Das Ergebnis ist dann i.A. ein Bugreport zum Simulator oder zur realen Hardware. Oder sogar zu beidem, auch das habe ich schon einmal erleben dürfen...
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.