Hallo, Ich habe folgendes Problem: Ich baue gerade an einer Uhr und dazu brauch ich den Sekundentakt. Ich habe jetzt das Beispiel aus dem Wiki übernommen und meine Quarzfrequenz eingesetzt (4.9152 MHz). Dann hatte ich eine Abweichung von 44 Sekunden bei einer Minute (Uhr ging nach). Nach der Formel hab ich ein Neues XTAL berrechnet (4915200*(1-(44/60))). Allerdings hatte ich dann schon wieder 44 Sekundenabweichung. Ich hab dann nochmal andere XTAL Werte ausprobiert --> Keine änderung. Aber Wenn ich DEBOUNCE änder merkt man die Änderung. In dem Angehangen Program sind jetzt ca. 80MHz angeben, auch das mach keinen Unterschied zu 8MHz oder 0.8MHz. Hardware: Ich habe einen Quartz mit 22pF Kondensatoren. Fuses: CKOPT = haken, SUT_CKSEL: Ext.Crystal/Resonator High Freq.; Start-up time 1K CK + 64ms. (in AVR Studio mit ISP mkII). Ich hab auch schon verschiedene Einschwingzeiten ausprobiert. Frage: Woran liegt das? Ist das Hardwarebedingt oder ein Softwareproblem? Tim
alle Variablen, die in der ISR verändert werden, und außerhalb gelesen werden müssen volatile werden. Nach dem du das bereinigt hast, mach noch mal einen Test. den prescaler kannst du übrigens in der ISR selbst definieren:
1 | ISR(TIM1_COMPA_vect) // <-- benutze keine deprecated sachen, sondern ISR |
2 | {
|
3 | static prescaler = DEBOUNCE; // <-- variablen so lokal wie möglich definieren |
4 | if( --prescaler == 0 ){ |
5 | prescaler = (uchar) DEBOUNCE; |
6 | m++; // exact one second over // <-- m muss volatile sein |
7 | aflag = 1; // <-- aflag muss volatile sein |
8 | }
|
9 | #if XTA % DEBOUNCE
|
10 | if (prescaler <= XTA % DEBOUNCE) |
11 | OCR1A += XTA / DEBOUNCE +1; // <-- rechne das mal aus! 87127040L/64= 1361360 - much too much |
12 | else
|
13 | #endif
|
14 | OCR1A += XTA / DEBOUNCE; // <-- s.o. |
15 | |
16 | }
|
data braucht übrigens nicht volatile sein
Hallo, Hier mal meine neue Datei. Irgendwie läuft der Timer wohl gar nicht mehr?! Zumindest ändert sich auf der Uhr nichts. Das hier musste ich machen, damit die Funktion wordclock noch ganz aufgerufen wird, denn sonst werden nur die ersten 2 Zeilen gemultiplext, die anderen bleiben aber aus. So funktioniert das. Kann es daran liegen und wenn: wie bekomm ich beides zum laufen.
1 | cli(); |
2 | if(aflag == 1) {assign(); aflag = 0;} |
3 | wordclock(); |
4 | sei(); |
Tim
Ich weiß bis heute nicht warum, aber bei vielen Codes sieht man, dass vor dem cli() das SREG gesichert wird und nach dem sei() wiederhergestellt wird. Hat das evtl was damit zu tun, dass der nicht mehr läuft?
@ Tim H. (hotty) Benutzerseite >Hier mal meine neue Datei. Irgendwie läuft der Timer wohl gar nicht >mehr?! Zumindest ändert sich auf der Uhr nichts. Tja, man sollte vielleicht mal bissel nachdenken. >Das hier musste ich machen, damit die Funktion wordclock noch ganz >aufgerufen wird, denn sonst werden nur die ersten 2 Zeilen gemultiplext, Ziemlicher Mist. Schon mal was von einem Timer gehört? Schon mal funktionierende Codes zum Thema LED-Matrix angeschaut? >cli(); >if(aflag == 1) {assign(); aflag = 0;} >wordclock(); >sei(); cli() uns sei() sind hier VOLLKOMMENER MIST! Damit sind die Interrupts so gut wie immmer gesperrt. Klar dass da kein Timer mehr läuft. Mach es doch einfach wie im Tutorial! MFG Falk
Ok ich schau mal. Aber kannst du mir kurz sagen was genau ich ändern soll. Danke schonmal. Tim
@ Tim Hotfilter (Gast) >Ok ich schau mal. Aber kannst du mir kurz sagen was genau ich ändern >soll. Pack das Multiplexen etc. in einen Timer, dort kann man auch problemlos die Uhr hochzählen lassen. Anstatt der for schleife mass man halt den Index normal hochzäglen und bei Erreichen des Maximums wieder bei 0 anfangen. MfG Falk
Tim H. schrieb:
> berrechnet (4915200*(1-(44/60))).
In Ganzzahl-Arithmetik gibt es da kräftige Rundungsfehler.
Hm? 44/60 ist 0. 0-1 ist -1. -1 mal 4915200 ist -4915200. Im Übrigen muss an die 4915200 ein L Suffix angehangen werden.
Mach dirs doch einfach und nimm einen Quarz mit 4,194304 MHz. Dann entfällt die ganze Rechnerei.
Anderen Quarz nehmen, damit man einfacher rechnen kann? Pff, Langweiler! ;) Übrigens ist der Code nach meinem Empfinden nach ziemlich grausam geschrieben :-)
mhhmm, hast Recht. Warum einfach, wenns auch umständlich geht. Da lernt man ja nix bei g
Ich weiß gar nicht, wer das Märchen mit den 22pF am Quarz erfunden hat?! Da gehören (beim HC49-U) laut Datenblatt 5..55pF dran. Bessere Genauigkeit habe ich zwischen 4 und 20MHz machgemessenermaßen mit 33pF erreicht. Wenn die Uhr genau sein soll, dann an XTAL2 33pF und an XTAL1 einen Trimmer der 33pF und leicht drüber hat. Dann kann mit einem ordentlichen Frequenzzähler genau abgestimmt werden. ;)
Diese Formel berchne ich doch nicht im Programm oder hast du die da etwa gesehen? Die hab ich auch dem Wiki und mit dem Taschenrechner ausgerechnet. Ich hab das multiplexing jetzt in den Timer gepackt und das läuft super. Trotzdem will die Uhrzeit nicht so wirklich -> Also gar nicht
Hallo, Ich hab jetzt den Fehler gefunden und es funktioniert: es heißt TIMER1_COMPA_vect und nich TIM1_COMPA_vect ... Tim
Thilo M. schrieb: > Ich weiß gar nicht, wer das Märchen mit den 22pF am Quarz erfunden hat?! > Da gehören (beim HC49-U) laut Datenblatt 5..55pF dran. Bessere > Genauigkeit habe ich zwischen 4 und 20MHz machgemessenermaßen mit 33pF > erreicht. Das Datenblatt! > Wenn die Uhr genau sein soll, dann an XTAL2 33pF und an XTAL1 einen > Trimmer der 33pF und leicht drüber hat. Dann kann mit einem ordentlichen > Frequenzzähler genau abgestimmt werden. ;) Die 22pF werden auch nur "pauschal" empfohlen. Es hängt stark von der Kapazität der Quarze ab, soweit ich weiß.
>Die 22pF werden auch nur "pauschal" empfohlen. Es hängt stark von der >Kapazität der Quarze ab, soweit ich weiß. Eher vom ESR und der Frequenz. ;)
Kann ich so nicht bestätigen. Das ATmega16 Datenblatt zum Beispiel sagt eindeutig ab 1MHz 12-22 pF.
http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=B41;GROUPID=3173;ARTICLE=32841;START=0;SORT=artnr;OFFSET=16;SID=32sAbNLawQASAAAE9yWmY95942f06a6fa47a377af9c833cfa788c -> Der Quarz + Datenblatt (Anhang) -> sagt 16pF -> Ist das überhaupt die Abblockkondensator Kapazität?
Hi >Na, das Datenblatt sagt's schon: >QMIM004,194 4.194.304Hz 32pF Davon muss man aber noch hardwarebedingte Kapazitäten abziehen. MfG Spess
Auch hier weis Atmel wiedereinmal Rat: http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Hier ist auch eine Berechnung für die Kondensatoren. Die 22-33 pF werden hier nur als gängige Werte die sich bewährt haben bezeichnet. Und was das Messen und dann ziehen angeht, es gibt Leute die nehmen dann das Signal direkt am Quarz, einige sind so "profesionell" und verwenden einen Tastkopf mit ca. 15 pF, andere machen es sogar direkte Klemmen. Aber der Abgleich soll dann stimmen ;) avr
Ich benutze den mega644 und die Fuse CKOUT und einen Trimmer-C an XTAL-1, dann bin ich unabhängig von der Last am Quarz. Die Uhren laufen perfekt. ;)
spess53 schrieb: > Hi > >>Na, das Datenblatt sagt's schon: >>QMIM004,194 4.194.304Hz 32pF > > Davon muss man aber noch hardwarebedingte Kapazitäten abziehen. Richtig! 10pF beim ATmega16 laut Electrical Characteristics (steht aber unter TWI, gilt aber sicher auch für andere Pins). Dann würden 22pF ja wieder hinkommen.
Wie gesagt, ich hab's mit 'nem sehr genauen Frequenzzähler ausgemessen. 33pF sind auch nicht 100% genau, aber um Längen besser als 22pF.
@ Thilo M. (power) >Wie gesagt, ich hab's mit 'nem sehr genauen Frequenzzähler ausgemessen. >33pF sind auch nicht 100% genau, aber um Längen besser als 22pF. [ ] Dir ist klar, dass die Kapazität vom QUARZ und nicht vom AVR abhängt. MFG Falk
Falk Brunner schrieb: > [X] Dir ist klar, dass die Kapazität vom QUARZ und nicht vom AVR > abhängt. Das habe ich weiter oben schon geschrieben. ;) >Dann lieber im Datenblatt des Quarzes schauen, nicht bei Atmel. ;)
Bitte 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.