R8C - ich hatte noch keine Zeit

Wo ist das Problem? Ohne den "R8C" zu kennen... µC-internen Timer aufsetzen, der
periodisch einen Interrupt auslöst, z.B. jede 10ms. Bei jedem Interrupt Zählerkette
hochzählen, ein Byte für die Interrupts, bei dessen Überlauf (100) ein Byte für die
Sekunden, bei dessen Überlauf (60) das nächste für die Minuten, das nächste für die
Stunden, das letzte für die Tage - passt alles in jeweils ein Byte, und reicht für
den angegeben Zeitraum. Auf diese Art und Weise kannst Du fast beliebig lange Zeiträume
erfassen, bis zum Mehrfachen des Universumalters.

Im Baseband (Hauptprogramm in einer Endlosschleife) den abzufragenden Pin pollen, letzten
Zustand in Variablen speichern, bei Zustandswechsel (eventuell mehrfach verzögert pollen
zum Entprellen) obige Zählerkette auslesen (*), und in NV-Bereich wegschreiben, mit Art
des Pegelwechsels. Ebenfalls aktuelle Schreibadresse des NV-Bereich nachhalten.
Saubere Initialisierung der Variablen nicht vergessen! (klassischer Fehler)

Zweiten Pin ebenso pollen, und bei Zustandswechsel den NV-Bereich vom Anfang bis
zur oben gespeicherten Adresse auf die UART rausschreiben.
Auf diese Art hast Du einen Timestamp ab Einschalten. Falls Du absolute Zeit
brauchst, dem µC eine externe RTC zur Verfügung stellen, von Philips gibt es
da I²C auslesbare RTCs, PCF-irgendwas (Initialisierung mit aktueller Uhrzeit für die
RTC vorsehen) (**). Wenn Du mit absolutem Timestamp arbeitest, kann man als Verfeinerung
noch beim Starten den NV-Bereich auslesen, um alte Timestamps nicht zu überschreiben - das
hängt von der Anwendung ab.
Falls Du mit RTC arbeitest, die immer in UTC laufen lassen, dann gibt es keinen Ärger
mit DST.

Ist ne schöne Fingerübung!

Edit, vergessen:

* Beim Auslesen die Interrupts sperren, sonst kann es während des Auslesens im
Baseband einen Interrupt geben, der den Timestamp verfälscht. Interrupts disablen,
Timestamp in lokale Kopie speichern, Interrupts enablen (Interrupts nie länger als
absolut nötig disablen).

** I²C spart Portpins gegenüber RTC mit parallelem Bus, musst halt nur das I²C-
Protokoll in Software implementieren - easy.

Besser 100ppm für einen Controllertakt? Na Du hast Ansprüche An die 100 mal gleich? 1ppm? In meinem Zähler steckt für 5ppm ein Ofen, kann es sein, dass Dein Projekt ein bisschen an der Realität vorbei läuft?

Verstehe ich auch nicht, ist alles gesagt.
Wieso den XTAL so genau bestimmen? Wenn als zeitliche Auflösung Minuten reicht,
laut Aufgabenstellung, wo ist dann das Problem? Selbst unabgeglichen dürfte die
Abweichung in 5 Wochen nicht überschritten werden.
Warum vier Eingänge? Zwei reichen doch.
Implementierung in C oder Assembler überlasse ich Dir...

5 Wochen sind 50400 Minuten, für eindeutige Genauigkeit von 1min reicht es also, dass die Uhr in dieser Zeit nicht mehr als 30s wegdriftet - das sind knapp 10ppm. Mit einem 32768Hz-Schwinger an einem der übllichen RTC-ICs abgeglichen kein Problem, es gibt auch fertig abgeglichene ICs mit integriertem Quarz (ich hab damals den Seiko-Epson RTC72421 verbaut) für Leute ohne genaue Referenz. Die Temperaturstabilität ist übrigens deutlich mieser, beim Einsatz bei mehr oder weniger konstantem Temperaturgradienten sollte man das also berücksichtigen, wenn es auf die Minute ankommt.

Bedenke bitte den Temperaturdrift des Quarzes, da kommst Du schnell in die Größenordnung von Minuten in Deinen 5 Wochen. Oder ist der Einsatzbereich wohltemperiert und schwankt um einen festen Mittelwert? Dann solltest Du aber auch bei der Temperatur nochmal die Frequenz genau messen.

shaun: Ich hatte keine Lust, es auszurechnen... :O
Ja, die Epson-RTC sagt mir was, gibt es die denn noch? Dallas (jetzt zu Maxim
gehörend) macht noch schöne all-in-one RTCs, also inklusive XTAL und Batterie,
mit parallelem Bus. Bei den RTCs mit externem XTAL muß man die Kapazitätsbürde
genau an den ausgewählten 2^15Hz XTAL anpassen, sonst ist man eh völlig daneben
(da ist ein Kollege mal reingefallen).

ffje: Wie hast Du die XTAL-Frequenz gemessen? Hat der R8C einen gepufferten
Oszillatorausgang? Falls nicht, und falls Du direkt am XTAL gemessen hast, hast
Du durch die kapazitive Belastung bereits die Frequenz verschoben...
Falls Du die durch die Störstrahlung mit dem ICF gemessen hast, wie genau ist
die Timebase des ICF?
Wenn Du es langzeitgenau haben willst, kannst Du ein DCF-Modul von Meinberg
anschliessen. Da aber der Empfang nicht immer gewährleistet ist, musst Du noch
parallel eine XTAL-gesteuerte Uhr µC-intern mitlaufen lassen, und einen Synchro-
nisationsmechanismus vorsehen... wird dann etwas aufwändiger.

Aber die einzige Möglichkeit, um die geforderte Genauigkeit zuverlässig zu erreichen. Ob nun DCF, GPS oder sonst irgendein Standard, nur mit Oszillator wird das nichts mit 1 Sekunde auf 5 Wochen.

Grrr, und wir diskutieren hier seit ner Woche über eine Präzisionsuhr. Hättest ja mal was sagen können, wenn Du mit 0,011% Abweichung schon leben kannst. C ist strukturiert, Pascal ist eine Katastrophe. Wenn man Pascal mal zu irgendwas gelernt hat, kehrt sich die Sichtweise um. Ich habe neulich in einem Seminar selbst mal kurz ein Pascal-Progrämmchen geschrieben, grausam. Seit zehn Jahren kein Wort in dieser Sprache gesprochen und dann "machense mal"

shaun, nicht ärgern! Dass man den Fragestellern das Pflichtenheft aus der Nase
ziehen muß, ist nichts Neues.

Das mit dem Pascal kann ich bestätigen ("Wer nichts wird, wird Wirth"). Alleine
diese unsinnige Unterscheidung zwischen procedures und functions. Keine Pointer-
arithmetik, Adressreferenzierung. Strikte Typenwahl, ohne Cast-Möglichkeit.
Zudem ist diese Sprache, gerade mit OOP-Aufsätzen wie Delphi, völlig proprietär
und plattformgebunden.

C bietet, gerade für hardwarenahe Programmierung, geniale Bitoperatoren.
Im Prinzip ist das ein "Hochsprachen-Assembler", mit sehr vielen Freiheiten, aber
auch sehr hoher Selbstverantwortung.

Mag sein, dass das in Modula2 geht... aber es gibt kaum irgendetwas
programmierbares auf diesem Planeten, für das es nicht einen C-Compiler
gibt... vom Z8 vielleicht mal abgesehen.

Wozu brauchst Du unsigned long, und wie groß soll das array sein? Hat der R8C
soviel RAM?
Mit den Typecasts hast Du Dich schon angefreundet? Kannst auch das
array als union anlegen, einmal vom Typ unsigned char, einmal als unsigned
long, dann ersparst Du die Konversion. C ist geil!!!!!!!!!