Hallo liebe Community, derzeit sitze ich an einer "fast" uralten Hardware (>25 Jahre alt) und versuche folgendes Problem zu lösen: Eine Elektronik, die von mehreren Schaltkanälen die Zustandsmeldung erfasst und dann auf einem kleinen Speicher mit Datum und Uhrzeit abglegt. Bis zum 31.12.2023 funktionierte das einwandfrei, aber nun ist er zurückgesprungen auf 1992. Jetzt habe ich aus dem ProgrammEprom (27c256b) das Programm ausgelesen, was mir aber leider nicht viel weiter hilft, da ich den Programmcode nicht entschlüssen kann. Auf der Platine befindet sich aber u.a. auch der PCF8583, welcher über I2C an einen P80C528 angeschlossen ist. Nur um dies als mögliche Ursache auszuschließen - ist euch bekannt, ob der Clock-Chip hier das Problem ist? Aus dem Datenblatt kann ich das zumindest nicht als Ursache ableiten, aber ich möchte lieber nachfragen. Von dem Board hab ich mehrere im Einsatz und bei allen tritt das Problem identisch auf. Uhrzeit und Funktion sind nicht beeinflusst - alles läuft, nur das Jahr stimmt im Log nicht mehr. Leider habe ich keine Schaltungsunterlagen dazu. Vielen Dank für euer Feedback.
Michael S. schrieb: > Bis zum 31.12.2023 funktionierte das einwandfrei, aber nun ist er > zurückgesprungen auf 1992. 2023 - 1992 = 31 Scheint so als würde irgendwer (der Uhrenchip?) das Jahr nur mit 5 Bit erfassen und dann stur 1992 + X rechnen.
Axel S. schrieb: > Scheint so als würde irgendwer (der Uhrenchip?) das Jahr nur mit 5 Bit > erfassen Es sind sogar nur zwei, siehe S. 7, Bild 7: https://www.nxp.com/docs/en/data-sheet/PCF8583.pdf
Michael S. schrieb: > Nur um dies als mögliche Ursache auszuschließen - ist euch bekannt, ob > der Clock-Chip hier das Problem ist? Aus dem Datenblatt kann ich das > zumindest nicht als Ursache ableiten, aber ich möchte lieber nachfragen. Doch, kannst Du. Auf Seite 7 Fig. 7 siehst Du, dass für das Jahr nur 2 Bits vorhanden sind. Die RTC zählt also immer nur von 0 bis 3 und springt dann wieder auf 0 zurück. Das siehst Du auch auf Seite 9 Table 4: "year 0 to 3". Heißt also: Die RTC ist unschuldig. Die Firmware hat irgendwo das komplette Jahr gespeichert (oder zumindest weitere Bits) und zählt die bei einem Überlauf von 3 auf 0 in der RTC weiter. Die Firmware ist es auch, die von 2023 wieder auf 1992 zurückspringt, denn die RTC kann es nicht. Ändere die Firmware, und Dein Problem ist erledigt. Leichter gesagt als getan, ich weiß. Aber das wäre die einzige Möglichkeit. fchk
Wow so schnell Feedback - Danke euch sehr. Ok, da hatte ich das Datenblatt nicht richtig verstanden - aber eure Hinweise haben mir da sehr geholfen und wieder was gelernt :) Nun habe ich zumindest einen guten Ansatzpunkt zum weitermachen (Umsetzung wird ne schöne Lernkurve). Hab schon versucht das die ausgelesene .bin aus dem EPROM zu dekompilieren via dogbolt (Decompiler Explorer), was aber leider nicht geklappt hat...
Das wird dann vermutlich an dem Controller liegen, dass der aus den 2 bits intern irgendwie gescheit mehr bits macht. Vielleicht wird das komplett intern gehandelt, und das Jahr aus dem RTC einfach ignoriert. Und beim überlauf von Dez 31 auf Jan 1 einfach intern ein Zähler inkrementiert. Oder der holt sich den bits aus dem RTC und baut noch extra bits intern nach. Man müsste immerhin gucken ob die 2 bits überlaufen sind. Wenn ja dann intern den Zähler hoch zählen. Und auf den Jahr zu kommen, dann den bit aus den RTC nehmen (2) pluss die bits die man intern hat (3?). Daraus baut man halt den 5 bit wert. Wieso 5 bits? Wieso dann nicht 8? Oder nur 4? Ich meine bei einer 8 bit controller, wer würde dann aus einer byte dann nur 5 bits für den Jahr spendieren? Was passiert mit den restlichen bits? Man muss beim Zugriff dann halt immer den Wert maskieren und aufpassen. Klar wenn man kein RAM hat, dann zählt jedes Byte.
tja und ich seh auch grad im datasheet (ich muss langsamer lesen ;) ) Features and benefit: Clock function with four year calendar öhm....hab grad überlegt "warum?"...somit wird das Schaltjahr mit integriert.
Michael S. schrieb: > ist euch bekannt, ob > der Clock-Chip hier das Problem ist? Nein, der arbeitet einwandfrei. Das Problem steckt in der Firmware für das 80C51-Derivat. Die wird vermutlich mit dem Keil C51 erstellt worden sein. Das ist quasi wie das Jahr-2000-Problem, nur in klein. Michael S. schrieb: > Jetzt habe ich aus dem ProgrammEprom (27c256b) das Programm ausgelesen, > was mir aber leider nicht viel weiter hilft, da ich den Programmcode > nicht entschlüssen kann. Ja, das sind nur Assembler-Befehle, daraus kriegt man keinen lesbaren Quellcode zurück. Man müßte die Firmware aus der Funktionsbeschreibung neu schreiben. Heutige Programmierer hätten allerdings zuviel Angst, daß ein 80C51 das unmöglich wuppen kann. Die würden nicht unter Cortex M3, 1MB Flash, ab 72MHz anfangen.
Michael S. schrieb: > Bis zum 31.12.2023 funktionierte das einwandfrei, aber nun ist er > zurückgesprungen auf 1992. Mal ganz blöd gefragt: Läßt sich die Uhr manuell auf 2024 stellen oder ist irgendwo eine Batterie leer?
Peter D. schrieb: > Ja, das sind nur Assembler-Befehle, daraus kriegt man keinen lesbaren > Quellcode zurück. > Man müßte die Firmware aus der Funktionsbeschreibung neu schreiben. > > Heutige Programmierer hätten allerdings zuviel Angst, daß ein 80C51 das > unmöglich wuppen kann. Die würden nicht unter Cortex M3, 1MB Flash, ab > 72MHz anfangen. ghidra kann da helfenden zu verstehen. Ich vermute mal, dass man den disassembly mit ghidra vielleicht so weit lesbar machen kann, dass man die Stelle findet, wo das Ding auf das Jahr 1991 addiert. Dann muss man den 1991 halt einfach umschreiben. Das schafft man auch in einer Notepad direkt im HEX datei im notfalls.... Also firmware auslesen und hier hochladen. Dann kann man da reinschauen ob man da etwas auf die schnelle fixen kann.
Axel S. schrieb: > 2023 - 1992 = 31 Da hat sich wohl der Programmierer gedacht, in 31 Jahren arbeite ich eh nicht mehr bei dem Haufen. Man könnte nun alle Stellen mit 1992 durch 2024 ersetzen für die nächsten 32 Jahre. Ist allerdings nicht ganz einfach, da das ein 8Bitter ist. D.h. der Wert kommt nicht direkt im Code vor, sondern wir z.B. als 16Bit Addition verwendet:
1 | mov a, r7 |
2 | add a, #low(1992) |
3 | mov r7, a |
4 | mov a, r6 |
5 | addc a, #high(1992) |
6 | mov r6, a |
Kann aber auch sein, daß nicht binär gerechnet wird, sondern in packed BCD. Assemblerprogrammierer machen das gerne, um die Umrechnung in Digits bei der Anzeige zu ersparen. C-Compiler rechnen nur binär.
echt coole Tipps. Das mit der Batterie hab ich geprüft - daran liegts nicht. Ghidra hab ich mir installiert und versuche nun, da erfolgreich zu decompilieren. Mal schauen wie weit ich komme - jeder eurer Hinweise hilft super - vielen Dank an euch.
Kannst ja mal das Hex hier reinstellen, dann kann man einen Blick drauf werfen. Man kann auch das Hex im SIM51 durchsteppen.
Hi, also mit Ghidra komme ich nicht weiter - ehrlicherweise fehlt mir hier das Verständnis des Umgangs mit dem, was das Programm da anzeigt. Daher anbei mal 2 Dateien. Ausgelesen habe ich die Daten mit dem GQ-USB-Programmer. Ab Adresse 00001720 sieht es für mich nach Uhrzeit/Datums-Handling aus (zumindest für meinen Laienhaften Blick an der Stelle).
mal ein paar Adressen: main 0x00DC I2C Low Level ab 0x5C20 C runtime ab 0x6800 Die Uhr wird über 0xA0 adressiert (0x50 in 7 Bit Adressierung) Bei 0x38F4 könnte das Jahr ausgewertet werden. Das müsste man aber genauer anschauen. Wenn ich das richtig interpretiere werden dort 4 Bytes vom RTC ab Adresse 0x02 gelesen. Die Daten landen in einem Buffer idata:0xC7 Der Code ist mit einem relativ alten Keil C51 übersetzt worden. Ich tippe auf eine 4er Dos version. Jedenfalls vor uVision.
Ein paar der relevanten Routinen für Datum/Uhrzeit:
1 | 0x4134: Uhr setzen, verwendet scanf (0x71FE) |
2 | 0x3EDB; Jahr umrechnen, u.a. dort gibt es den Offset "92" (vermutlich Startjahr 1992) |
3 | 0x4658: Auch hier wird mit dem Offset "92" gearbeitete und mit dem Datum |
4 | 0x5C20: I2C write |
5 | 0x5C38: I2C read |
6 | 0x5CD8: I2C write mit DPTR |
7 | 0x5CF4: I2C read mit DPTR |
8 | 0x5CBA: I2C read Byte, wird für I2C Adresse 0x40 verwendet |
Ich kann kein Assembler, aber ich bin immer wieder von solchen Beiträgen fasziniert. Wie hier geballte Kompetenz ein Problem in nullkommanix erledigen. Hier haben vor langer Zeit ein paar Jungs eine Heizung komplett dekodiert. Habe davon fast nichts verstanden, aber es war toll, dass die das komplett aufgebröselt haben. Ich gehe mal davon aus, dass die meisten die hier gepostet haben, sicher 50+ oder auch schon 60+ sind. Außer euch zu applaudieren, kann ich also nicht viel machen.
Ein Update bzw. Korrektur zu den Adressen weiter oben.
1 | 0x3F78: Uhrzeit/Datum anzeigen, bei Bedarf das Jahr im PCF8583 RAM |
2 | aktualisieren, verwendet printf (0x6D87) |
3 | 0x4134: Uhrzeit/Datum setzen, verwendet scanf (0x71FE) |
4 | 0x3EDB: Wochentag aus Jahr, Monat und Tag berechnen, Basis 1.1.1992 |
5 | 0x437B: Alarm setzen |
6 | |
7 | Das Jahr (zwei Stellen) wird im RAM des PCF8583 abgelegt: |
8 | |
9 | PCF8583 RAM adresse 0x10: Jahr - (Jahr & 3) |
10 | PCF8583 RAM adresse 0x11: (Jahr & 3), steht auch in den Jahr-Bits der RTC |
Momentan sehe ich noch nicht wo es bei den obigen Funktionen zu der Beschränkung des Jahres auf 1992 bis 2023 kommt. Aber es gibt noch andere Stellen die das Datum behandeln.
:
Bearbeitet durch User
Dieter S. schrieb: > Momentan sehe ich noch nicht wo es bei den obigen Funktionen zu der > Beschränkung des Jahres auf 1992 bis 2023 kommt. Es muß ja irgendwo einen Jahres-Offset von 1992 (bzw. 0x07C8) und eine Maske 0x1f geben, die das angezeigte Jahr festlegen. Vielleicht ist das zu finden?
Mi N. schrieb: > > Es muß ja irgendwo einen Jahres-Offset von 1992 (bzw. 0x07C8) und eine > Maske 0x1f geben, die das angezeigte Jahr festlegen. Vielleicht ist das > zu finden? So wie ich das bisher verstanden habe wird nicht mit einer vierstelligen Jahreszahl gearbeitet. Es wäre hilfreich wenn man wissen würde wie die Jahreszahl bzw. Datum/Uhrzeit bei dem Gerät angezeigt bzw. verarbeitet wird. Vielleicht kann der TO diese Information noch liefern. Den Offset "92" sehe ich mehrfach, da gibt es aber keine Beschränkung des Jahres auf 5 Bit. Und auch eine 5-Bit Maskierung ist mir bisher nicht im Zusammenhang mit dem Jahr aufgefallen Was es noch bezüglich Uhrzeit/Datum gibt:
1 | 0x4658: Uhrzeit/Datum in 32 Bits speichern (Ergebnis im RAM (0x89..0x8C) |
2 | |
3 | MSB |
4 | Jahr (6 Bits) |
5 | Monat (4 Bits) |
6 | Tag (5 Bits) |
7 | Stunde (5 Bits) |
8 | Minute (6 Bits) |
9 | Sekunde (6 Bits) |
10 | LSB |
Mit dieser Zeit (RAM 0x89..0x8C) wird an vielen Stellen im Code gearbeitet aber auch da sehe ich bisher noch keine Beschränkung. Die 6 Bits für das Jahr sollten ja ausreichen und so wie es bisher aussieht werden die 32-Bit als "unsigned" behandelt, eventuelle Probleme durch ein Vorzeichen sollte es also nicht geben. Es gibt allerdings eine Stelle bei der etwas mit dem MSB dieser 32-Bit Zahl gemacht wird, da habe ich aber noch nicht komplett verstanden was da genau passiert.
Dieter S. schrieb: > Es gibt allerdings eine Stelle bei der etwas mit dem MSB dieser 32-Bit > Zahl gemacht wird, da habe ich aber noch nicht komplett verstanden was > da genau passiert. Das Ding soll ja die Schaltzeiten mitloggen. Das MSB könnte daher ein/aus kodieren.
Peter D. schrieb: > Das Ding soll ja die Schaltzeiten mitloggen. Das MSB könnte daher > ein/aus kodieren. Vielleicht, das könnte auch der Grund für die begrenzte Jahreszahl sein. Aber es würde noch die Kanalnummer fehlen. Ein pragmatische Lösung könnte sein, anstatt 2024 'nur' 2004 einzustellen und dann 20 Jahre zu addieren. Dafür gibt es bestimmt eine APP ;-)
Das was ich bisher bezüglich einer möglichen Beschränkung auf 5-Bit beim Jahr sehe passiert in der Funktion Adresse 0x08A0. Dort wird das MSB der 32-Bit Zeit/Datum gesetzt und dieser Wert dann im externen RAM (MOVX) Adresse 0x0003 gespeichert. Ich sehe allerdings bisher nicht was damit gemacht wird, diese Adresse im externen RAM wird öfters verwendet, z.B. wird an anderes Stelle auch mal die 32-Bit Zeit/Datum direkt ohne Modifikation dort gespeichert. Sollte also das MSB der 32-Bit Zeit/Datum an der Adresse 0x0003 im externen RAM (eventuell ist das ja auch IO) eine spezielle Bedeutung haben dann wäre das eventuell die Beschränkung der Jahreszahl. Als mögliche Lösung könnte man die Firmware u.U. so patchen dass das Basisjahr 1992 verschoben wird. Das geht aber nur wenn es keine alten Daten/Werte gibt die irgendwo in dem Gerät gespeichert sind und deren Zeitstempel dann nicht mehr stimmt. Mir fehlt allerdings der Überblick was das Gerät genau macht (z.B. findet man ja in der Firmware auch einen Disketten Bootsektor, also werden wohl auch Werte extern ausgegeben) um zu beurteilen ob so eine Verschiebung des Basisjahr 1992 keine Komplikationen verursacht.
@Frank O. - dem kann ich nur zustimmen. Naja, ich hab auch schon über ein halbes Jahrhundert hinter mir, aber bin darin leider "noch" nicht firm. @Mi N. - das Offset müsste man idealerweise auf 2020 legen. Alle 28 Jahre wiederholt sich der Kalener 1:1, wobei das hier nicht mal notwendig wäre, da der Wochentag keine Rolle spielt. Aber so wäre noch Reserve ;) @Dieter S. - Das Datum wird im Format DD.MM.YY eingegeben. Die Daten werden auf einer kleinen Flashcard gespeichert. Langzeitdaten über Jahre hinweg gibts da nicht. Gespeichert wird immer Datum, Uhrzeit und Schaltzustand des Eingangs.
Michael S. schrieb: > > @Dieter S. - Das Datum wird im Format DD.MM.YY eingegeben. Die Daten > werden auf einer kleinen Flashcard gespeichert. Langzeitdaten über Jahre > hinweg gibts da nicht. Gespeichert wird immer Datum, Uhrzeit und > Schaltzustand des Eingangs. Wie sieht die Ausgabe des Datum aus? Am besten ein Beispiel hier zeigen. Und wie werden die Daten von der Flashcard ausgewertet? Ich kann in der Firmware nicht erkennen dass z.B. Text Dateien erzeugt werden. Ist eine spezielle Software zum Auswerten der Daten auf der Flashcard erforderlich?
Das hat zwar nichts mit dem Datum zu tun, aber dafür dass die Firmware nur Schaltzustände erfasst rechnet sie ziemlich viel mit Floating-point, z.B. die Funktion Adresse 0x1C76. Die entsprechenden Floating-point Funktionen stehen hier:
1 | 0x5FDC: Float Sub |
2 | 0x5FE0: Float Add |
3 | 0x60EB: Float Mul |
4 | 0x6163: Float Div |
5 | 0x6212: Float Compare |
6 | 0x6276: 32 Bit in Float umwandeln |
7 | 0x627A: 16 Bit in Float umwandeln |
8 | 0x627E: 8 Bit in Float umwandeln |
9 | 0x62B2: Float in 16 Bit umwandeln |
Hi ds1, die FloatingPoint Berechnung würde vermutlich für die 1 (oder 2) analogen Eingänge genutzt werden können (müsste da am Freitag nochmal drauf schauen wenn ich wieder heim bin). Ansonsten kann ich mir da keinen Reim drauf machen. Auf der Karte liegen die Daten als File und ich habe dazu ein Programm, was die Karte dann ausliest. Das File kann man nicht direkt lesen. Ich dachte auch erst, dass ich beim einlesen das "anpassen" bzw. ein Offset einstellen kann, aber da gibts keine Möglichkeit. Im Programm wirds dann einfach in csv gewandelt und ergibt praktisch Datum, Uhrzeit, Schaltkanäle, jeweiliger Zustand. Tja und einfach nur das Jahr in der csv ändern wäre auch denkbar - aber es muss doch auch anders gehen und ehrlich gesagt freu ich mich schon drauf, die alte UV-Röhre wieder einzuschalten ;) Mit Ghidra hab ich einiges getestet, aber ich komme nicht mal ansatzweise auf deine Informationstiefe. Geht dein Weg über Ghidra, oder machst Du das ganz anders?
Michael S. schrieb: > Das File kann man nicht direkt lesen. Auf den ersten Blick wird die Karte mit FAT12 beschrieben. Lass dir mal auch die Files mit hidden und System Attribut anzeigen.
Michael S. schrieb: > > Auf der Karte liegen die Daten als File und ich habe dazu ein Programm, > was die Karte dann ausliest. Das File kann man nicht direkt lesen. > Ich dachte auch erst, dass ich beim einlesen das "anpassen" bzw. ein > Offset einstellen kann, aber da gibts keine Möglichkeit. Genau die beiden Dinge (was steht auf der Karte und das Programm) sind interessant bzw. wichtig: Kannst Du von der Karte ein Image machen (mit irgendeinem der vielen Tools die den kompletten Inhalt von der Karte/Laufwerk lesen)? Wenn man das Image dann komprimiert (z.B. mit 7ZIP) bleibt vermutlich nicht sehr viel übrig und man kann es hier problemlos hochladen. Das selbe gilt für das Programm: bitte hier hochladen. Ich frage deshalb weil ich vermute dass auch das Programm bei dem Problem mit dem Datum mitspielt. Um das zu prüfen brauche ich das was auf der Karte steht und das Programm. > Mit Ghidra hab ich einiges getestet, aber ich komme nicht mal > ansatzweise auf deine Informationstiefe. Geht dein Weg über Ghidra, oder > machst Du das ganz anders? Es hat nichts mit dem Tool zu tun, egal ob Ghidra, IDA Pro oder was anderes: es hängt von der Erfahrung desjenigen ab der das Tool verwendet. Die Tools sind nur ein Werkzeug, von alleine machen die erstmal nicht viel mehr als ein einfacher Disassembler.
:
Bearbeitet durch User
Nochmal zu dem was auf der Karte steht und dem Programm: so wie ich das bisher in der Firmware verstehe wird in Dateien geschrieben (die entsprechenden Funktionen habe ich inzwischen gefunden). Allerdings ist das relativ sicher ein Binärformat und das Programm macht die Umwandlung. Daher wird das Problem mit dem Datum sehr wahrscheinlich auch das Programm betreffen, eventuell kann es auch nur da behoben werden. Daher wie schon geschrieben bitte das Programm und den Inhalt der Karte hier hochladen.
Axel S. schrieb: > 2023 - 1992 = 31 2024 - 1992 = 32 In einer binären Welt macht das deutlich mehr Sinn. Michael S. schrieb: > Bis zum 31.12.2023 funktionierte das einwandfrei, aber nun ist er > zurückgesprungen auf 1992. Und wie benimmt sich der Wochentag? Ist der passend für das Jahr 2024 oder entspricht der dem vom Jahr 1992?
Rainer W. schrieb: > Axel S. schrieb: >> 2023 - 1992 = 31 > > 2024 - 1992 = 32 > > In einer binären Welt macht das deutlich mehr Sinn. Nein, es ergibt keinen Sinn, denn die 32 Zustände sind 0 - 31.
Mi N. schrieb: > Nein, es ergibt keinen Sinn, denn die 32 Zustände sind 0 - 31. Eben, die Differenz zwischen dem tatsächlichen Jahr und dem angezeigten ist 32, d.h. es spricht vieles dafür, dass da irgendwo ein übergelaufener 5-Bit Zähler/Speicher im Spiel ist, wie oben schon bemerkt. Michael S. schrieb: > Nur um dies als mögliche Ursache auszuschließen - ist euch bekannt, ob > der Clock-Chip hier das Problem ist? Das könntest du nachmessen. Wenn im PCF8583 irgend etwas verbockt ist (alte Version mit Maskenbug), müssten falsche Jahreszahlen vom PCF8583 kommen. Sonst liegt es an der "fast" uralte Hardware, die einen Controller mit FW für einen arg begrenzten Datumsbereich enthält, z.B. um beim Abspeichern Platz zu sparen.
:
Bearbeitet durch User
Michael S. schrieb: > Das File kann man nicht direkt lesen. Warum nicht? Wenigstens ein Hexdump sollte doch möglich sein, falls das reine Binärdaten sind. JSON o.ä. hat damals noch kaum einer verwendet.
Und nochmal zu dem Programm und dem was auf der Karte steht: das Programm ist ziemlich sicher wichtig wenn es um die Funktion des Geräts geht. So wie es bisher aussieht formatiert das Programm die Karte so dass sie vom Gerät akzeptiert wird. Außerdem werden vom Programm ein oder zwei Dateien angelegt (die zweite Datei ist optional), am Anfang dieser Dateien stehen diverse Konfigurationswerte (Binärformat) die das Gerät dann verwendet. Werte die das Gerät abspeichert werden sehr wahrscheinlich an diese Dateien angehängt. Vermutlich setzt das Programm das "Hidden" Attribut der Dateien, zumindest akzeptiert die Firmware auch Dateien mit dem "Hidden" Attribut. Die Datei Extension könnte eventuell ".DAR" sein. Was ebenfalls nett wäre sind Bilder vom Gerät damit man einen besseren Eindruck bekommt.
Dieter S. schrieb: > Was ebenfalls nett wäre sind Bilder vom Gerät damit man einen besseren > Eindruck bekommt. Wohnt Du in einem Hochwassergebiet? Bei der vielen Zeit, die Du hier aufbringst: Wäre jetzt nicht der richtige Zeitpunkt, wo Du das Programm 'eben mal' selber neu schreibst? :-) Rainer W. schrieb: > d.h. es spricht vieles dafür, dass da irgendwo ein > übergelaufener 5-Bit Zähler/Speicher im Spiel ist, wie oben schon > bemerkt. Alternativ vielleicht auch nur ein 3 Bit Zähler, der um die 2 Bit Jahreszahl im PCF8583 ergänzt wird. 1992 war ja ein Schaltjahr, wo der PCF-Zähler mit 0 beginnen konnte. Selber hatte ich seinerzeit einen separaten Zähler verwendet, der mit dem Schaltjahrzähler bei jedem Neustart synchronisiert wurde, wenn ein Jahresüberlauf stattgefunden hatte. Der geht zwar nur von 0 - 99, aber wenn das auffällt bin ich längst woanders ;-)
Mi N. schrieb: > > Alternativ vielleicht auch nur ein 3 Bit Zähler, der um die 2 Bit > Jahreszahl im PCF8583 ergänzt wird. Das ist doch bereits mit ziemlich großer Wahrscheinlichkeit geklärt, siehe weiter oben. Zwei Stellen der Jahreszahl stehen im RAM des PCF8583 und werden von der Firmware aktualisiert. Die Firmware selbst arbeitet mit Uhrzeit/Datum in einem 32-Bit Wert, davon 6 Bits für das Jahr. Das Problem mit der Jahreszahl kommt ziemlich sicher in erster Linie durch die Umwandlung der Daten auf der Karte durch das Programm und muss dort behoben werden.
Angehängte Dateien:
-
Datenrecorder_MC-B31.png
230 KB
Es könnte bei dem Gerät in diese Richtung gehen (siehe Bild), laut Firmware ist es ein MC-B21. Das Progamm ist dann vermutlich DAREC.
Hallo, im Hochwassergebiet - LOL ja - aber arbeitstechnisch. Bin derzeit echt "Land unter". Das Problem ist noch nicht gelöst, aber @DieterS. - Du hattest völlig Recht. Das muss Firmware und Programmtechnisch gelöst werden. Das Thema muste ich erstmal hinten an stellen, aber sobald ich hier eine Lösung habe, zeige ich es gern hier auf. Einen Test mit Porgrammanpassung hatte ich durchgeführt, alelrdings blieb die Uhr dann nach einer Weile stehen. Ich muss trotzdem nochmal sagen, dass ich absolut beeindruckt bin von der Fachkompetenz die hier gezeigt wird und von der hilfsbreitschaft. Ihr seid Klasse. Hoffentlich kann ich auch mal so unterstützen. LG
Ich habe es ja schon weiter oben geschrieben, wenn Du die PC Software hier hochladen würdest könnte man sich das ansehen.
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.