Hallo, ich habe mir heute den Simulator für Win herunter geladen um ein paar Subroutinen zu testen, es hat einfach nicht geklappt der Code lief einfach nicht. Nach dem ich mir ein paar Testzeilen geschrieben habe mußte ich feststellen dass der mov Rd,Rr genau umgekehrt ausgeführt wird. Jedenfalls bei meiner Installation vom Simulator. Ich habe auch ein .jpg gemacht. Kann mir jemand sagen wo ich was einstellen muss dass korrekt simuliert wird. Gruß
:
Verschoben durch User
Andreas N. schrieb: > Hallo, > > ich habe mir heute den Simulator für Win herunter geladen um ein paar > Subroutinen zu testen, es hat einfach nicht geklappt der Code lief > einfach nicht. Nach dem ich mir ein paar Testzeilen geschrieben habe > mußte ich feststellen dass der mov Rd,Rr genau umgekehrt ausgeführt > wird. Jedenfalls bei meiner Installation vom Simulator. Ich habe auch > ein .jpg gemacht. Kann mir jemand sagen wo ich was einstellen muss dass > korrekt simuliert wird. Das geht über Systemsteuerung->Software. Den schrottigen Simulator deinstallieren und statt dessen AVR-Studio installieren. Das enthält einen Simulator, der zumindest den AVR8-Core vollständig fehlerfrei simulieren kann. Bei der Peripherie hingegen ist auch nach fast zwei Jahrzehnten Entwicklungszeit immer noch Vorsicht geboten. Manche Peripherie wird bis heute garnicht unterstützt, andere nur mit mehr oder weniger großen Bugs und/oder in einer Form, die die Simulation erstmal ziemlich nutzlos macht. Offensichtlich wurde/wird der Simulator nur mit (qualitativ und quantitativ) völlig ungenügender Manpower entwickelt, wenn er überhaupt weiter entwickelt wird...
c-hater schrieb: > deinstallieren und statt dessen AVR-Studio installieren. Das enthält Das sollte natürlich eigentlich "Atmel-Studio" heissen. Sorry.
Und noch abgesehener davon, dass Dein Simulator ganz prima funktioniert. Deine Vorstellung vom mov - Befehl ist verkehrt: > mov r16, r0 > !!! copiert r16 nach r0 ist falsch. - mov rd, rr kopiert rr (2.Parameter) nach rd (1.Parameter), d für Destination : Ziel. Schau nochmal ins AVR-Instruction Manual.
Heinz R. schrieb: > Und noch abgesehener davon, dass Dein Simulator ganz prima funktioniert. > Deine Vorstellung vom mov - Befehl ist verkehrt: > >> mov r16, r0 >> !!! copiert r16 nach r0 > > ist falsch. > > - mov rd, rr > kopiert rr (2.Parameter) nach rd (1.Parameter), d für Destination : > Ziel. > > Schau nochmal ins AVR-Instruction Manual. Hmm... Das war jetzt zumindest ein Hinweis, sich den Kram nochmal genauer anzuschauen. Also: aus dem OT ist bei genauer Betrachtung weder abzulesen, was der TO erwartet hat, noch ist abzulesen, was tatsächlich passiert ist. Sprich: der TO ist dermaßen inkompetent, dass es ihm nicht einmal möglich ist, sein Problem kompetent darzustellen. Also ist nach Ockham deine Annahme am wahrscheinlichsten: der TO erwartete schlicht das Falsche. Trotzdem ist Atmel-Studio die bessere Wahl. µC-Anwendungen leben davon, dass man ihre Peripherie benutzt. Über kurz oder lang muss man also doch den Atmel- (heute: MC-) Simulator benutzen. Dann kann man auch gleich damit anfangen.
Also für mich ist das angehängte Bild eindeutig, wenn ich mir das Testprogramm anschaue und daneben die Registerinhalte ...
Andreas N. schrieb: > ich habe mir heute den Simulator für Win herunter geladen um ein paar > Subroutinen zu testen Gemeint ist wohl Beitrag "AVR Simulator mit grafischer Benutzeroberfläche für Linux" c-hater schrieb: > Das geht über Systemsteuerung->Software. Den schrottigen Simulator > deinstallieren und statt dessen AVR-Studio installieren. Das enthält > einen Simulator, der zumindest den AVR8-Core vollständig fehlerfrei > simulieren kann. Das AVR-Studio 4 hat bei mir, bis Windows 7 prima funktioniert, mein letzter Test mit WINE vor 4 Jahren war allerdings noch nicht so perfekt. Für gelegentliche Tests von Routinen, so wie vom TE hat das ziterte Projekt allerdings seinen Zweck erfüllt. c-hater schrieb: > Trotzdem ist Atmel-Studio die bessere Wahl. µC-Anwendungen leben davon, > dass man ihre Peripherie benutzt. Über kurz oder lang muss man also doch > den Atmel- (heute: MC-) Simulator benutzen. Dann kann man auch gleich > damit anfangen. Das ist wohl wahr. Mangels Resonanz, war aber wohl der Anreiz, das Projekt weiter zu entwickeln nicht so hoch.
S. Landolt schrieb: > Also für mich ist das angehängte Bild eindeutig, wenn ich mir das > Testprogramm anschaue und daneben die Registerinhalte ... Ja, eindeutig ein Schiebebefehl ;-)
... wir sind uns doch darin einig, dass in r16 0xFF stehen müsste?
Heinz R. (Gast) schrieb: >Und noch abgesehener davon, dass Dein Simulator ganz prima funktioniert. >Deine Vorstellung vom mov - Befehl ist verkehrt: >> mov r16, r0 >> !!! copiert r16 nach r0 >ist falsch. > - mov rd, rr >kopiert rr (2.Parameter) nach rd (1.Parameter), d für Destination : >Ziel. >Schau nochmal ins AVR-Instruction Manual. Nöö, schau Du wie auch c-hater noch mal die Beschreibung des TO an. Die Kopieraktion r16 nach r0 ist ja genau das, was er bemängelt, und das sieht man ja auch im Screeenshot, daß da was schief läuft.
:
Bearbeitet durch User
S. Landolt schrieb: > Also für mich ist das angehängte Bild eindeutig, wenn ich mir das > Testprogramm anschaue und daneben die Registerinhalte ... Nein. Um das zu entscheiden, bräuchte man die Registerinhalte von zwei Zeitpunkten... Weil: wenn vermutet wird, dass die Simulation nicht tut, was sie tuen soll, dann kann man das natürlich für keine Instruktion annehmen. D.h.: man kann sich auch nicht darauf verlassen, dass das Programm sich vorher erwartungsgemäß verhalten hat. Simple Anwendung trivialster Gesetze der Logik...
Doch schon einige Zeit vergangen seit damals; aber damals hatten Sie nicht versucht, mit Gewalt etwas an den Haaren herbeizuziehen, bloß um Recht zu behalten. Und, pardon, hier nun stehen Sie mit Heinz doch alleine auf weiter Flur. Aber nichts für ungut, trotz allem wünsche ich Ihnen noch Frohe Ostern.
S. Landolt schrieb: > Doch schon einige Zeit vergangen seit damals; aber damals hatten Sie > nicht versucht, mit Gewalt etwas an den Haaren herbeizuziehen, bloß um > Recht zu behalten. Und, pardon, hier nun stehen Sie mit Heinz doch > alleine auf weiter Flur. Dunkel ist der Rede Sinn... > Aber nichts für ungut, trotz allem wünsche ich Ihnen noch Frohe > Ostern. Jo, ebenfalls.
c-hater (Gast) schrieb: >S. Landolt schrieb: > >> Also für mich ist das angehängte Bild eindeutig, wenn ich mir das >> Testprogramm anschaue und daneben die Registerinhalte ... > >Nein. > >Um das zu entscheiden, bräuchte man die Registerinhalte von zwei >Zeitpunkten... Wie meinen? Man vollzieht das kleine Testprogramm einfach mal im Kopf nach, und stellt nach Ausführung fest, daß die Registerinhalte rechts als Ergebnis nicht so ganz stimmen.
Jens G. schrieb: > Man vollzieht das kleine Testprogramm einfach mal im Kopf nach, und > stellt nach Ausführung fest, daß die Registerinhalte rechts als Ergebnis > nicht so ganz stimmen. Das ist ein Ansatz. Der allerdings nur zu der Erkenntnis führt, das da irgendwo im Simulator ein Bug ist. Um hingegen feststellen zu können, wo genau der steckt, braucht man im Minumum zwei Snapshots. Diese zwei genügen genau dann, wenn man eigentlich bereits weiss, wo der Bug stecken muss und man sie genau vor und nach der fehlerhaft implementierten Instruktion macht.
c-hater schrieb: > Das ist ein Ansatz. Der allerdings nur zu der Erkenntnis führt, das da > irgendwo im Simulator ein Bug ist. Hat der TE schon richtig beschrieben, im Simulator waren Quelle und Ziel vertauscht, Der Disassembler hat es noch richtig angezeigt. Hab es im o.g. Thread korrigiert.
c-hater schrieb: > Das ist ein Ansatz. Der allerdings nur zu der Erkenntnis führt, das da > irgendwo im Simulator ein Bug ist. Um hingegen feststellen zu können, > wo genau der steckt, braucht man im Minumum zwei Snapshots. Diese zwei > genügen genau dann, wenn man eigentlich bereits weiss, wo der Bug > stecken muss und man sie genau vor und nach der fehlerhaft > implementierten Instruktion macht. Hää ? String formula to komplex error ! ------------------------------------------------------------------------ -- Was ich noch zum AVR-Handbuch sagen wollte auf meinem jpg ist rechts unten ein Ausschnitt aus dem Handbuch zu sehen. Der der das nicht erkennt wird's wohl nicht gelesen haben - das Handbuch. Zur Systemsteuerung/Software wäre zu sagen, dass der 'Schrott-Simulator' gar keine Installation braucht. Sondern lediglich vor der Kommandozeile gestartet wird. Und das ist das Ideale daran. @Ingo: Danke für die super schnelle Korrektur. Funktioniert jetzt prima. PS. Mein 'Studio' ist mein Kopf, seit ca. 37 Jahren, an gefangen mit dem i8048 als Ur-Ur-Opa der Single-Chipper und es gab nur Assembler zur Programmierung. No Studio, No Atmel aber Intel Inside.
Bitte 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.