mikrocontroller.net

Forum: Projekte & Code Input Capture Pin (ICP) auslesen ( Frequenz messen)


Autor: Karl Napf (karlnapf)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang ein C-Code um den Input Capture Pin auszulesen, den ich mit 
reichlich Unterstützung aus dem Forum geschrieben habe.
Hab einen Atmega16 mit 4MHz externem Quarz benutzt.
Sicherlich noch optimierungsfähig aber ein Anfang.
Gruss

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau den Code noch mal durch.

Was macht der delay.h da drinnen.

Was ist mit den LCD Funktionen? Die hat nicht
jeder.

Namen wie ic_zp_A sind nicht wirklich aussagekräftig.
Was macht die Variable wirklich?

Selbiges für i. i als Variablenname wird normalerweise
für Dinge mit sehr geringen Scope (also zb eine
for-Schleife benutzt). Als Name für eine globale
Variable ist es aber unbrauchbar.

Über den double da drinnen könnte man auch
noch debattieren.

Auch wäre eine kleine Kommentierung, wie das Teil
funktioniert, worauf es basiert angebracht.


Veröffentlichter Code ist dein Aushängeschild gegenüber
der Welt!

Autor: Karl Napf (karlnapf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab ja dazu geschrieben, dass es sich um einen keinenfalls perfekten 
Code handelt.
Wollte damit nur denjenigen helfen, die ein ähnliches Problem haben und 
einen Einstieg suchen.
Mir persönlich ist es immer lieber wenn ich einen Code vor mir habe der 
nicht perfekt durchprogrammiert ist, dafür übersichtlicher.
Außerdem ist es doch unmöglich was zu schreiben, das man dann 1 zu 1 
übernehmen kann.
Die Variablen und die Kommentierung sind sicherlich verbesserungsfähig.

Und auf meinen Ruf als "großer" Programmierer leg ich nicht so viel Wert 
;-)

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wollte damit nur denjenigen helfen, die ein ähnliches Problem haben und
>einen Einstieg suchen.
>Und auf meinen Ruf als "großer" Programmierer leg ich nicht so viel Wert

Ist aber nicht schön, wenn diejenigen dann in fiese Fallen tappen, weil 
sie den Code einfach übernehmen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wollte damit nur denjenigen helfen, die ein ähnliches Problem haben
> und einen Einstieg suchen.

Da dürfte ich jetzt falsch rübergekommen sein.

Ich honoriere das ja voll und ganz. Ganz im Gegenteil.
Ich finde es gut, wenn du ein Stück Code hast, von dem du
denkst, dass es veröffentlicht werden soll.

Nur solltest du den Code vor der Veröffentlichung etwas
aufräumen. Da finden sich andere dann nämlich viel
schneller zurecht, wenn zb. eine Variable nicht i sondern
FirstEdge oder ErsteFlanke heist.

Nimm es als konstruktive Kritik.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Und damit du nicht sagst der Klugschwätzer hat leicht reden:
So würde ich das abliefern.

Autor: Karl Napf (karlnapf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Freut mich, dass du von dir aus das Ding nochmal überarbeitet hast, so 
kann ich mir jetzt anschauen wie man's richtig macht.
Sieht natürlich schon um einiges professioneller aus.
Bis dann.

Autor: Mister mit Kanister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegen persönlichem Interesse: Bis zu welcher Frequenz kannst Du mit dem 
Code Signale messen? Hast Du das praktisch mal ausprobiert?

Autor: Karl Napf (karlnapf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werd's demnächst mal testen und sag dann Bescheid. Komm nur grad 
nicht dazu.

Autor: Karl Napf (karlnapf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Frequenzmessung:

Das ganze gerät bei ca. 75kHz an seine Grenzen. Dann wird das Display 
nur noch ganz langsam beschrieben und es mischen sich falsche Zahlen mit 
rein.
Je höher die Frequenz wird desto langsamer wird das Display beschrieben. 
Könnte daran liegen, dass dann die Zahlen länger werden und die Zeit 
für's Beschreiben länger wird.
Außer über's Display wüßt ich aber nicht wie ich's sonst testen könnte.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger Brenner wrote:
> Zur Frequenzmessung:
>
> Das ganze gerät bei ca. 75kHz an seine Grenzen. Dann wird das Display
> nur noch ganz langsam beschrieben und es mischen sich falsche Zahlen mit
> rein.
> Je höher die Frequenz wird desto langsamer wird das Display beschrieben.
> Könnte daran liegen, dass dann die Zahlen länger werden und die Zeit
> für's Beschreiben länger wird.

Das denke ich nicht.
Das Problem wird eher sein, dass ab dieser Frequenz schon
so viele Input capture Interrupts generiert werden, dass
der Prozessor praktisch nur noch Capture Interrupts bearbeitet.

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Problem wird eher sein, dass ab dieser Frequenz schon
>so viele Input capture Interrupts generiert werden, dass
>der Prozessor praktisch nur noch Capture Interrupts bearbeitet.

Vorschlag: Den ICP-Interrupt nach der zweiten Flanke (in der ISR) 
sperren und erst nach der Ausgabe auf dem LCD wieder aktivieren.
Vllt musst du vorher noch das ICP-Interrupt Flag zurücksetzen.
2. Vorschlag: 8MHz statt 4

Werner

Autor: Benjamin Ullrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus Miteinander,
Gleich vorneweg ich bin alles andere als ein Profi.
Ich selber benötige eine art Frequenz zu messen, bin also auf den ICP 
gestoßen und hab mal dieses Programm hier ausprobiert.
Nun habe ich ein paar Problemchen bzw ideen:

Ideen:
Bekommt man tatsächlich beim Auslesen des Zählerstandes Probleme mit den 
Interrupts so wie im Manual beschrieben ? also muss man zuerst das SREG 
sichern mit cli() interrupts sperren und dann SREG wiederherstellen?

Sollte man den Overflow nicht bei DisplayUpdate == 1 totstellen da der 
sonst weiterzählt ?

Problem:
der Frequenzbereich der mich interessiert ist von ca 1Hz - 500Hz;
Ich habe noch keinen Quarz und nutze den 1MHz Oszillator bei ca 25° und 
recht genau 5,00V

Wenn ich mit meinem Rechteckgenerator 10kHz - 200Hz gehe bekomme ich 
gute ergebnisse, unter 200Hz bekomme ich irgendwann natürlich den 
Overflow aber Stellenweise Totale aurseißer ( Teilweise nur 95% Fehler) 
je weiter ich mit der Frequenz nach unten gehe desteo mehr unbrauchbare 
Werte habe ich.

Da das Ganze ja eine Periodendauermessung ist und ich bei niedrigen f 
eigentlich mehr Pulse bekomme sollte die Messung doch eigentlich genauer 
werden.
Auch wenn ich mit dem Prescalar so weit Hochgehe dass kein Overflow mehr 
entsteht sind meine Werte trotzdem nur bis 50Hz brauchbar.

Ich hab auch mal an der SV für den Chip nachgemessen, ich habe keinen 
erhöhten Stromverbrauch und die Spannung bricht auch nicht zusammen.

Hat einer eine Idee? (Nutze die die  FreqCount.c mit UART ausgabe statt 
LCD)

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenn mich mit C nicht aus und weis auch nciht wie der FreqCount.c 
funktioniert, aber ich würde im Overflow Interrupt eine Variable 
hochzählen und diese dann mal 256 und danach plus den Zählerwert 
rechnen. Und schon ist das Overflow Problem gelöst.

Autor: Sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>FreqCount.c

wie würde denn ein solcher PIN an einem PIC eingelesen werden???

ich komm mit den Datenblättern nicht zu Potte

Autor: ein Freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo wirklich ein tolles Programm,
hatte ein Paar Probleme mit der Messung über den Capture Betrieb da ich 
die Berechnung in der Interrupt gemacht habe.
Jetzt arbeite ich nach dem hier beschriebenen Prinzip und es 
funktioniert wirklich gut.
Habe aber noch irgendwie leicht Abweichungen. Will sehr genau messen und 
arbeite daher mit 8MHz. Messe zu Testzwecken meinen eigenen Timer0 den 
ich auf genau 1Hz eingestellt habe. Mein Ergebniss liegt aber bei 
1,02Hz.
Bei höheren Frequenzen wird die Abweichung noch größer.

@Hauke Radtki: Ich denke das hier schon nach dem von dir beschriebenen 
Prinzip gearbeitet wird nur das der Timer1 ein 16Bit Timer ist und daher 
nicht mit 256 multipliziert wird sondern mit 65536.

@Karl Napf: In jedemfall erstmal vielen Dank für den Tip. ;-)

Autor: Klaus De lisson (kolisson)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

das ist ja ein recht alter thread. trotzdem habe ihn heute erst gelesen 
und
fand das programm :

> Autor:  Karl heinz Buchegger (kbuchegg) (Moderator)
>Datum: 08.02.2007 22:28
>Dateianhang: FreqCount.c

ganz schön.

als bascom-fan habe ich mal an bascom angepasst und etwas erweitert.

im anhang dann der code

gruss
klaus

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
double Erg = 0.0;

Erg = (NrOverflows * 65536) + EndTime - StartTime;
      sprintf(s,"Erg als Float: %f\r\n",Erg);
    uputs(s);


ausgabe:

Erg als Float : ?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gast schrieb:

> Erg als Float : ?

http://www.mikrocontroller.net/articles/FAQ#Aktivi...

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade dabei, diesen Code zu verwenden. Verstehe aber folgende 
Logik nicht:
Erg = (NrOverflows * 65536) + EndTime - StartTime;

Angenommen der StartTime ist 65000 und EndTimer wäre 100. Es hat 
folglich 1 Overflow stattgefunden.
Rechne ich also:
Erg = (1*65536) + 100 - 65000
    = 65536 + 136
    = 65672

Die vergangene Zeit in Timer Werten ist jedoch nur 136.
Ist daran etwas falsch? Oder wird hier tatsächlich ein Overflow zuviel 
gezählt, der nicht gezählt werden dürfte?

Autor: T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist 100 - 65000 denn +136 ?

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
T. schrieb:
> Ist 100 - 65000 denn +136 ?

Scheinbar nicht...
Könntest du mir das mal erklären, wie dort in dem Beispiel "gerechnet" 
wird?

Autor: T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erm, du hast es behauptet...

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte ich auch so gedacht, aber scheinbar habe ich einen Denkfehler. 
Darum habe ich gebeten, ob du mir die Rechnung mal erklären kannst, 
damit ich es verstehe.
Danke.

Autor: Klaus De lisson (kolisson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
((1*65536)-65000) + 100 = 636


also einmal  von 65000 bis overflow
und dann noch die 100

gruss

Autor: Erik B. (bibabulks)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hab den hier geposteten Code von Karl Napf verwendet, besten Dank 
hierfür erstmal und die Verbesserungen des anderen Karl's, um über das 
IC-PIN eine Frequenzmessung durchzuführen. Habe den Code ein versucht 
ein bißchen zu erweitern und zwar, dass j Messungen durchgeführt werden 
um dann einen Mittelwert gebildet um die Genauigkeit zu erhöhen. Ich 
verwende für die Messaufgabe einen Atmega168 mit 20MHz Taktfrequenz. 
Beim Test des Programmes mit einem Frequenz-Generator erhalte Ich bis 
ca. 2kHz sehr gute Ergebnisse, d.h. dass die ausgegebene Frequenz auf 
dem Display mit 1Hz Genauigkeit übereinstimmt.
Erhöht man die Frequenz bis 5kHz so muss man feststellen, dass Sie bis 
zu 3Hz abweichen kann. Bei 10kHz ist die Auflösug schon so schlecht, 
dass man sich mit einer Auflösung von 10 Hz bis 20 Hz abfinden muss.

Meine Frage: kann mir jemand weiterhelfen den Code zu verbessern, oder 
einen Tip geben, um die Messgenauigkeit zu verbessern? Entweder bei 2kHz 
Auflösung von 0,1Hz oder bei 20kHz Auflösung von 1Hz? Ist das überhaupt 
möglich?

Hintergrund ist Ich möchte Frequenzen bis 150Mhz messen, die über Teiler 
bis in den kHz-Bereich herunter geteilt werden sollen. Teilungsfaktor 
bei 2kHz der Messfrequenz wäre dann nach Adam Ries 75 000 macht bei 
einer Auflösung von 1Hz, wie es bisher ist 75 kHz Gesamtauflösung. Dies 
möchte Ich gern verbessern.

Danke im vorraus

Autor: Erik B. (bibabulks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sry hat's alles bissl verschoben, hat jemand ne idee???

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erg = (overflows*65536) + endtime - starttime;  // allg. Formel

Die Logik dahinter ist nicht ganz richtig. Es kann auch ein 
Timer-overflow stattfinden, ohne dass die Messung selbst 65556 Zyklen 
überschritten hat.

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Logik dahinter ist nicht ganz richtig. Es kann auch ein
>Timer-overflow stattfinden, ohne dass die Messung selbst 65556 Zyklen
>überschritten hat.

Kann das jemand näher ausführen?

Mal eine Frage zur Hardware.

Hab das Ganze mal auf einem Pollinboard versucht (aktive-high) und ein 
alten Rechteckgenerator drangehangen.
Problem ist das sporadisch (für längere Zeit) die Messungen aussetzen, 
sollte man da noch etwas dazwischen schalten?

Autor: Erik B. (bibabulks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein du brauchst eigentlich nicht's mehr dazwischen zu schalten. Einfach 
mit dem Ausgang des Frequenzgenerators an das Capture-PIN und natürlich 
noch die Massen zusammenführen. Eichtig ist, dass dein Frequenzgenerator 
für den Mikrocontroller verarbeitbare Pegel ausgibt. (0-5)V TTL z.B.

Wenn du oben aufgeführtes Messprinzip nimmst, ist irgendwann schluss.
Messprinzip ändern Torzeit gewähren und Impulse zählen.

Autor: Mitleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann muß ich noch irgendwo ein anderes Problem haben,
Pegel 5V stimmt laut Oszi auch ein leichtes hoch und herunterregeln 
bringt nichts.
Evtl. stimmt aber auch im Messaufbau was nicht und ich geh mit über 5V 
in den AVR.
Sollte man da evtl. noch nen Transistor oder gar Schmidt Trigger 
verwenden, so als Sicherheit?
Irgendwann soll das Ding dann mal in eine bestehende Maschiene wandern 
und zur Drehzahl schalten ob die wirklich TTL ausgiebt, ich weiß es 
nicht.
Wie wichtig ist denn auch ein sauberes Rechteck für den Capture-Pin?

Ihr merkt schon das ich langsam verzweifel g versuche mich schon seit 
längerem an dem Beispiel.

Autor: Erik B. (bibabulks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal welchen Controller & Welche Frequenz kannst ruhig mal erwähnen . 
. .

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mitleser schrieb:
> Dann muß ich noch irgendwo ein anderes Problem haben,
> Pegel 5V stimmt laut Oszi auch ein leichtes hoch und herunterregeln
> bringt nichts.

Kann mich daran erinnern, dass ich damals mit dem Programm auf einem 
Mega16 gespielt habe.
Durch berühren mit dem Finger zeigte die Anzeige 50Hz an.
Dein Frequenzgenerator liefert mit Sicherheit um einiges saubere 
Rechtecksignale als mein Körper, der sich die Netzfrequenz von irgendwo 
her einfängt,

> Evtl. stimmt aber auch im Messaufbau was nicht und ich geh mit über 5V
> in den AVR.

Bist du am richtigen Pin?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mitleser schrieb:
>>Die Logik dahinter ist nicht ganz richtig. Es kann auch ein
>>Timer-overflow stattfinden, ohne dass die Messung selbst 65556 Zyklen
>>überschritten hat.
>
> Kann das jemand näher ausführen?

Nimm dir reale Werte (erfinde welche), setz in die Formel ein und sieh 
nach was rauskommt.

Dadurch das der Startwert dann größer als der Endwert ist, rechnet sich 
dieser eine Overflow wieder heraus.

Du musst nur, anders als Steffen weiter oben, so rechnen wie es auch der 
µC macht: von links nach rechts und nicht als mitdenkender Leser 
zunächst Teilausdrücke zusammenziehen.

Autor: Robert Schepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

habe auch einige Versuche unternommen, über Int0/Int1 die pos. Flanke, 
und über ICP die neg. Flanke, und damit die Dauer eines Fernsteuer PPM- 
Signals zu messen.
Der sich ändernde Fehler in der Genauigkeit hängt meiner Ansicht nach an 
eventuellen Asymetrien in den Interruptroutinen.
Dauert die Routine für die erste Flanke länger als für die zweite, 
ändert sich der Fehler prozentual bei sich ändernder Frequenz.
D.h. es muß peinlichst darauf geachtet werden, beide Interruptroutinen 
exakt gleich lang (Laufzeit) zu machen.

anderes Thema:
Durch Auswerten des Timer Overflows bzw. des erreichten Zählerstandes 
kann man einen anderen Vorteiler einstellen, und hat damit eine 
automatische Frequenzanpassung.


Gruß
Robert

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Schepp schrieb:

> Der sich ändernde Fehler in der Genauigkeit hängt meiner Ansicht nach an
> eventuellen Asymetrien in den Interruptroutinen.

Wie schnell taktest du deinen Prozessor?
1kHz, 10kHz?

> D.h. es muß peinlichst darauf geachtet werden, beide Interruptroutinen
> exakt gleich lang (Laufzeit) zu machen.

Übertreib mal nicht.
Dein µC arbeitet schnell genug, dass das kein Problem darstellt.

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe die Ideen oben mal mit einfließen lassen. Ich berechne mir das 
Ergebnis direkt in der ISR, da ich später direkt dort entscheiden muss, 
ob je nach Frequenz etwas getan werden muss oder nicht.
Ich habe im obigen Programm folgende Codezeilen ergänzt:
  
if ( (TIFR & (1 << TOV1)) && (!(EndTime & 0x8000)) ){    // Überlaufstattgefunden, der zur Messung gehört?
  NrOverflows++;
  }  
  if ( EndTime < StartTime ){    // Overflow stattgefunden, der aber nicht zur Messung gehört?
  NrOverflows--;
  }
Einerseits durch das hineinziehen in die ISR, muss ich prüfen, ob 
während Auftritt der ISR ein Overflow stattgefunden hat.
Die zweite Ergänzung prüft, ob ein Overflow vorliegt, der aber nicht zur 
Messung gehört.
Leider bekomme ich manchmal, nicht immer trotzdem 1 Overflow zu viel in 
der Messung.
Erkennt noch jemand einen Fehler in der Logik?

Danke.

P.S. Die Zeilen sind für Atmega8 geschrieben.

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

Bewertung
0 lesenswert
nicht lesenswert
Kleiner Fehler in der angehängten Datei, dort habe ich die 
Variablennamen noch nicht angepasst. Hier mit Fehler behoben, ändert 
aber nichts an der Logik :-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> Leider bekomme ich manchmal, nicht immer trotzdem 1 Overflow zu viel in
> der Messung.

Du mußt die Überlaufbehandlung auch bei der Startflanke machen.
Oder einfach garkeine extra Start/Stop-Behandlung, sondern einfach 2 
aufeinanderfolgende Auslesungen subtrahieren (alte Stopzeit = neue 
Startzeit).

http://www.mikrocontroller.net/attachment/16302/TIMER32.C


Peter

Autor: Martin H. (ar583)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mir mal die Frequenzmessungsprogramme von Karl Napf und Karl 
Heinz Buchegger angesehen und denke, dass diese für meine Anwendung 
passen könnten. Bin mir da aber nicht so ganz sicher und möchte euch 
deshalb gerne fragen, was ihr dazu sagt.

Ich würde nämlich gerne die Frequenz eines Rechtecksignals messen, die 
ca. im Bereich von 1-10Hz liegt, also sie wird mal höher mal niedriger. 
Der High-Pegel dieses Signals soll ebenfalls veränderlich sein. Mal kann 
er 0,5V sein, mal 4V. Ich würde gerne die Frequenz dieses Signals messen 
und gleichzeitig als "schönes" Rechtecksignal an einem anderen Port 
ausgeben, der Pegel soll dann 0V low bzw. 5V high sein.

Ist es möglich so etwas zu realisieren, oder müssen die High-Pegel immer 
gleich sein? Kann gleichzeitig gemessen und an einem anderen Port das 
Signal in der gemessenen Frequenz ausgegeben werden?
Ich hab so daran gedacht, solange sich die Frequenz am Eingang nicht 
ändert, müsste ja keine neue Frequenz an den Ausgangsport geschrieben 
werden. Das Ganze muss nicht so ne genaue Auflösung haben, aber es 
sollte so im 1Hz-Bereich unterschieden werden können (z.B. zwischen 4Hz 
und 5Hz). Ich möchte das auf dem Atmega16A realisieren.

Lg

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn nun der InputCapture auslöst, der Timerwert gespeichert wird, und 
alle Interrupts gerade durch eine andere ISR gesperrt sind und innerhalb 
dieser zeit der Timer überläuft, was passiert wenn die Interrupts wieder 
freigegeben werden? Zuerst wird doch die Overflow ISR angesprungen, der 
Overflowcounter incrementiert und erst anschließend die Input Capture 
ISR abgearbeitet. Dann passt aber der gecaputerte Wert nicht zum 
Overflowcounter und die Frequenz ist falsch.

Also macht das doch keinen Sinn. Man müsste eigentlich jedesmal prüfen 
ob der alte Wert größer ist als der neue, dann nämlich ist der Timer 
min. einmal übergelaufen, richtig?

Eigentlich eignet sich ein INT0 Interrupt besser, denn da wird der 
Zählerstand manuell ausgelesen und somit passt der Wert immer zum 
Overflowcounter.

Oder liege ich falsch?

Ingo

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.