Hallo, wünsche ein gutes neues Jahr! mit einem Atmega 162 messe ich mit ICP1 ein Signal von einem externen Signalgenerator.Habe den Prescale auf 8 eingestellt. Verwende einen externen Quarz mit 3.686.400 Hz Fuses gesetzt auf Ext.Crystal Osc.3.0-8.0 MHz Start-up time 16K CK +65ms Bin mir allerdings nicht sicher, ob das die optimale Einstellung ist, denn: wenn ich beispielsweise mit dem Signalgenerator 64,87 Hz = Periodendauer 15.4178 ms einspeise, dann gibt mein µC 7055 aus, also: 7055*10=70550 70550/4608 = 15.3103 ms = 65,31 Hz aus. Eine Differenz von 0,44 Hz ist aber für meine Anwendung inakzeptabel. Denn ich muss aufgrund eines Messwertes ein auf cHz genaues Sinussignal ausgeben. Den externen Frequenzgenarator habe ich mit dem Oszi geprüft, der stimmt. Könnte mir jemand einen Tipp geben? Gruß Thomas
Thomas schrieb: > Könnte mir jemand einen Tipp geben? Irgendwas machst Du hier grundlegend falsch: bei 460800 Hz Zähltakt solltest Du 7104 anstelle 7055 Takte erhalten. Das sind 0,7% Fehler: So falsch kann kein Quarz gehen. Ansatzpunkte: - Wird wirklich der Quarz verwendet? - Mißt du wirklich die Periodendauer oder den Abstand zwischen steigender und fallender flanke eines 99% PWM-Signals? - läuft der Timer kontinuierlich oder hälst Du den etwa während der Messung an? - ist das ICP-Signal sauber? Beim ATMEGA ist im Normalfall die Schaltschwelle relativ niedrig (ca 1.5V) was bei Masseversatz im System zu Fehlimpulsen oder Ausfällen führen kann. Ich verwende in der Regel einen Spannungsteiler und eine Tiefpaßfilterung mit ein paar pF um das Eingangssignal zu filtern. Gruß Anja
>Den externen Frequenzgenarator habe ich mit dem Oszi geprüft, der
stimmt.
Ein Oszi ist nicht genauer wie 1%. Ausser vielleicht ein MSO, mit 1 mega
Punkten.
@hacky ist schon klar, war aber dennoch genauer, als das, was der µC erzählt.. @anja >Irgendwas machst Du hier grundlegend falsch: >bei 460800 Hz Zähltakt solltest Du 7104 anstelle 7055 Takte erhalten. >Das sind 0,7% Fehler: So falsch kann kein Quarz gehen. Das sehe ich genauso,deswegen ja meine Frage.... > Wird wirklich der Quarz verwendet? ich denke ja, deswegen hatte ich Fuseeinstellung mitgepostet, UART läuft ja auch korrekt >Mißt du wirklich die Periodendauer oder den Abstand zwischen >steigender und fallender flanke eines 99% PWM-Signals? ich denke über ICP kann ich mich nur für rising to rising edge oder eben für die fallenden entscheiden. Deswegen muss es die Periodendauer sein. Ich hänge mal den Code an. >- läuft der Timer kontinuierlich oder hälst Du den etwa während der >Messung an? der Timer läft kontinuierlich, geht ja über compare match >- ist das ICP-Signal sauber? ein sauberes TTL Signal Gruß Thomas
Kann es sein, dass Du bei zweiter_flanke noch die neue Startzeit speichern mußt und nicht nur die Endzeit? Ich habe Deinen Code nur schnell überflogen.
Bis auf die Behandlung der Überläufe sieht der Code so aus als müsste die Periodenmessung funktionieren. Das könnte also gelegentliche Ausreißer geben, meistens (ca. 99,9 % der Fälle), sollte der Wert aber stimmen. Wie zuverlässig ist denn die andere Frequenzangabe ? Die meisten Oszlloskope sind da nicht so genau. Ich kann zwar keine häufiges zurücksetzen des Prescalers finden, wäre aber eine mögliche Fehlerquelle. Wieso nicht mal ohne Prescaler beim Takt probieren - das ist etwas weniger Fehleranfällig. Bei dem Beispiel ginge dsa sogar noch ohne Überlauf.
@Kakadu muss ich mal überlegen.... @Ulrich also jetzt bin ich ziemlich verwirrt: Habe nochmal getestet: Frequenzgenerator Eingang ICP 65,56 Hz = 15,2532 ms Ausgabe :ICP Wert 6980 = 15,1475 = 66,01 Hz (schneller als das Eingangssignal???) Ohne Prescaler bekomme ich nur negative Werte (?) -9700; -9694 etc Ich steh jetzt völlig auf dem Schlauch........... Thomas
achso, habe ich vergessen: >Wie zuverlässig ist denn die andere Frequenzangabe ? Die meisten >Oszlloskope sind da nicht so genau. zu dem Wert 65,56 sagt das Oszilloskop 65.6Hz , 15.3 ms Periode das ist deutlich besser als der µC. Thomas
Hallo, zum Testen empfehle ich einen der Atmeltimer des gleichen Prozessors im CTC Mode laufen zu lassen, um damit eine bekannte Frequenz auszugeben. Diese dann mit dem ICP messen. Damit kannst Du dann Softwarefehler einkreisen bzw. ausschliessen. Gruss Klaus
@Thomas du solltest die Overflows nur während der Messung weiterzählen, also wenn UpdateUart=flase, sonst kann's bis zur Berechnung in der Main u.U. noch weiterzählen. Sascha
Das ohne Prescaler negative Zahlen rauskommen, liegt an itoa() zur Wandlung. Für unsigned Zahlen gibt es bei Glibc auch utoa() und auch noch einen Version für die 32 Bit Zahlen. Die -9700 etsprechen bei richtiger Ausgang 55836. Das passt also zu 6980 mit Teiler 8. Was ist denn das für ein Signalgenerator oder anderer Frequenzmesser ?
lieg ich falsch oder kommst du hier nie in den else zweig???
ISR( TIMER1_CAPT_vect )
{
static unsigned char ErsteFlanke = TRUE;
...
if( ErsteFlanke )
{
...
}
else
{
...
Thomas schrieb: > Ausgabe :ICP Wert 6980 = 15,1475 = 66,01 Hz (schneller als das > Eingangssignal???) Thomas schrieb: > - ist das ICP-Signal sauber? > > ein sauberes TTL Signal Sieht mir aber nicht danach aus wenn einmal zuviel und einmal zuwenig gemessen wird: - Welche Pegel High/Low - welche Flankensteilheiten? - gibt es evtl. Treppenstufen durch Reflektionen auf dem Signal (womöglich noch bei 1,5V?) Die Messungen die hier Interessieren sind direkt zwischen Massepin des ATMEGA und dem ICP-Eingang. (nicht irgend eine Masse im Netzteil oder so). Gruß Anja
@kollisson der Timer 3 läuft ja schon im CTC mode für die Ausleseabstände der LUT. Werde morgen mal das reine CTC Signal ausmessen bzw auf ICP schalten.... @sacha-w würde nicht, wenn das der Fehler wäre, die Periodendauer eher zu lang als zu kurz? muss mal drüber nachdenken.... @Ulrich >Was ist denn das für ein Signalgenerator oder anderer Frequenzmesser ? oups, daran hatte ich nicht gedacht, klar kenn ich utoa. Der Frequenzgenartor ist ein Voltcraft 7202 Sweep / Funktionsgenerator, das Oszi ist ein Velleman 2 Kanal Digital Oszi mit Funktionsgenerator. @gasd12 doch, ich komme in else, sonst käme ich ja gar nicht in die updat UART Schleife... @anja sorry, habe mich vielleicht blöd ausgedrückt, aber die messung bringt immer nur zu niedrige Periodendauern und damit eine zu hohe Frequenz. Nie umgekehrt Die Abweichung ist linear, steigt also bei steigender Eingangsfrequenz entsprechend an( also prozentual gleich) >- Welche Pegel High/Low >- welche Flankensteilheiten? >- gibt es evtl. Treppenstufen durch Reflektionen auf dem Signal werde ich morgen nochmal nachmessen...zwischen massepin und ICP, wie Du gesagt hast. Danke an alle für die rege Teinahme! Gruß Thomas
>> @kollisson >> der Timer 3 läuft ja schon im CTC mode für die Ausleseabstände der LUT. >> Werde morgen mal das reine CTC Signal ausmessen bzw auf ICP schalten.... Du kannst ja auch zum testen einen weiteren Atmel nehmen, den du aber aus dem gleichen Systemtakt speist. Es geht hierbei ja darum, dass du die genaue Frequent deines Taktes nicht kennst. Im von mir vorgeschlagenen scenario wäre das aber egal, da die Abweichung dann auch im zu messenden Signal vorliegt. Du kannst damit halt deine Software testen, da hier exact das herauskommen muss, was zu erwarten ist. Gruss Klaus
>Die Abweichung ist linear, steigt also bei steigender Eingangsfrequenz >entsprechend an( also prozentual gleich) Dann stimmt Deine Taktfrequenz nicht mit der angenommenen überein. Auch Quarze können defekt sein. Am einfachsten wäre es, die Netzfrequenz (50 Hz) zu messen. Die ist in diesem Fall wohl hinreichend genau, um als Referenz zu dienen.
Der Frequenzgenerator hat zwar eine 6 Stellige Anzeige und damit viel Auflösung, laut Datenblatt ist aber die Genauigkeit mit +-5% sehr gering. Ganz vorstellen kann ich mit das aber auch nicht. Einen Quarzstabilen Takt kann man zumindest bei einem wohl noch analog aufgebautem Wobbelgenerator ja nicht erwarten, aber die Anzeige hätte ich dann über den eingebauten Zähler erwartet. Vielleicht ist da ja ein Kalibrierung vorgesehen, und irgendwie eine falsche Konstante drin. Nach der Anleitung sehe ich die da eingestellte Frequenz jedenfalls nicht als zuverlässig an - der Fehler kann also auch bein Generator liegen. Ist vielleicht der andere Generator (im Scope) besser ?
Hallo, habe jetzt erstmal probiert den Systemtakt an PB0 auszugeben, indem ich die Fuse CKOUT gesetzt habe. Entweder mein Oszi löst das nicht auf, oder irgendetwas anderes klappt nicht. Jedenfalls konnte mein Oszi diesem Signal keine Frequenz zuordnen. Dann habe ich Timer3 in CTC ohne prescale, den Compare OCR3A auf 0 gesetzt, den PIND4 auf Ausgang gesetzt und hier nun den halben Systemtakt erwartet. Da kann ich aber nur eine recht chaotische Welle mit 10.4 MHz (?) feststellen. Merkwürdigerweise hat das Oszi im Gegensatz zur PB0 Messung hier eine Frequenz anzeigen können.(Frust) @Ulrich Das Oszi gibt schon die richtige Frequenz in der Messung des Funktionsgenerators aus. Dass dieser natürlich trotz 5 stelliger Anzeige diese Auflösung nicht korrekt produziert, ist mir klar. Ich nehme ja auch nur die ersten zwei Stellen im Hzbereich hinter dem Komma ernst. Und die stimmen mit den Oszimessungen überein. @kollison ich steh da etwas auf dem Schlauch, wie ich die 50Hz Netzschwingung als Referenz praktisch umsetzten soll. Antenne an Eingang;-)? @anja Habe, wie Du oben lesen kannst erstmal versuch den Systemtakt zu messen und bin daran schon gescheitert. Werde mal morgen schauen, dass ich den Quarz und den µC austausche. Dazu noch eine Frage: Ich neige dazu meine Programmschnipsel nicht im Compiler zu simulieren, sondern direkt auf den µC zu flashen. Ich habe das doch recht verstanden, dass der bis zu 100.000 Flashs überlebt? Oder habe ich damit schon ein Problem verursacht? Gruß Thomas
Die 100.000 oder auch nur 10.000 mal die man den µC Flaschen kann sind in der Regel kein Problem. Auch wenn man sich nur 5 Minuten mit einer Version beschäftigt kriegt man so kaum 100 Versionen am Tag oder 3000 im Monat hin. Noch so viel Zeit die man mit dem µC verbracht hat, kann man dann ggf. alle 3 Monate einen neuen spendieren. Am ehesten erreicht man das Limit noch wenn man viel JTAG für Einzelschritt-simulationen nutzt - da werden dann schon öfter mal Waits geschrieben und gelöscht. Wenn der Takt den der µC ausgibt nicht sauber ist, könnte es vielleicht ein Porblem mit der Versorgungsspannung oder den Abblockkondensatoren sein ? Wenn das Oszilloskop Problem mit der hohen Frequenz hat, ggf. auch ein langsameres PWM Signal nachmessen. Die Frequenz sollte auch der Zähler im Generator nachmessen können.
Anja schrieb: > Das sind 0,7% Fehler: So falsch kann kein Quarz gehen. Das stimmt nicht, wenn er auf einer Nebenresonanz schwingt schon, da gibt es die lustigesten Effekte. z.B. Springen zwischen den Haupt- und Nebenresonanzen durch Erschütterungen.
@Ulrich ich verwende das STK500 . Da denke ich nicht, dass es ein Problem mit den Abblockkondensatoren gibt. Außerdem ist das Ergebnis ja nicht total falsch sondern eben nur ein bischen;-) Werde es jetzt nochmal mit einer lamgsameren Frequenz probieren. Im Datenblatt steht, dass es mitunter zu Problemen kommen kann, wenn man die prescaler häufig wechselt, da sich die Timer 0,1 und 3 ein physikalisches prescale Modul teilen. Hat da jemand schon negative Erfahrungen gemacht? Gruß Thomas
>Im Datenblatt steht, dass es mitunter zu Problemen kommen kann, wenn man >die prescaler häufig wechselt, da sich die Timer 0,1 und 3 ein >physikalisches prescale Modul teilen. Meinst Du die leiern aus und gehen kaputt? Nimm einen Trafo 230V prim. 10-20V sek. und lege die Sekundärspannung über 10k an den ICP; ggf. noch 10nF zur Filterung gegen Masse. Dann müssen sich 49,99 - 50,01 Hz zeigen, wenn korrekt gemessen wird.
@kakadu naja, so wie Du es jetzt sagst...... Bin Anfänger;-) Leiert also nicht aus. Suche jetz in der Bastelkiste nach einem 230/12V Trafo..... Ich wollte aber gerade die Systemfrequenz überprüfen, indem ich Timer3 im CTC Modus ohne Prescale mit irgendeiner OCR3A über den OC3A PIN ans Oszi gebe. Nun habe ich anscheinend irgendwas nicht ganz verstanden. Laut AVR GCC Tutorial sollte sich die Ausgangsfrequenz am PIN berechnen lassen durch: Foc3A = F cpu / prescaler * ( OCR3A+1 ) nun habe ich eine Fcpu von 3.686.400 Hz, prescale 1 (also keinen) und mal 2000 ins OCR3A geschrieben. Nach der Formel müsste jetzt doch 3686400/2001 = 1842,2788605697 rauskommen. Mein Oszi zeigt nun 915 Hz. Weiß nun nicht was das bedeutet, außer dass ich die Timerartikel noch mal durcharbeiten muss. Kann mir jemand einen Tipp geben, unter was ich in den Treats suchen muss? Unter CTC, Systemfrequenz oder so habe ich nichts gefunden.... Gruß Thomas
@kakadu Habe jetzt ein 12 Voltnetzteil gefunden, so angeschlossen wie Du es gesagt hast, ICP zählt aber nicht. Es ist allerdings ein stabilisiertes Netzteil... Vielleicht zu stabil für ICP ? Gruß Thomas
@ Thomas (Gast)
>Habe jetzt ein 12 Voltnetzteil gefunden,
Kein Netzteil, einen TRAFO, wo WECHSELSPANNUNG rauskommt. Ein Netzteil
liefert GLEICHSPANNUNG!
Thomas schrieb: > Nun habe ich anscheinend irgendwas nicht ganz verstanden. Laut AVR GCC > Tutorial sollte sich die Ausgangsfrequenz am PIN berechnen lassen durch: > > Foc3A = F cpu / prescaler * ( OCR3A+1 ) > > nun habe ich eine Fcpu von 3.686.400 Hz, prescale 1 (also keinen) und > mal 2000 ins OCR3A geschrieben. Nach der Formel müsste jetzt doch > > 3686400/2001 = 1842,2788605697 rauskommen. Mein Oszi zeigt nun 915 Hz. > > Weiß nun nicht was das bedeutet, außer dass ich die Timerartikel noch > mal durcharbeiten muss. Wenn deine ISR 1814 mal in der Sekunde aufgerufen wird UND bei jedem ISR Aufruf der Ausgangpin seinen Pegel wechselt, dann hat der Pin eine Frequenz von der Hälfte der ISR Aufruffrequenz. Wenn du jede Sekunde den Lichtschalter in jeweils die andere Stellung bringst, dann blinkt dein Licht mit 0.5Hz > Unter CTC, Systemfrequenz oder so habe ich nichts gefunden.... EInfach mal darüber sinnieren, wie das auf Hardware Ebene funktioniert. Dann ergeben sich all die Formeln ganz von alleine. Und das beste daran: man versteht sogar warum die Formeln genau so aussehen wie sie aussehen. Und noch viel besser: beim nächsten mal muss man nicht erst umständlich im Datenblatt nach einer Formel suchen, sondern leitet sich das in 5 Sekunden selber her.
@kakadu ...das war jetzt blöd.. Hatte ich fälschlicherweise gleichgesetzt,sorry @kbuchegg Da war ich eben auch draufgekommen... Aber dennoch verstehe ich nicht, weshalb der Wert dann nicht genau stimmt: bei 1842 müsste dann doch 921 ausgegeben werden. 7 Hz Unterschied ist schon viel..... Aber darin liegt ja mein Grundproblem, mit dem ich diesen Thread begonnen habe: Die ausgegebenen Frequenzen haben immer eine Abweichung. Wem darf ich denn jetzt glauben: Meinem µC mit seinem Quarz, oder meinem Oszilloskop? Ich habe jetzt den OC3A an ICP angeschlossen und bekomme hier bei no prescale und Fcpu 3.686.400 Werte von 500-501! und damit tatsächlich eine Periodendauer von 1.085069 ( 5000/4608 )= ca 921.6589 Hz Mein Oszi zeigt korrekt 1,09ms aber 915Hz statt 917 Hz (=1.09ms) --Rundungen...... Das scheint nun meine Eingangsfrage schon zu beantworten: Mein ICP ist genauer als das Oszi und das ganze Problem beantwortet sich ggf. dadurch, dass mit der feineren Auflösung des ICP das Ergebniss anders, aber richtiger ist als das Oszi-Ergebnis mit seiner geringeren Auflösung. D.h. alles geht richtig, aber eben richtig je nach Auflösung! Danke. Thomas
>Ich habe jetzt den OC3A an ICP angeschlossen und bekomme ...
Ändere mal Deine Quarzfrequenz auf zum Beispiel 12MHz und Du wirst immer
noch das erwartete Ergebnis bekommen, was aber völlig verkehrt ist.
Denk einmal darüber nach :-)
@kakadu wie jetzt? Du meinst, wenn ich einen realen 12Mhz Quarz einsetze bekomme ich wirklich das selbe Ergebniss wie mit meinem 3,6MHz Quarz?? Das verunsichert mich jetzt extrem. Wenn ich den Timer 3 mit 12Mhz ohne prescale arbeiten lasse, dann muss er doch auch 12.000.000 Tics in der Sekunde machen, oder nicht? Dann zählt er doch entsprechend schneller, und braucht weniger Zeit um den eingestellten OCR3A Wert zu erreichen. Wenn mein ICP dann das toggeln zählt, oups, der zählt ja dann auch schneller......im selben Verhältnis, was sich ja nicht geändert hat. Also bekäme ich dasselbe Ergebnis, was aber mit der realen Zeit nicht direkt übereinstimmen würde. Hm. Aber wenn ich dieselbe UART Ausgabe bekomme, muss ich sie doch dann anders berechnen, d.h. in meine Rechnung fließt ja dann der höhere Systemtakt ein, der das dann ausgleichen müsste......... Ich merke, dass ich es definitiv noch nicht im Griff habe ;-(( Gruß Thomas
> oups, der zählt ja dann auch schneller......im selben Verhältnis, was > sich ja nicht geändert hat. Also bekäme ich dasselbe Ergebnis, was aber > mit der realen Zeit nicht direkt übereinstimmen würde. Hm. Das war ja der Sinn meines Vorschlages zum Testen deiner Software. Unabhängig vom wirklichen Takt muss in deiner Zählung exact das herauskommen, was nach Berechnung zu erwarten ist. Dies passiert aber nur dann, wenn deine Software korrekt arbeitet . Gruss Klaus
@kollison das scheint ja dann der Fall zu sein. Takt ist verifiziert und stimmt. Bekomme jetzt aber ein neues Problem: Das Sinussignal ist sehr unruhig. Dazu öffne ich aber einen neuen Thread. Danke
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.