[AVR Studio 5] einzelschritt debugging erzwingen

[Dshing S. (dshing)]

Hallo,
ich wollte gerade raus finden wie lange (Zeit oder Zyklen) mein µC 
braucht um einen bestimmten Programmabschnitt zu durchlaufen.
Ich dachte mir, mit F11 in Einzelschritten debuggen und im Processorview 
schauen wie viele Zyklen er für den abschnitt braucht.

Das Problem ist, dass am Ende des Abschnittes eine "warte bis" while 
kommt. Nun springt das AVR studio dann immer automatisch auf das 
kontinuierliche debuggen um.

Meine Frage, kann man das irgendwie ausschalten? Ich hab schon versucht 
ein Brakepoint zusetzen, oder nur bis zum "Curser debuggen" funktioniert 
aber nicht, vielleicht mache ich es auch nicht richtig.

Könnt ihr mir helfen?

Grüße
Dshing

[Karl H. (kbuchegg)]

Es kann natürlich sein, dass dir der Optimizer da einen Strich durch die 
Rechnung macht und Anweisungen umgestellt hat. Da es dann diese 
Anweisungen so nicht mehr gibt, kannst du auch keinen Breakpoint darauf 
setzen. Dann musst du dir eben eine Anweisung dahinter suchen, auf die 
du wieder einen BP setzen kannst. Oder aber du schaltest auf 
Assembleransicht um und suchst dir dort einen Punkt an dem du einen 
Breakpoint setzt.

Was immer funktionieren müsste: Den betreffenden Codeabschnitt in eine 
Funktion auslagern und jeweils am Anfang bzw. Ende der Funktion einen 
Breakpoint um die Zyklenzahl abzulesen. Das ist dann zwar nicht mehr 
exakt das gleiche Programm, so wie es dann auch im Endeffekt laufen 
wird, aber normalerweise nahe genug drann.

Aber wozu brauchst du überhaupt die exakte Zyklenzahl? Die ist doch 
normalerweise ziemlich uninteressant. Es gibt natürlich 
Aufgabenstellungen, bei denen sie wichtig ist, wie zb Erzeugen eines 
Videosignals, aber da gehts sowieso nicht ohne das Studium des 
Assemblerprogramms welches der Compiler erzeugt hat. Im Regelfall ist es 
herzlich egal ob da irgendwo mal 5 oder 10 Zyklen mehr anfallen oder 
nicht. Exakte zyklengenaue regelmässige Timings erzeugt man nicht mit 
Warteschleifen oder dergleichen sondern mit einem Timer im CTC Modus. 
Und da ist es dann wurscht, ob in der Hauptschleife mal ein paar Zyklen 
zu viel anfallen oder nicht.

[Dshing S. (dshing)]

Hi,
danke erst mal für die Antwort!
Ich will zwei µC mit einander synchronisieren, dazu setzt einer der 
beiden ein Interrupt bei dem anderen und dann soll der Timer auf 0 
gesetzt werden.
Die Frage ist jetzt wie viel Zeit vergeht, von dem setzen des 
Ausgangspins des einen µC bis der Timer auf 0 ist bei dem anderen.
Die konkrete Stelle:

ISR( INT1_vect)
{
  while ( !(PIND & (1 << PD0)) );            
    TCNT1=0;
...

Davon ausgehend, das der PD0 gesetzt ist, würde ich 10 Zyklen schätzen, 
die das ganze braucht. Klingt das realistisch?

Ich glaub ich werde langsam mal anfangen mir Assembler bei zubringen, 
das scheint für µC wirklich die bessere Sprache zu sein.

[Karl H. (kbuchegg)]

Dshing Sung schrieb:


>

> ISR( INT1_vect)
> {
>   while ( !(PIND & (1 << PD0)) );
>     TCNT1=0;
> ...
>

Ist das so gedacht, dass der eine µC erst mal mit dem Interrupt den 
anderen µC 'in Lauerstellung' versetzt, ehe er dann dem anderen mittels 
einer Flanke an PD0 den genauen Zeitpunkt vorgibt?

Oder ist PD0 der Interrupt Eingang deines ungenannten µC?

> Davon ausgehend, das der PD0 gesetzt ist, würde ich 10 Zyklen schätzen,
> die das ganze braucht. Klingt das realistisch?

Kommt jetzt drauf an, wie die Synchronisierung genau erfolgt: Eine oder 
Zwei Leitungen von einem µC zum anderen. Oder ist das so gedacht, dass 
der eine erst mal mit einer fallenden Flanken dem anderen ein 'Achtung' 
zuruft und mit der steigenden Flanke wird dann synchronisiert?

Die while Schleife an sich: das sind 3 Zyklen. Das wird der Compiler zu 
einem sbis (bzw. sbic) mit einem nachfolgendem rjmp für die Schleife 
übersetzen und wenn der Pin gesetzt ist, dann gehts halt aus der 
Schleife raus.

Die genaue Taktzahl vom Setzen eines Interrupts, bis dann zum ersten mal 
dein C-Code die Kontrolle kriegt, das sind mehr Zyklen. Da ist zum einen 
die Frage, welcher Befehl gerade duch den Interrupt unterbrochen wird 
(der Befehl wird ja noch fertig abgearbeitet), dann erfolgt ein Sprung 
in die ISR, wo vom Compiler erst mal ein paar Register gesichert werden 
(welche und wieviele hängt auch davon ab, was genau in der ISR 
passiert). 10 Zyklen ... könnte hinkommen. Kann aber auch schon mal mehr 
sein.

[Dshing S. (dshing)]

Ja das zwei separate Kanäle, wie du sagst einmal um ihn in Lauerstellung 
zu kriegen und dann um los zulegen.
Ja daran hab ich gar nicht gedacht, dass ja der Befehl, aus dem in die 
ISR gesprungen wird unterschiedlich lang sein kann.
Dann müsste ich die Sync. auf jeden Fall mit dem PD0 einleiten, dann 
wären die 3 Zyklen auch noch eine verkraftbare Toleranz.

Gut, dann bedanke ich mich für die Hilfe und werde versuchen das so hin 
zu bekommen :)