Simulator und Timer

[Hans-Peter D. (pitdahl)]

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.

#include <avr/io.h>
#include <avr/interrupt.h>

#ifndef F_CPU
#define F_CPU 1000000UL      // intern 1MHz
#endif
volatile unsigned int flag;

 ISR(TIMER1_OVF_vect)
 {
   flag=1; 
 }

int main(void)
{
     DDRD = 0xFF;
  PORTD &= ~ (1<<DD0); //Led aus
  
  TCCR0B |= (1<<CS00) | (1<<CS02); //Teiler /1024
  TIMSK0 |= (1<<TOIE0);
  // Interrupts freigeben
  sei();
  
  while(1)
    {
     if (flag == 1) 
   { // Neuer Timerzyklus ?
       flag = 0;
       PORTD ^= (1 << PD0);    // LED toggeln
   }
    }
}

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Hans-Peter D. (pitdahl)]

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" ???

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

[Hans-Peter D. (pitdahl)]

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

[Peter II (Gast)]

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.

[Hans-Peter D. (pitdahl)]

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

[Ralf G. (ralg)]

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,...

[Peter II (Gast)]

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.

[pit (Gast)]

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

[Hans-Peter D. (pitdahl)]

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

[Ralf G. (ralg)]

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?

[Hans-Peter D. (pitdahl)]

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... ;-(

  while(1)
    {
     if (flag == 1) 
   { // Neuer Timerzyklus ?
       flag = 0;
       PORTD ^= (1 << PD0);    // LED toggeln
   }

was ist mit diesem if???, Breakpoint vor dem PORTD !
Gruß Pit

[Michael A. (micha54)]

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

[Hans-Peter D. (pitdahl)]

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

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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

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.

[Hans-Peter D. (pitdahl)]

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
>

> 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, 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

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Hans-Peter D. (pitdahl)]

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