Frequenz einlesen über den AVR Butterfly

[hrei]

Einen Timer verwendet man so oder so, aber einmal verwendet man dessen InputCapture-Einheit, um Zeiten genau zu messen, und einmal verwendet man externe Impulse, um den Timer hochzählen zu lassen. Bei letzterem braucht man noch einen zweiten Timer.
Dummerweise liegen die Tx Eingänge an anderen Pins als die ICPx.

Öhmm... ganz so isses ja nu nicht.

* Die Pulsein-Methode verwendet keinen Timer.

* Die Capture Methode verwendet einen Timer.

* Die Zählmethode verwendet einen Timer für die Torzeit.
Die Impulse erfasst man am besten über einen Interrupteingang, alternativ geht natürlich auch eine Flankendedektion an jedem beliebigen Pin per Software.

Grüße
Henrik

[SprinterSB]

Einen Timer verwendet man so oder so, aber einmal verwendet man dessen InputCapture-Einheit, um Zeiten genau zu messen, und einmal verwendet man externe Impulse, um den Timer hochzählen zu lassen. Bei letzterem braucht man noch einen zweiten Timer.
Dummerweise liegen die Tx Eingänge an anderen Pins als die ICPx.

Öhmm... ganz so isses ja nu nicht.

* Die Pulsein-Methode verwendet keinen Timer.

* Die Capture Methode verwendet einen Timer.

* Die Zählmethode verwendet einen Timer für die Torzeit.
Die Impulse erfasst man am besten über einen Interrupteingang, alternativ geht natürlich auch eine Flankendedektion an jedem beliebigen Pin per Software.

Grüße
Henrik

Mag sein, daß Pulsin das so macht...

Ich bezog mich in meinem Post auf die Möglichkeiten der zugrundeliegenden AVR-Hardware.

Wenn man seinen AVR auf 1MHz getaktet hat, dürfte man IMHO arge Probleme bekommen, wenn man versucht, Frequenzen über 100kHz softwaremässig zu messen, wahrscheinlich sogar schon deutlich früher. Vor allem mit Basic.

Flankendetektion über Polling und externe IRQs liefern zudem ein recht fehlerbehaftetes Ergebnis, vor allem erster Ansatz. Die Schleife dürfte nicht länger dauern als 10 Takte. Eine auf externe IRQ basierende ISR dürfte komplett nicht länger dauern als 6 Takte (4 Takte IRQ-Latenz). In beiden Fällen sind (andere) IRQs tabu.

Warum also sollte man die Möglichkeiten der Hardware nicht nutzen?

[hrei]

Mag sein, daß Pulsin das so macht...

Das mag nicht so sein, daß ist so.

Wenn man seinen AVR auf 1MHz getaktet hat, dürfte man IMHO arge Probleme bekommen, wenn man versucht, Frequenzen über 100kHz softwaremässig zu messen, wahrscheinlich sogar schon deutlich früher. Vor allem mit Basic.

Wer einen µC mit 1 MHz taktet, wenn er 100 kHz messen will, hat kein (programm)technisches Problem, sondern ein Verständnisproblem.

Flankendetektion über Polling und externe IRQs liefern zudem ein recht fehlerbehaftetes Ergebnis, vor allem erster Ansatz. Die Schleife dürfte nicht länger dauern als 10 Takte. Eine auf externe IRQ basierende ISR dürfte komplett nicht länger dauern als 6 Takte (4 Takte IRQ-Latenz). In beiden Fällen sind (andere) IRQs tabu.

Schneller als das direkte Aufaddieren der Impulse im Interrupt ist keine andere Methode. Die ISR besteht aus einem Befehl + return: INCR var.

Warum also sollte man die Möglichkeiten der Hardware nicht nutzen?

Weil der Fragesteller erwähnte, er hätte die Timer gerne für andere Zwecke frei?

Ohne zu wissen, welcher Frequenzbereich denn nun tatsächlich erfasst werden soll, können nur alle Methoden aufgezeigt werden. Bei niedrigen Frequenzen <1 kHz ist die Periodendauermessung meist sinnvoll, darüber hinaus werden i.d.R. mit der Impulszählung die besseren Ergebnisse ezielt werden können.

Henrik

[Rage_Empire]

Henrik hat das schon richtig erkannt.
Man könnte ja eine hohe frequenz runterteilen. dann wäre es mit der Periodendauermessung wieder zu bewältigen. Also, bei meiner anwendung um die 40Kz, teiler durch 32 oder 64 und dann pulsein. Nur die Hardware wächst dann leider auch mit.

[SprinterSB]

Ich gehe mal davon aus, daß es in Ordnung ist, hier die Möglichkeiten der Hardware eines AVR aufzuzeigen, die zur Lösung der Frage das OP hinführen könne. Hierzu gehört auch das Zählen externer Pulse mittels externer Timer-Quelle.

Ich sehe nicht, warum man damit nicht eine Frequenz von f messen können sollte, wenn man auf 10*f taktet. Voraussetzung ist, daß die einzelenen Pulse länger sind als ein Prozessortakt -- eine Einschränkung an das Signal, die man bei allen Verfahren hat.

Ok, je höher die Anforderungen an eine Messung sind, desto mehr Hardware muss man vorhalten -- ne Binsenweisheit. Nen Timer frei zu haben ist freilich immer nett...

Ohne Kenntnis der restlichen Applikation ist es kaum möglich zu beurteilen, wie man einen externen IRQ am besten dienstbar macht, das weiß der OP am besten.

Die externen IRQs haben hohe Priorität. Lässt man kaskadierende IRQs zu, schafft man eine IRQ-Latenzzeit von 9 Takten, 2 Takte für Save/Restore von SREG und 2 Takte adiw für der Zähler, 4 Takte reti. Leistet man sich den Luxus, die verwendeten Register zu sichern, ist man grob bei 20 Takten.
Damit erhält man eine untere Grenze für die Pulslängen eines fehlerfrei messbaren Signals.

[Heiko R.]

Hallo,

sorry das ich so lange nichts gesagt habe. Ich möchte eine Frequenz von max 10KHz messen. Wenn ich es richtig verstanden habe wäre somit die pulsein-Variante schon möglich, oder? Habe ich das jetzt richtig verstanden, dass die Zahl die er uns bei pulsein ausgibt, mit 10µs multipliziert werden muss? Steht die Info im User Guide oder wo hast du diese Info denn her Henrik?
Wenn es ohne Timer gehen würde wäre es schon besser für uns, da der Timer irgendwie nie das macht was wir wollen .

Gruß Heiko

[Heiko R.]

Hallo,

ích habe gerade noch mal die pulsein-Variante ausprobiert und meine Chiptaktung geändert. Dadurch ändert sich ja auch die ausgegebene Zahl. Mit welcher Taktung hast du deinen Chip getaktet, dass er die Zahl * 10µs ausgibt? Durch die höhere Taktung streut der Wert auch nicht mehr so stark.

Gruß Heiko

[Werner_Just]

Hallo Henrik,

> Die einzige Falle besteht darin, daß zum Lesen des Capture
> Registerpaares die Interrupts abgeschaltet sein müssen.
Ist das nicht standardmäßig in einer Interrupt-Routine sowieso so?
D.h. solange Du in OnCapture die Interrupts nicht explitzit wieder frei gibst sind sie innerhalb der Interrupt-Routine gesperrt und werden erst beim Return wieder freigeschaltet.

Aber noch was anderes...
Funktioniert das Timer-Capture bei Dir im BASCOM-Simulator?
Bei mir übernimmt der BASCOM-Simulator den aktuellen Timerwert nicht in das Capture Register. Weder bei Deinem Code, noch bei meinem, noch beim Beispiel von Rowalt. Simuliere ich den Code in Studio4 klappt es, genauso wie in real Hardware. Der von Bascom erzeugte Code scheint also korrekt zu sein.

Mark Albert hat sich bei Supportanfragen dazu bisher nie geäussert. Keine Antwort, auch auf Nachfrage

Ist das nur auf meinem Rechner so? (Getestet hab ich es unter W95/2000/XP, mit Bascom 1.11.7.4 bis 1.11.7.9 und M8, M16 und M32er Atmel.)

Ciao,
Werner

[Heiko R.]

Hallo,

hat sich glaube ich geklärt. Ich müsste einen Anstieg, der in 100-400ms erledigt ist, bearbeiten. Ich müsste aber den Wert ständig abtasten um nicht über einen Punkt in der Rampe hinauszufahren. Wenn keiner mehr eine neue Lösungsidee hat, dann werde ich es vermutlich anders lösen müssen.

Gruß Heiko