Unterschiedliche Latenzzeiten [ recht_3.c ]

Postby laurin » Fri Nov 16, 2012 12:00 am

Hallo,

wenn ich die Reihenfolge des Codes ändere so entstehen unterschiedliche Latenzzeiten:

Reihenfolge FOR->WHILE

Ergebnis Pegeldauer H = 140us, L = 140us

Reihenfolge WHILE->FOR

Ergebnis Pegeldauer H ~ 160us, L ~ 160us (keine 100% feststehenden Flanken)

[Sorry hab den Code rausgenommen wird nicht richtig angezeigt]

Wie ist es möglich dass die Reihenfolge von FOR/WHILE in der Abarbeitung des Codes solche Latenzzeiten verursacht? Und muss so ein Phänomen beim coden berücksichtigt werden? Vielen Dank.

Gruß
L.
Attachments

[The extension bmp has been deactivated and can no longer be displayed.]

[The extension bmp has been deactivated and can no longer be displayed.]

rechteck-einst.c
(6.52 KiB) Downloaded 49 times
laurin
 
Posts: 3
Joined: Fri Jan 03, 2014 2:14 pm

Postby rai » Fri Nov 16, 2012 12:00 am

Hi,

ohne Code ist das sehr schwer zu beantworten, ich kann jetzt natürlich nur raten.

Ich würde jetzt einfach mal auf die unterschiedlichen Schleifen als Grund tippen:

while(Bedingung) --> Prüft nur, ob Bedinung wahr ist, macht dann sofort weiter

for(Startwert, Bedinung, Befel(Erhöhung))
Muss sowohl die Bedinung prüfen, als auch die Erhöhungsaddition ausführen (meist i++).
Mehr Aktionen nötig, also mehr Zeit.


Viele Grüße

Rai
rai
 
Posts: 45
Joined: Fri Jan 03, 2014 2:12 pm

Postby laurin » Fri Nov 16, 2012 12:00 am

Hi Rai,

das C-File kannst Du unter den Oszi-Bildern einsehen. Mein C-File heißt rechteck_einst.c, die Musterlösung recht_3.c ist dort auch enthalten. Was Du geschrieben hast ist mir klar, aber ich meine wenn Du die Reihenfolge im Code von FOR - WHILE auf WHILE - FOR änderst - einfach die Zeilen tauschen, sorry war nicht eindeutig beschrieben. Vielleicht macht die Frage keinen Sinn, aber oftmals lernt man viel über die Arbeitsweise eines System über Programmierfehler oder Kopfhörer-Fehler, danke.

L.
laurin
 
Posts: 3
Joined: Fri Jan 03, 2014 2:14 pm

Postby rai » Fri Nov 16, 2012 12:00 am

Ah, das hatte ich übersehen.

Das Datenblatt des AT89C51CC03 sagt, dass eine typische AD Wandlung 16µs dauert.

Wenn wir uns jetzt deinen "schnellen" Code anschauen:
for(i=0; i<=me; i++) P1_0 = 0;
while((ADCON & 0x10) == 0); //warten bis Messung fertig
Hier zählt jetzt zuerst die For schleife die gewünschte Zeitdauer herunter (Ausgang bereits gesetzt), währendessen läuft im !Hintergrund! die AD Wandlung. d.h. die Whileschleife sieht schon beim ersten Durchlauf "Wandlung ist fertig"

Beim "langsamen" Code:
while((ADCON & 0x10) == 0); //warten bis Messung fertig
for(i=0; i<=me; i++) P1_0 = 0;
Hier wartet der µC ersteinmal gemütlich, bis die Wandlung abgeschlossen ist (Ausgang noch im alten Zustand) bevor er sich dann dazu bequemt die Zeit herunter zu zählen und den Ausgang umzuschmeißen.

Folgende Sachen sind mir noch aufgefallen:
ADCON = 0x2f; //Start der Messung
ADCON &= 0xff;
Zeile 1: Zwingt das ADCON auf 0x2f
Zeile 2: Macht eine UND-Verknüpfung zwischen dem aktuellen Wert (0x2f) und 0xff
Was im Endergebnis wieder 0x2f ergibt. Zeile 2 ist somit unnötig.
Binär:
0010 1111
& 1111 1111
----------------
0010 1111



Genau dasselbe machst du auch bei:
ADCON = 0x2e; //Start der Messung
ADCON &= 0xfe;

Viele Grüße

Rai


Edit: Die Unsauberen Flanken kommen dann vermutlich daher, weil die 16µs nur der typische Wert ist und durchaus schwanken kann
rai
 
Posts: 45
Joined: Fri Jan 03, 2014 2:12 pm

Postby laurin » Fri Nov 16, 2012 12:00 am

Hey Rai,

... aaahhhh na klar! Danke für Deine Antwort! Die Doppel-Zuweisung ist natürlich Unfug, sorry.

Gruß
L.
laurin
 
Posts: 3
Joined: Fri Jan 03, 2014 2:14 pm


Return to Mikrocontroller-Fernlehrgang (TFH)

Who is online

Users browsing this forum: No registered users and 2 guests