Hi,
ich möchte gern folgendes Beispielprogramm im AVR Studio Simulator
betrachten, um mehr Einblicke zu bekommen und den Simulator später für
eigene Programme zu nutzen. Da Timer und Interrupt benutzt werden ist
meine Frage a, geht das überhaupt und wenn wie.
Ich möchte gern die Änderungen im PORTD0 und in der Variablen "flag"
betrachten.
1
#include<avr/io.h>
2
#include<avr/interrupt.h>
3
4
#ifndef F_CPU
5
#define F_CPU 1000000UL // intern 1MHz
6
#endif
7
volatileunsignedintflag;
8
9
ISR(TIMER1_OVF_vect)
10
{
11
flag=1;
12
}
13
14
intmain(void)
15
{
16
DDRD=0xFF;
17
PORTD&=~(1<<DD0);//Led aus
18
19
TCCR0B|=(1<<CS00)|(1<<CS02);//Teiler /1024
20
TIMSK0|=(1<<TOIE0);
21
// Interrupts freigeben
22
sei();
23
24
while(1)
25
{
26
if(flag==1)
27
{// Neuer Timerzyklus ?
28
flag=0;
29
PORTD^=(1<<PD0);// LED toggeln
30
}
31
}
32
}
Läuft das Programm im Simulator komplett in Endlosschleife und wie ist
es mit dem Timing, entspricht das in etwa der realen Geschwindigkeit wie
es auf dem Mikrocontroller liefe?
Gibt es irgendwo eine gute und ausführliche Beschreibung über das
Debuggen und simulieren? Deutsches Tutorial wäre Klasse.
Danke
Hans-Peter Dahl schrieb:> Läuft das Programm im Simulator komplett in Endlosschleife und wie ist> es mit dem Timing, entspricht das in etwa der realen Geschwindigkeit wie> es auf dem Mikrocontroller liefe?
Nein. Dein Simulator hat ja auch keine "Pins" wo du irgendwas
anschließen könntest. Es gibt aber einen Zähler, der die vergangenen
Taktzyklen mitzählt, so dass du dann ganz einfach sehen kannst, wie viel
Simulationszeit gerade vergangen ist.
Lothar Miller schrieb:> Hans-Peter Dahl schrieb:>> Läuft das Programm im Simulator komplett in Endlosschleife und wie ist>> es mit dem Timing, entspricht das in etwa der realen Geschwindigkeit wie>> es auf dem Mikrocontroller liefe?> Nein. Dein Simulator hat ja auch keine "Pins" wo du irgendwas> anschließen könntest. Es gibt aber einen Zähler, der die vergangenen> Taktzyklen mitzählt, so dass du dann ganz einfach sehen kannst, wie viel> Simulationszeit gerade vergangen ist.
Hi Lothar,
ok, müsste ich dann nicht nach einer gewissen Zeit mal eine Änderung in
der Watchlist von "flag" sehen oder eine Änderung im Datenport PD0 und
wo sehe ich die abgelaufenen Taktzyklen?
Gruß Pit
P.S. Nachdem ich auf den grünen Pfeil (Start Debugging) gedrückt habe
scheint nichts zu passieren, unten steht allerdings "running" ???
Hans-Peter Dahl schrieb:> P.S. Nachdem ich auf den grünen Pfeil (Start Debugging) gedrückt habe> scheint nichts zu passieren, unten steht allerdings "running" ???
Er arbeite mit Vollgas dein Programm ab.
> ok, müsste ich dann nicht nach einer gewissen Zeit mal eine Änderung in> der Watchlist von "flag" sehen
Das siehst du (wie im Debugger) nur, wenn du an einem Breakpoint
anhältst.
> oder eine Änderung im Datenport PD0
Das siehst du (wie im Debugger) nur, wenn du an einem Breakpoint
anhältst.
Es gibt keine "Echtzeit-Darstellung" vo Ports oder eine
"Echtzeit-Eingriffsmöglichkeit" über Pins.
> und wo sehe ich die abgelaufenen Taktzyklen?
Die Stopwatch im Prozessor Status Fenster.
http://www.schniko.at/index.php/de/avr-meets-me/90-simulation-mit-einem-timer-und-overflow-interrupt-deutsch
Lothar Miller schrieb:> Hans-Peter Dahl schrieb:>> P.S. Nachdem ich auf den grünen Pfeil (Start Debugging) gedrückt habe>> scheint nichts zu passieren, unten steht allerdings "running" ???> Er arbeite mit Vollgas dein Programm ab.>>> ok, müsste ich dann nicht nach einer gewissen Zeit mal eine Änderung in>> der Watchlist von "flag" sehen> Das siehst du (wie im Debugger) nur, wenn du an einem Breakpoint> anhältst.>>> oder eine Änderung im Datenport PD0> Das siehst du (wie im Debugger) nur, wenn du an einem Breakpoint> anhältst.>> Es gibt keine "Echtzeit-Darstellung" vo Ports oder eine> "Echtzeit-Eingriffsmöglichkeit" über Pins.>>> und wo sehe ich die abgelaufenen Taktzyklen?> Die Stopwatch im Prozessor Status Fenster.> http://www.schniko.at/index.php/de/avr-meets-me/90-simulation-mit-einem-timer-und-overflow-interrupt-deutsch
Hi Lothar,
d.h. wenn der Debugger durchläuft sehe ich keine Veränderung der Ports
oder des Taktzyklenzählers, nur wenn ich den zwischendurch anhalten
würde?
D.h. dann ja aber auch ich kann gar nicht sehen ob der Timer und
Interrupt funktioniert? Richtig?
Gruß Pit
Hans-Peter Dahl schrieb:> D.h. dann ja aber auch ich kann gar nicht sehen ob der Timer und> Interrupt funktioniert? Richtig?
dafür setzt man einfach einen Breakpoint. dann hält er an diese Stelle
an.
Peter II schrieb:> Hans-Peter Dahl schrieb:>> D.h. dann ja aber auch ich kann gar nicht sehen ob der Timer und>> Interrupt funktioniert? Richtig?>> dafür setzt man einfach einen Breakpoint. dann hält er an diese Stelle> an.
Hallo Peter,
dann müsste das Debugging ja anhalten, wenn ich einen Breakpunkt hinter
das Toggeln von PORTD0 setze, da der Punkt mit 0 inititialisiert wird,
sollte der Status sich ja beim ersten Timeroverflow ändern,
1000000/1024/255 also etwa nach 261ms oder? Das Programm läuft aber
durch?
Gruß Pit
Peter II schrieb:> dafür setzt man einfach einen Breakpoint. dann hält er an diese Stelle> an.
Der Simulator hat noch mehr Schaltflächen... Einzelschritt, Autostep,...
Hans-Peter Dahl schrieb:> Das Programm läuft aber> durch?
hast du auch lange genug gewartet? Bei den CPU Daten steht auch die
vergangen Zeit. du kannst dir auch die Werte vom Timer anschauen - oder
sogar manipulieren wenn du nicht so lange warten willst.
260ms können durchaus mal 1min dauern, je nach CPU.
Peter II schrieb:> Hans-Peter Dahl schrieb:>> Das Programm läuft aber>> durch?>> hast du auch lange genug gewartet? Bei den CPU Daten steht auch die> vergangen Zeit. du kannst dir auch die Werte vom Timer anschauen - oder> sogar manipulieren wenn du nicht so lange warten willst.>> 260ms können durchaus mal 1min dauern, je nach CPU.
Hallo Peter, bin nun zu Hause und kann in Ruhe testen.
Das mit dem Einzelschritt etc. habe ich gesehen. Aber entweder mache ich
noch was falsch, oder der Simulator spinnt.
Ich habe jetzt mal einen Breakpunkt vor Sei(); gesetzt. Müsste der
Debugger dann nicht dort anhalten, nachdem ich "Start Debugging and
Break" ausgeführt habe? Bei mir bleibt der aber mit dem gelben Pfeil vor
der ersten Zeile im Hauptprogramm stehen, so, als ob ich Einzelschritt
machen würde.
Drück ich dann auf Continue, läuft er wieder endlos. Was mach ich falsch
?
Gruß Pit
Lothar Miller schrieb:> Hans-Peter Dahl schrieb:>> P.S. Nachdem ich auf den grünen Pfeil (Start Debugging) gedrückt habe>> scheint nichts zu passieren, unten steht allerdings "running" ???> Er arbeite mit Vollgas dein Programm ab.>>> ok, müsste ich dann nicht nach einer gewissen Zeit mal eine Änderung in>> der Watchlist von "flag" sehen> Das siehst du (wie im Debugger) nur, wenn du an einem Breakpoint> anhältst.>>> oder eine Änderung im Datenport PD0> Das siehst du (wie im Debugger) nur, wenn du an einem Breakpoint> anhältst.>> Es gibt keine "Echtzeit-Darstellung" vo Ports oder eine> "Echtzeit-Eingriffsmöglichkeit" über Pins.>>> und wo sehe ich die abgelaufenen Taktzyklen?> Die Stopwatch im Prozessor Status Fenster.> http://www.schniko.at/index.php/de/avr-meets-me/90-simulation-mit-einem-timer-und-overflow-interrupt-deutsch
Moin Lothar,
also ich habe gestern noch einiges getestet. Wenn ich das richtig
verstanden habe ist es so, dass beim Debugging ohne Breakpoint das
Programm einfach durchläuft, ohne das man Änderungen an den Ports etc.
sieht. Also kein Live Viewing der Ports. Richtig?
Hält man den Lauf per Pause an, sollte man die aktuellen Werte am Port,
Timer, Counte, Stoppuhr etc. sehen können. Richtig?
Startet man das Debugging mit Breakpoint, sollte der Lauf am Breakpoint
anhalten. Richtig?
Warum hält der Debugger dann nicht an, wenn ich z.B. vor dem sei();
einen setze oder in der if-Schleife einen setze?
Warum stoppt der Debugger in der ersten Programmzeile in main, wenn ich
Debugging mit Breakpoint anwähle? Sollte er dann nicht bis zum
Breakpoint durchlaufen?
Müsste ich nicht die geänderten Timereinstellungen sehen, wenn ich den
freien Lauf anhalte? Der Timer wird ja gleich am Anfang gesetzt, diese
Änderungen müssten ja beim Anhalten mit Pause sichtbar sein. Richtig?
Was mach ich falsch?
Und als Letztes, wo ist der Unterschied zwischen dem Simulator und
Debugger?
Wäre toll, wenn Du mich aufklären könntest.
Gruß Pit
Hans-Peter Dahl schrieb:> Warum hält der Debugger dann nicht an, wenn ich z.B. vor dem sei();> einen setze oder in der if-Schleife einen setze?
Vielleicht, weil es keine 'if-Schleife' gibt... ;-(
Für welchen AVR hast du das Programm übersetzt und welcher ist im
Simulator eingestellt?
Ralf G. schrieb:> Für welchen AVR hast du das Programm übersetzt und welcher ist im> Simulator eingestellt?
Beides für den Atmega88P,
Ralf G. schrieb:> Vielleicht, weil es keine 'if-Schleife' gibt... ;-(
1
while(1)
2
{
3
if(flag==1)
4
{// Neuer Timerzyklus ?
5
flag=0;
6
PORTD^=(1<<PD0);// LED toggeln
7
}
was ist mit diesem if???, Breakpoint vor dem PORTD !
Gruß Pit
Hallo
Start Debuggung and Brake Initialisiert den Prozessor und hält am 1.
Statement an.
Du solltest schon wissen, wann der Simulator läuft und wann nicht.
Gruß,
Michael
Michael Appelt schrieb:> Hallo>> Start Debuggung and Brake Initialisiert den Prozessor und hält am 1.> Statement an.>> Du solltest schon wissen, wann der Simulator läuft und wann nicht.>> Gruß,> Michael
Hallo Michael,
wenn Du alles gelesen hast, solltest Du wissen, das ich den Thread
aufgemacht habe weil ich das eben nicht weiss. Mein Anliegen ist ja
genau das, das mir jemand mal erklärt wie das genau läuft, oder mir
einen Tipp gibt wie und wo man das evtl. mal nachlesen kann.
Wo liegt nun der Unterschied zwischen Simulator/Debugger und wie starte
ich den Debugger/Simulator, das er von Anfang des Programms bis zum
Breakpoint automatisch durchläuft.
Gruß Pit
Hans-Peter Dahl schrieb:> volatile unsigned int flag;
Mach da mal ein 'uint8_t' draus, dann hast du auch keine Problem mit
atomaren Zugriffen in der Hauptschleife. Wegen der Struktur deines
Programmes sollte es hier damit keine Probleme geben, aber es ist
hilfreich, es im Hinterkopf zu behalten.
Und du hast zwar eine ISR für Timer 1 gebaut, aber willst eigentlich
eine für Timer 0:
> ISR(TIMER1_OVF_vect)> {> flag=1;> }
sollte also besser
1
ISR(TIMER0_OVF_vect){
heissen. Dann klappts auch in meinem alten AVR Studio 4, wenn man als
Device z.B. den Mega168 benutzt. Du kannst dann z.B. einen Breakpoint in
die ISR setzen und siehst schön, wieviel Zeit zwischen den Ticks
vergeht.
Matthias Sch. schrieb:> Hans-Peter Dahl schrieb:>> volatile unsigned int flag;>> Mach da mal ein 'uint8_t' draus, dann hast du auch keine Problem mit> atomaren Zugriffen in der Hauptschleife.>> Und du hast zwar eine ISR für Timer 1 gebaut, aber willst eigentlich> eine für Timer 0:>>> ISR(TIMER1_OVF_vect)>> {>> flag=1;>> }> sollte also besser>
1
>ISR(TIMER0_OVF_vect){
2
>
> heissen. Dann klappts auch in meinem alten AVR Studio 4, wenn man als> Device z.B. den Mega168 benutzt. Du kannst dann z.B. einen Breakpoint in> die ISR setzen und siehst schön, wieviel Zeit zwischen den Ticks> vergeht.
Matthias, mein Retter,
danke für diesen entscheidenden Tipp, logisch ist der Timer falsch
initialisiert, nun haben so viele drauf geschaut und keiner hats
gesehen.
Nun kann ich auch sehen, das der Timer läuft und der Interrupt auch
ausgeführt wird. Blöder Fehler, vielen Dank.
das war der entscheidende Hinweis. Trotzdem würde mich noch mal
interessieren, wie dieser Debugger /Simulator richtig bedient wird und
wie man das mit den Breakpoints richtig hinbekommt.
Bin nun aber entschieden weiter, danke
Gruß Pit
Hans-Peter Dahl schrieb:> Trotzdem würde mich noch mal> interessieren, wie dieser Debugger /Simulator richtig bedient wird und> wie man das mit den Breakpoints richtig hinbekommt.
Hmm, eigentlich gibts da nicht so viel zu beachten, ausser das bei C
wegen der Optimierung oft lustige Programmsprünge passieren. Für den
Simulator ist es ab und zu besser - wenn auch fern der Realität - die
Optimierung mal auszuschalten, vor allem wenn man kniffelige
Struktogramme überprüfen will.
Du hast dann die Option, Einzelschritte mit F10 und F11 (Studio 4)
auszuführen, wobei 'StepInto' dir die Abarbeitung der Unterprogramme mit
anzeigt, während 'StepOver' diese zwar abarbeitet, aber nicht anzeigt.
Wenn du eine (globale) Variable beobachten willst, bietet sich das
'Watch' Fenster an.
Matthias Sch. schrieb:> Hans-Peter Dahl schrieb:>> Trotzdem würde mich noch mal>> interessieren, wie dieser Debugger /Simulator richtig bedient wird und>> wie man das mit den Breakpoints richtig hinbekommt.>> Hmm, eigentlich gibts da nicht so viel zu beachten, ausser das bei C> wegen der Optimierung oft lustige Programmsprünge passieren. Für den> Simulator ist es ab und zu besser - wenn auch fern der Realität - die> Optimierung mal auszuschalten, vor allem wenn man kniffelige> Struktogramme überprüfen will.>> Du hast dann die Option, Einzelschritte mit F10 und F11 (Studio 4)> auszuführen, wobei 'StepInto' dir die Abarbeitung der Unterprogramme mit> anzeigt, während 'StepOver' diese zwar abarbeitet, aber nicht anzeigt.> Wenn du eine (globale) Variable beobachten willst, bietet sich das> 'Watch' Fenster an.
Hi Matthias,
hab mir das Programm nun mal so geändert, das in der ISR das flag
hochgezählt wird. Dann kann ich im Einzelschrittmodus auch wirklich
sehen, das die ISR ausgeführt wird und das flag hochgezählt wird.
Langsam kommt Licht ins Dunkel.
Habe es nun auch hinbekommen, das die Abarbeitung an einem Breakpoint
anhält. Man arbeitet sich vor.
Das manchmal seltsame Sprünge auftreten, habe ich auch schon bemerkt.
Guter Tipp mit dem Abschalten der Optimierung.
Vielen Dank
Gruß Pit