ZitierenUm bei den Frequenzen weiter nach unten zu kommen, kannst Du auch den Timer 1 in diesem Modus betreiben.
Der hat dann 16Bit breite, also 65536 verschiedene Werte.
Wenn Du diesen Timer für nicht schon was anderes nutzt...
OK werd ich probieren !
Um bei den Frequenzen weiter nach unten zu kommen, kannst Du auch den Timer 1 in diesem Modus betreiben.
Der hat dann 16Bit breite, also 65536 verschiedene Werte.
Wenn Du diesen Timer für nicht schon was anderes nutzt...
Ja daran hab ich auch gedacht, aber ich möchte die erzeugte Frequenz mit dem Timer 1 als Torzeit ( 1Sekunde) messen und auf dem Display darstellen. Da tut sich allerdings schon das nächste Problem auf. Mein Takt wird am OC2 ( Portd.7)ausgegeben, den möchte ich jetzt abfragen, aber wie????
Eine Abfrage auf Pind.7 oder Portd.7 funktioniert nicht ??
Wenn man die Frequenz per CTC Modus erzeugt, und keinen groben Fehler drin hat, dann stimmt das Verhältnis zur Taktfrequenz des µC. Ein nachmessen mit dem selben µC macht damit überhaupt keinen Sinn - da kommt immer der Sollwert bei raus.
Da hat Besserwessi natürlich recht.Wenn man die Frequenz per CTC Modus erzeugt, und keinen groben Fehler drin hat, dann stimmt das Verhältnis zur Taktfrequenz des µC. Ein nachmessen mit dem selben µC macht damit überhaupt keinen Sinn - da kommt immer der Sollwert bei raus.
Grundsätzlich gibt es bei einem AVR Controller mehrere Möglichkeiten Frequenzen zu messen.
Die den Controller am wenigsten belastende ist, die Messfrequenz auf einen Timer Clock In zu legen und damit diesen Timer + Überlaufvariable hochzuzählen.
Dann brauchst Du nur nach einen Torzeit den aktuellen Timerwert und die Hochzählvariable miteinander zu verrechnen und kommst auf Deine Frequenz.
Bei sehr niedrigen Frequenzen wird es genauer, wenn man die zu messende Frequenz auf den ICP Pin legt und einen Timer mit der ( heruntergeteilten ? ) Taktfrequenz des Controllers laufen lässt.
Die Frequenz wird dann anhand des Unterschiedes zwischen 2 ICP Interrupts ( = 1 Periode ) errechnet.
Dieses Verfahren bringt dann schnelle und genaue Ergebnisse auch noch bei Frequenzen um 1Hz.
Das Optimum dürfte eine Messroutine sein, die beide Verfahren benutzt, die ICP Interrupts aber nur bei niedrigen Frequenzen zulässt.
Wenn die Frequenzschritte, bedingt durch die Taktfrequenz dieses Timers, bei der ICP Methode über 1Hz groß werden ( bei 1sek Torzeit ) ist es günstiger die Zählmethode zu verwenden.
Die ICP Methode belastet bei höheren Frequenzen den Controller stark, da ja bei jedem 0 nach 1 Übergang ein Interrupt ausgelöst wird!
@wkrug:
Die Messung der Frequenz über die ICP Funktion geht auch noch bei relativ hohen Frequenzen (bis über 100 kHz) mit mehr Auflösung als durch Zählen, wenn man sich nicht auf die Zeit zu einer Periode beschränkt, sonder ggf. mehr Perioden misst. Nur bei höheren Frequenzen ist der µC nicht schnell genug und man braucht einen Vorteiler - mit einer Stufe von 1:256 oder 512 kommt man dann auch schon bis rund 50 MHz.
Auch per Software DDS kann man einen Sauberen Sinus über 2 kHz hinkriegen, man sollte dazu aber schon einen Rekonstruktionsfilter passend zur Abtastrate haben.
Hab um bei meiner Frequenzeinstellung in einen möglichst großen Bereich zu variieren per Software den Prescaler geändert.
Weil ich es aber nicht hinbekommen habe bei folgender Anweisung :
Config Timer2 = Timer , Clear Timer = 1 , Compare = Toggle , Prescale = 256
hab ich es mit der direkten Registereingabe versucht, und es hat auch geklappt.
Tccr2 = &B00011100
Allerdings hab ich unterschiede in der Ausgabefrequenz bei der Bascom Anweisung 30 bis 7810 Hz, und bei der Registereingabe 7 bis 1980 Hz.
Wo liegt der Unterschied zwischen der Bascom Anweisung und der Registereingabe ?
Eigentlich sollte es keinen Unterschied geben... was die Register anbetrifft, kocht Bascom auch nur mit Wasser
Wenn ich mir allerdings das Datenblatt des ATMega32 so anschaue, resultiert aus TCCR2 = &B00011100 ein Prescaler von 64. Das würde erklären, weshalb sich die Frequenzspektren genau um den Faktor 4 unterscheiden.
Genau genommen müssten die Frequenzen unter der Bascom-Konfiguration dann zwar niedriger sein als bei direkter Registereingabe - also genau andersrum wie Du es beschrieben hast. Aber vielleicht hast Du das ja nur verwechselt...?
Wenn Du ein LCD am Start hast, kannst Du Dir übrigens genau anschauen, was Bascom mit den einzelnen Registern so alles anstellt, indem Du sie Dir direkt anzeigen lässt (z.B. LCD TCCR2). Du musst den dezimal angezeigten Inhalt nur noch nach binär umwandeln - aber das macht der Windows-Taschenrechner ganz bequem!
Was zu beweisen wäre.Die Messung der Frequenz über die ICP Funktion geht auch noch bei relativ hohen Frequenzen (bis über 100 kHz) mit mehr Auflösung als durch Zählen
bei 100kHz hast Du genau 160 Takte, bevor der nächste ICP Interrupt auftritt.
Allein die Registersicherung verschluckt davon schon mal ca. 70 Takte, wenn man sie nicht abschaltet.
Dazwischen ist aus den ermittelten Werten die Frequenz zu berechnen.
Ich habs schon mit einem ATMEGA 32 Controller probiert.
Ab ca. 13kHz geht es los, das das Display rumzickt, weil das Display Timing nicht mehr stimmt. Ab 2 kHz ist die Zählerei genauer als die ICP Methode.
Gut, man könnte den ICP Interrupt sperren, bis alle dazugehörigen Aufgaben erledigt sind und erst dann wieder eine neue Messung starten, aber richtig toll find ich das nicht.
Das ICP Verfahren ist ab dem Zeitpunkt nicht mehr genauer, als die Zählmethode, wenn ein Wert höher oder niedriger des Counters mehr als einen Wert in der Torzeit überschreitet.
Wenn man mehrere Perioden zur Messung heranzieht wird das zwar etwas besser, aber irgendwann ist da auch Schluß.
Wo dieser Punkt liegt ist abhängig von der Torzeit der Messung und dem Prescaler des "ICP Timers".
Aber gut, hier gehts um einen Frequenzgenerator und nicht um einen Frequenzzähler.
Ich würde aber trotzdem eine Lösung mit einem speziellen DDS Chip vorziehen.
Guck mal bei ELV unter der Baubeschreibung für den DDS 130 Funktionsgenerator.
Das Teil könnte größtenteils übernommen werden. Lediglich den Controllerteil würd ich austauschen und der Filter ist lt. Simulation auch etwas wellig.
Ein Kollege und Ich basteln zur Zeit an einem Funktionsgenerator mit AD9834 ( DDS Chip ) , AD5620 ( D/A Wandler = Amplitudenmodulation ), AD8000 ( Ausgangsverstärker ) und nem ATMEGA 644 Controller rum.
Es ist dran gedacht Dreieck, Sinus und Rechtecksignale ( TTL Pegel ) zu erzeugen inklusive Wobbeln.
Das Teil soll AM, FM, und PPM Modulation beherrschen.
Ausserdem wird eine USB Schnittstelle reinkommen, mit der man die Parameter einstellen und die Modulatoren bedienen kann.
Die maximale Trägerfrequenz wird so zwischen 20 und 30MHz betragen.
Nach unten möchten wir bis 1Hz kommen.
Zur Zeit existieren nur mal die ersten Schaltpläne, mal gucken, was daraus wird.
Alles klar, hab ich wohl einen groben Fehler gemacht, falsch abgelesen !Zitat von Sauerbruch
Eigentlich sollte es keinen Unterschied geben... was die Register anbetrifft, kocht Bascom auch nur mit Wasser
Wenn ich mir allerdings das Datenblatt des ATMega32 so anschaue, resultiert aus TCCR2 = &B00011100 ein Prescaler von 64. Das würde erklären, weshalb sich die Frequenzspektren genau um den Faktor 4 unterscheiden.
Genau genommen müssten die Frequenzen unter der Bascom-Konfiguration dann zwar niedriger sein als bei direkter Registereingabe - also genau andersrum wie Du es beschrieben hast. Aber vielleicht hast Du das ja nur verwechselt...?
Wenn Du ein LCD am Start hast, kannst Du Dir übrigens genau anschauen, was Bascom mit den einzelnen Registern so alles anstellt, indem Du sie Dir direkt anzeigen lässt (z.B. LCD TCCR2). Du musst den dezimal angezeigten Inhalt nur noch nach binär umwandeln - aber das macht der Windows-Taschenrechner ganz bequem!
Danke
Das mit der Displayanzeige probier ich mal aus.
Berechtigungen
Lesezeichen