ich habe gerade im AVR Studio 4 unten stehenden Code simuliert.
Der Debugger wiederholt am Ende nur "while (!(UCSR0A & (1<<UDRE0)));"
Zumindest ist dort die ganze Zeit der gelbe Pfeil.
Ich habe das Programm mit SimulIDE woanders getestet.
UART empfängt 9 mal etwas.
Wie kann man AVR Studio denn dafür nutzen auch UART anzuzeigen?
Warum bleibt der immer bei dieser Stelle? Er müsste doch aufhören nach 9 mal senden.
ich habe gerade im AVR Studio 4 unten stehenden Code simuliert.
Der Debugger wiederholt am Ende nur "while (!(UCSR0A & (1<<UDRE0)));"
Zumindest ist dort die ganze Zeit der gelbe Pfeil.
Entweder wartest du nicht lange genug, denn der Sendevorgang ist langsam (viele Zehntausende CPU-Takte!) oder der Simulator simuliert den UART nicht korrekt. Bei 9600 Baud und 16 MHz CPU-Takt, dauert ein Zeichen mit 10 Bit stolze 1,042ms, das sind 16.666 CPU-Takte.
wie kann man denn
delays überspringen?
Irgendwie klappt das nicht mit den breakpoints.
Sonst hätte ich die einfach übergangen.
D.h. der Debugger bleibt einfach bei _delay_ms(50) hängen..
Ganz grundsätzlich benutzt man delay() nur da, wo die Programme so einfach sind, daß man sie nicht im Simulator testen muß.
Zum Lernen im Simulator benutzt man einfach eine eigene delay-Routine, die im echten Betrieb die passende Libraryroutine aufruft, im Debugmodus aber zurückkehrt, ohne etwas zu machen, oder eine Schleife ausführt, die dann einfach einen Zähler hochzählt.
Zum Lernen im Simulator benutzt man einfach eine eigene delay-Routine,
die im echten Betrieb die passende Libraryroutine aufruft, im Debugmodus
aber zurückkehrt, ohne etwas zu machen, oder eine Schleife ausführt, die
dann einfach einen Zähler hochzählt.
Habe ich mir auch schon gedacht.
Aber es kam mir etwas umständlich vor.
Wie macht man das denn dann ?
Also ich könnte jetzt irgendwas zusammenschreiben.
Aber es gibt sicherlich eine bewährte Schreibweise dafür.
Wonach sollte ich googlen?
dann kommt die Fehlermeldung, dass das Setzen nicht funktioniert.
Kann es sein, dass du mit einer hohen Optimierungsstufe compiliert hast?
Ich benutze normalerweise -O1, damit kommt der Debugger meistens klar. Ansonsten weiche ich auf -Og oder notfalls gar auf -O0 aus. _delay_ms() funktioniert mit -O0 allerdings nicht richtig.
Dann schiebt man die // nur vor die Zeile, die man nicht benutzen möchte. Falls die nrofmilliseconds ein anderer Typ sind als int, sollte man das natürlich anpassen.
Wenn ich die Breakpoints auf die Portausgaben setze und dann auf "Start Debugging" klicke werden die Breakpoints wie auf dem Bild verschoben. Es erscheint dazu noch die Fehlermeldung.
Wenn ich die Breakpoints auf die Portausgaben setze und dann auf
"Start
Debugging" klicke werden die Breakpoints wie auf dem Bild verschoben. Es
erscheint dazu noch die Fehlermeldung.
Moment mal! Benutzt du den Simulator? Dafür braucht man keine Hardware. Oder einen Debugger mit Hardwar? Wenn ja, welchen Debugger und welche Hardware?
Der Simulator läuft auf jeden Fall viel langsamer als ein echter Mikrocontroller. Deswegen führt kein Weg umhin, delays in Größenordnungen von Sekunden durch etwas anderes zu ersetzen.
Ok.
Aber man sieht bei dem Code nicht mehr den gelben Pfeil.
Nur wenn man den Dissembler anschaut kann man den Assembler-Code mitverfolgen.
Ist das normal?
Außerdem musste ich -O0 einstellen..
Kann es sei, dass du einen neueren Compiler als WinAvr2010 (avr-gcc 4.3.3) verwendest? Ich frage, weil der Simulator/Debugger mit neueren Versionen öfter Probleme hatte, bis hin zum Absturz.
Für den Fall dass Dir Foren noch nicht geläufig sind: Man kann sich den Schubs in die richtige Richtung holen, dafür sind sie nützlich.
Und halt zum sozialen Austausch, als Wissensquelle sind sie eher vier minus.
Das innewohnende Problem ist, dass viele Teilnehmer tatkräftig ihr Unwissen verbreiten. Manchmal gezielt, aber meist weil sie's nicht besser wissen, jedoch mitreden wollen.
Du als Hilfesuchender müsstest bereits vorher das Wissen haben, das Dir zum Zeitpunk Deiner Frage noch fehlt, um die ganzen Falschinformationen von den Nutzinformationen auseinander zu halten.
Werde ich mir mal anschauen.
Es sieht danach aus als wäre es möglich Register zu manipulieren.
Um gezielte Tests z.B. für UART durchzuführen, müsste man jedoch genau wissen worauf es ankommt.
Weil der Simulator die Gegenstelle mit der dein µC Kommuniziert nicht
simulieren kann.
Warum?
Eingehende Daten könnten doch digital verarbeitet werden.
Meiner Meinung nach müsste ein digitales Software-Modell dazu in der Lage sein,eingehende UART Nachrichten zu verarbeiten.
" In this simulator you simply can add a c/c++-testprogram which runs on the host in the native host fashion and connect a simulated uart to the simulator which runs your avr program"
"Soft I2C"
Beitrag "Soft I2C Master"
Alleine auf einem uC ist doch dann eine solche Simulation/ Verarbeitung von Kommunikation per Software möglich.
Weil der Simulator die Gegenstelle mit der dein µC Kommuniziert nicht
simulieren kann.
Warum?
Eingehende Daten könnten doch digital verarbeitet werden.
Meiner Meinung nach müsste ein digitales Software-Modell dazu in der
Lage sein,eingehende UART Nachrichten zu verarbeiten.
Wenn ich zum Beispiel den seriellen Port eines Mikrocontrollers benutze, um meine Modelleisenbahn zu steuern, dann müsste dieses "digitale Software-Modell" die ganze Modelleisenbahn simulieren. Technisch ist das machbar, doch der Simulator vom AVR Studio bringt diese Funktion nicht ab Werk mit. Bevor ich hunderte Stunden in die Entwicklung von so einem Modell stecke, Debugge ich mein Programm lieber direkt in der echten Hardware.
