mikrocontroller.net

Forum: Compiler & IDEs Ungleichmäßiger Takt mit ISR


Autor: Aurel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
irgendwie komme ich nicht hinter folgendes Problem:

Randbedingungen: ATMEGA8 im STK500 Board, ISP Programmierung mit Studio
4 und WinAVR auf Win XP Rechner. Neuer Controller eingestellt auf
internen Oszylator mit 8MHz (CKSEL=0100 SUT=10). Verwendetes Programm
wie angehängt. Code optimierung -00.
Für eine PID Reglung möchte ich eine konstante Zykluszeit haben die
unabhänig von der Laufzeit des Programms ist. Zumindestens solange die
Ausführung des Programms kürzer als die Zykluszeit ist. Da es zu
Problemen gekommen ist habe ich alles bis auf die Erzeugung der
Zykluszeit reduziert und das ist das angehängte Programm:
Nach der Initialisierung vom Timer0 und Pin PB1 als Ausgang gehts in
die Endlosschleife. Hier wird gewartet bis der Timer0 320 mal
durchgezählt hat. Die ISR zählt dazu bei jedem Timer 0-Durgang hoch.
Ist 320 erreicht gibt es einen Impuls (Spike) am PB1 damit ich mit dem
Ossy nachmessen kann. Und hier ist das Problem:

1.) Der Takt ist unregelmäßig und variiert zwischen 10mS und 8mS. Warum
und was kann ich dagegen tun?

2.) Um eine Zykluszeit von 10mS zu erreichen musste ich den Timer Takt
ohne prescaling lediglich durch 320 teilen. Ich habe aber eine
Oszylatorfrequenz von 8MHz, die geteilt durch 320 entspricht 40µS. Wo
wird die Frequenz verringert und wo kann man das nachlesen?

Mit freundlichen Gruß

Aurel

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 2.) Um eine Zykluszeit von 10mS zu erreichen musste ich den Timer
> Takt ohne prescaling lediglich durch 320 teilen. Ich habe aber
> eine Oszylatorfrequenz von 8MHz, die geteilt durch 320 entspricht
> 40µS. Wo wird die Frequenz verringert und wo kann man das
> nachlesen?

Timer0 ist ein 8bit-Timer, zählt also pro 256 Schritte bis zum
Überlauf. Alle 320 Überläufe wird der Impuls erzeugt.

8 Mhz / 256 = 31,25 kHz
31,25 kHz / 320 = 97,65 Hz
1 / 97,65 Hz = 10,24 ms

Mal abgesehen davon, daß Wartschleifen in C bäh sind, sehe ich kein
Problem im Code.

Autor: Aurel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja logisch, der Timer selbst Teilt ja schon mit 256 und nicht mit 1.
Danke, jetzt ist das erstes Brett von Kopf weg!
Warteschleifen in C lieber mit _delay? Hier dient es lediglich zu
testzwecken damit ich den Impuls auf dem Ossy sehen kann.

Prima, dann muss nur noch einer das mit dem unregelmäßigen Takt
herausbekommen. Dann kann ich wieder weiter.

Gruß

Aurel

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warteschleifen in C lieber mit _delay?
Nee, das ist noch... wie heißt die Steigerung von "bäh"? In Deinem
Fall, wenn das Programm in der Zwischenzeit eh nichts anderes zu tun
hat als warten, ist das so schon OK (jedenfalls besser als mit
_delay_xx()...).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö, sinnvoller wäre es, beim Erreichen von 319 den Pin auf
high zu ziehen, dann bei 320 den Pin auf low und die
Zählvariable rücksetzen.  Der Impuls ist dann breiter (ist
sowieso besser für das Oszillofon), aber er braucht keine
CPU-Zeit mehr für seine Erzeugung, und man kann die CPU den
Rest der Zeit auch getrost schlafen legen.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine Vermutung:
Der IR tritt auf zwischen dem Vergleich von High- und Low-Byte der
16-Bit-Variable ZeitCount. Du solltest während dem Vergleich die IR
sperren.

uint8_t Zeitcount_kleiner_320(void){
  cli();
  if (ZeitCount < 320){
    sei();
    return(1);
  }
  else{
    sei();
    return(0);
  }
}

while(1){
  while (ZeitCount_kleiner_320 );  // ca. 10mS Takt
  ZeitCount = 0;
  PORTB &= ~(1<<PB1);    // Spike an
  for (i=0;i<50;i++);    // Spike Breite
  PORTB |= (1<<PB1);    // Spike aus
}

Viel Spass, Stefan

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Warteschleifen in C lieber mit _delay?
> Nee, das ist noch... wie heißt die Steigerung von "bäh"?

Wie bist du auf den Blödsinn gekommen?

> In Deinem Fall, wenn das Programm in der Zwischenzeit eh nichts
> anderes zu tun hat als warten, ist das so schon OK (jedenfalls
> besser als mit _delay_xx()...).

Warum sollte was handgeschraubtes besser sein als die extra dafür
vorgesehenen Bibliotheksfunktionen? Die _delay-Funktionen haben den
Vorteil, nicht einfach vom Compiler wegoptimiert zu werden, wenn man
Optimierungen einschaltet. Abgesehen davon produzieren sie eine
nachvollziehbare Wartezeit, weil sie in Assembler implementiert sind
und daher eine bekannte Zahl an Taktzyklen pro Durchlauf brauchen.

Wie Jörg schon schreibt, ist es meistens besser, gar nicht zu warten,
sondern sowas vom Timer erledigen zu lassen. Wenn man dann aber doch
warten will, dann doch wenigstens mit den delay-Funktionen der
Bibliothek.

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Neuer Controller eingestellt auf internen Oszylator mit 8MHz
...
> 1.) Der Takt ist unregelmäßig und variiert zwischen 10mS und 8mS.
> Warum und was kann ich dagegen tun?

das sind ca 20%. Das würde ich dem internen Oszillator durchaus
zutrauen. Die sind nicht so genau.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf:
Ich meinte damit eigentlich, dass eine Wartezeit mit Timer (wie er es
ja im Prinzip gemacht hat) einer _delay-Routine vorzuziehen ist! Und
ich kenne keinen Compiler, der in der Lage wäre, einen ganzen Timer
wegzuoptimieren...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für dein Impuls hat er aber eine Warteschleife benutzt, und um die ging
es ja. Die Frage war, ob er die durch einen delay-Aufruf ersetzen
soll.

> ich kenne keinen Compiler, der in der Lage wäre, einen ganzen
> Timer wegzuoptimieren...

Naja, in der Lage dazu wäre er schon. Würde er auch normalerweise
machen, wenn nicht die passenden Vorkehrungen getroffen worden wären.
Da die Interrupt-Routinen nie explizit aufgerufen werden, kann er ohne
diese Vorkehrungen auf die Idee kommen, daß sie nicht gebraucht werden
und sie weglassen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> das sind ca 20%. Das würde ich dem internen Oszillator durchaus
> zutrauen.

Keinesfalls, zumindest nicht, solange Vcc nicht gerade aus
ungeglätteten 100 Hz besteht...

Wir benutzen im Lab zu Debugzwecken den RC-Oszillator die ganze
Zeit zum Ansteuern einer RS-232.  Mit einmaliger Kalibrierung
läuft das wenigstens einige Stunden problemlos.

Autor: Aurel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nun habe ich Feierabend und gleich mal eure Vorschläge ausprobiert. Und
es funktioniert! Es scheint so als hat der Interrupt gerade immer die
ZeitCount Abfrage gestört. Man man was für ein Zufall, hätte ich Lotto
gespielt hätte ich auch bestimmt 'ne Milionen gewonnen.
Das modifizierte, funktionierende Programm habe ich beigelegt. Jetzt
gehts übrigens auch mit laufenden Interrupt (-:

Also klasse und vielen Dank an euch, echt ein super Forum hier!

Gruß

Aurel

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man man was für ein Zufall, hätte ich Lotto gespielt hätte ich
> auch bestimmt 'ne Milionen gewonnen.

Nein. Du mußt dir vor Augen halten, daß die while-Schleife im Bereich
von Millionen Mal pro Sekunde durchläuft und sehr kurz ist. Die
Wahrscheinlichkeit, daß der Interrupt genau zwischen den beiden Hälften
der Überprüfung kommt, ist viel höher als du denkst.

Übrigens, der Funktionsname Zeitcount_erreicht ist eher ungünstig
gewählt.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Aurel,

>Man man was für ein Zufall, hätte ich Lotto
>gespielt hätte ich auch bestimmt 'ne Milionen gewonnen.

Ist viel weniger Zufall, als Du denkst.
Für solche Probleme ist es immer sinnvoll, sich mal den Assembler-Code
anzuschauen. Dann wird Dir nämlich klar, dass eine einfache C-Zeile aus
mehreren einzelnen Befehlen besteht:

  while (ZeitCount < 320 );

Dazu muss der Compiler - weil 16-Bit-Variable - zwei Bytes laden und
dann in einer zweistufige Subtraktion die Konstante 320 abziehen:

    753c:  80 91 e2 00   lds  r24, 0x00E2
    7540:  90 91 e3 00   lds  r25, 0x00E3
    7544:  80 54         subi  r24, 0x40  ; 64
    7546:  91 40         sbci  r25, 0x01  ; 1
    7548:  c8 f3         brcs  .-14       ; 0x753c

Dein mc führt also während dem Warten immer nur zyklisch diese 5
Befehle aus - unterbrochen von den IRs, die ZeitCount hochzählen.
Irgendwann wird ZeitCount vom IR von 255 = 00-FF-hex auf 01-00-hex
hochgezählt. In ca. 80% aller Fälle passiert nichts. Tritt aber der IR
zwischen den beiden lds-Befehlen auf, passiert folgendes:

 lds  r24, 0x00E2 <- in ZeitCount steht 00FFh -> FFh wird nach R24
                     geladen

 !!! Interrupt tritt auf -> ZeitCount wird von 00FFh auf 0100h
 !!! incrementiert
 !!! Interrupt wird wieder beendet

 lds  r25, 0x00E3 <- in ZeitCount steht 0100h -> 01h wird nach R25
                     geladen

Jetzt steht im Registerpaar R24/25 also 01FFh (entspricht 511) statt
den eigendlich richtigen 256.
Diese Zeit entspricht auch den gemessenen 8ms.

Viel Spass noch, Stefan

P.S.:
Wenn Du einen Lottotrick mit ähnlicher Gewinnchance kennst - lass es
mich wissen - aber nicht über das Forum hier ;-))

Autor: Aurel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja Danke für die ausführliche Erklärung. Jetzt habe ich das sogar im
Detail verstanden. D.h. wenn ich mit mehr als 8 Bit rum mache muss ich
Aufpassen wenn ein Wert sich "selbständig" verändern kann. Ist ja
nervig, kann da nicht der Compiler aufpassen, woführ bezahle ich den
denn?  (-:

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoppla, wenn Du für gcc etwas bezahlt hast, dann hast Du was falsch
gemacht - nur spenden lasse ich durchgehen ;-)

Viele Grüße, Stefan

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anyway, du willst nicht wirklich, dass der Compiler dir um
jeden 16-bittigen Zugriff einen Interruptschutz herum baut:
das würde saumäßig auf die Performance hauen und wäre in 99,999 %
der Fälle überhaupt nicht notwendig.  Es ist ja nur notwendig,
weil du eine 16-bit-Variable zwischen ISR und der ,Außenwelt'
kommunizieren lässt.

Autor: Aurel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK ich merke schon, da hat man sich ausreichend Gedanken gemacht.
Dann werde ich halt aufpassen.

Aber einen Gedanken habe ich noch. Nur so zum Verständnis, stimmt
folgende Aussage?

cli();
while(ZeitCount < 320);
sei();

 --> geht nicht weil die ISR keine Chance hat ZeitCount zu erhöhen.


while(ZeitCount < 320){
sei();
cli();
}

--> müsste gehen. Allerdings wird CPU Zeit verbraten.
Werden eingetretene IR's nachgeholt wenn man sie z.B. mit sei() wieder
aktiviert?

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Flags, die das Auftreten eines Interrupts zeigen, bleiben solange
stehen, bis entweder dieInterruptroutine angesprungen wird oder du das
Flag (die Flags) löscht. Ausnahme ist der UART Receive Interrupt. Da
wird das Flag nicht durch den Einsprung in die Routine sondern durch
das Lesen des UDR-Registers gelöscht.

MW

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Aurel,

> while(ZeitCount < 320){
> sei();
> cli();
> }

ist theoretisch möglich. Aber bedenke: Du verlässt die while-Schleife
mit IRs gesperrt! Nicht vergessen, danach mit sei() die IR wieder
einzuschalten, sonst läuft Dein restliches Programm ohne IRs.

> Werden eingetretene IR's nachgeholt wenn man sie z.B. mit
> sei() wieder aktiviert?

Ja.
Und Nein. Wenn Du die IRs länger sperrst, können IRs verloren gehen. In
Deinem Beispiel: Wenn die IRs länger als 32us gesperrt sind, geht Dir
ein Timer-Event verloren (der mc merkt, dass der Timer übergelaufen
ist, aber kann nicht mitzählen, dass das schon mehrmals seit dem
Sperren der IR passiert ist).

Viele Grüße, Stefan

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ausnahme ist der UART Receive Interrupt. Da wird das Flag nicht
> durch den Einsprung in die Routine sondern durch das Lesen des
> UDR-Registers gelöscht.

Aber zumindest geht der USART-Interrupt nicht verloren.

Die meisten Interruptbedingungen löschen sich ,,automatisch'', sowie
der passende Interrupthandler aufgerufen wird, oder halt sonst
irgendwie ,,sinnvoll'' wie bei der USART.  Eine prominente Ausnahme
ist das TWI-Interface: hier muss man den Interrupt mit der Hand
löschen, weil das zugleich die nächste Bustransaktion einleitet.

Aber es gibt auch eine Interruptbedingung, die nicht ,,kleben''
bleibt: ein pegelgetriggerter Externinterrupt.  Dort ist der Status
der Leitung zugleich das Interruptflag, und wenn das Signal nur
während einer Interruptsperre aktiv war, aber vor dem Aufheben der
Sperre wieder verschwunden ist, dann wird der Interrupt nicht
ausgelöst.

Hier noch ein anderer Vorschlag:
static inline int getZeitCount(void) // feines Denglisch :)
{
  int tmp;
  cli();
  tmp = ZeitCount;
  sei();
  return tmp;
}
...
  while (getZeitCount() < 320) ...

Autor: Aurel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK jetzt weiß ich aber auch das letzte Detail. Ich glaub ich gehe morgen
mal zu meinem Chef und erzähle ihm das dann gibts betimmt eine
Gehaltserhöhung....
hust Träumen darf man doch.

Gruß und Dank

Aurel

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.