Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.
Hinweis kann nach Kenntnisnahme deaktiviert werden!
Ich kenne das Tool ich werde wahrscheinlich ein RTC Signal benutzen ich hatte einen Quarzoszillator benutzt weil die genauer sind als ein Quarz für ein ähnliches Projekt,
natürlich hatte ich da Abweichungen warum auch immer.
Ich habe das Programm auf den Controller gespielt, es läuft tatsächlich rückwärts ich werde das Programm ausarbeiten.
mal sehen wich ich es auch Takte genau mit 1 Hz wahrscheinlich mit einem Uhrenquarz
Ich kenne das Tool ich werde wahrscheinlich ein RTC Signal benutzen ich hatte einen Quarzoszillator benutzt weil die genauer sind als ein Quarz für ein ähnliches Projekt,
natürlich hatte ich da Abweichungen warum auch immer.
Hallo Memory,
ich dachte du redest hier über einen "Kuzzeittimer", also bestimmt unter einem Tag.
Da kannst du doch keine wirklich bemerkbaren Abweichungen haben.
2-3 sec am Tag wären nach meinem Verständnis für einen normalen Quarz das höchste der Gefühle.
Also andere sollte in durch dein Programm hervorgerufen sein.
"Natürlich" sind die definitiv nicht, wenn die Abweichungen deutlich darüber liegen.
Zeige doch mal dein ganzes Programm, dann sieht man vielleicht, woran es liegt.
vielleicht liegt es daran das Handy und der Controller nicht synchron laufen, zum abgleichen.
Blinker an zwei verschiedene Autos blinken auch nicht synchron. Zwei drei Sekunden am Tag fallen eh nicht ins Gewicht für ein kurz Zeit Timmer.
In meinem Programm ist es vielleicht ungünstig 'config clock=soft' zu schreiben. Ich bin mir jetzt nicht sicher, ob da jetzt timer und anderer Schnickes eingerichtet wird, den man nicht braucht. Besser wäre vielleicht 'config clock=user'. Da muss man sich um den Takt selber kümmern (was du ja machen willst), es werden aber die Variablen für eine clock bereit gestellt.
Alles im Konjunktiv, weil ich mir nicht 80% sicher bin. Kannst du das mal probieren?
Ich hab' jetzt mal einen interrupt mit timer1 zusammengebastelt. Hast du ein 4MHz Quarz dran? Wenn ja, dann überprüfe doch mal die Genauigkeit über eine längere Zeit in meinem Programm ist jetzt mal 1 Stunde vorgegeben.
@'tschoeatsch
Du hast dieses Timer Tool zur Berechnung verwendet und dann den Compare Mode verwendet.
Das sieht man auch selten.
Finde ich gut. Leider habe ich den Daumen beim falschen Post gehoben.
Und zwei bekommst du dafür nicht.
Danke. Bei dem tool finde ich die Erklärung ganz gut. Deswegen setze ich die auch gerne in das Programm mit ein. Ich bin mir aber nicht ganz sicher, ob man bei x ticks das compare auf x-1 (so wie ich es hier gemacht habe) einstellen muss. Der timer fäng bei 0 an, bei 1 hat er also 1 tick gemacht. Wenn jetzt compare=1 wäre, würde er wieder bei 0 beginnen. So gesehen müsste das -1 eigentlich falsch sein, oder doch richtig?
Hm, der Tackt verstreicht und der Timerzähler erhöht sich, die Zahl gibt also die verstrichenen Takte an. Wenn die Zahl mit dem compare-Wert überein stimmt, wird sie auf 0 gesetzt, dann verstreicht die Zeit, bist der 0. Tackt vorbei ist. So gesehen müsste doch x statt x-1 beim compare drin stehen.
Hm, ich muss sagen, ich hatte Startschwierigkeiten. Nach dem Einschalten musste ich einen reset machen, damit die Anzeige ansprang.
Was bei diesem Programm ungünstig ist, in der isr wird eine long-Variabe geändert, die in der main durch eine aufwändige Rechnung zerzupft wird. Probiere mal
zeit1=zeit
bsec=time(zeit1)
So kann die isr in die Zerlegung von zeit1 reinplatzen, was aber an zeit1 nix ändert. Vorher war das ungünstiger. Vielleicht ist das schon die Lösung.
ich hatte Startschwierigkeiten. Nach dem Einschalten musste ich einen reset machen, damit die Anzeige ansprang.
Ist bei mir jetzt behoben. Ich arbeite mit internen RC-Oszillator. Ich hab' jetzt bei den fuses eine längere Verzögerung eingestellt und jetzt läuft nach dem Einschalten das Programm gleich los, so wie es ja sein soll.
Ich würde die ISR und die Anzeige einfach synchronisieren.
Dazu in der ISR ein Flag setzen und in der Do-Loop auf das Flag warten, dann die Zeit runterzählen und die ganzen Berechnungen machen. Du hast ja schließlich fast eine Sekunde Zeit, in der sonst nichts passiert.
Sorry, mal kurz OT, ich bin jetzt etwas verwirrt.
Ich bin gerade am Bau eines Frequenzmessers, mit Quarz klappt das soweit alles.
Als genaue Zeitbasis wollte ich DCF77 nehmen, dazu eventuell gleich den Attiny mitverwenden, ADC Gain x20 um mir den Sekundentakt eventuell damit aufzubereiten.
VCO mit den 77,5 kHz Synchronisieren sollte dann das nächste sein.
Die Google Suche führt auch in diesen Tread, und ich lese gleich zweimal, DCF77 gibt kein Sekunden-Signal aus.
Laut Wiki ist das Signal immer noch im Sekundentakt Amplitudenmoduliert was ich auswerten wollte, das digitale Signal interessiert mich erst mal (noch) nicht.
Hat sich da etwas geändert?