Verständnisfrage: was beudeten Werte bei RTC?

[Rene M. (gozu)]

Hallo, ich habs jetzt endlich geschafft, eine Kommunikation mit meinem 
RTC zu schaffen und die Werte anschließend über UART auszugeben. Jetzt 
habe ich aber ein kleines Problem bei der Auswertung dieser Werte.

Hier mal kurz das Datenblatt von meinem RTC:
http://datasheets.maxim-ic.com/en/ds/DS1340-DS1340C.pdf

Auf Seite 8 sieht man die Register, nehmen wir zum Beispiel mal 00h her, 
also das Sekunden register. Bits 0-3 sind Seconds und 4-6 sind 10 
Sekunden. Was bedeutet das jetzt? Sind Sekunden für die Einerstelle und 
10Sekunden für die 10er Stelle?

Wenn ich die Sekundenwerte am PC debugge, bekomme ich z.b. (in ascii)
1,5,10,15,20,25....87,1,5 usw. (hab ein delay eingebaut, deshalb nicht 
jede Sekunde)

So jetzt ist mein Problem folgendes:

87 in binär ist 0101 0111, also bits 0-3 sind 0111 = 7 und 101 = 5
==> Wäre das Sekunde 57! Soweit sogut.

Nehme ich aber z.b. 15, dann ist das binär 0000 1111. Hier während ja 
die 10er Stellen bits 0 und die Einerstelle hätte ja einen undefinierten 
Zustand oder? Weil 1111 ja 15 ist, aber die Einerstelle nur maximal 9 
werden kann... Hier werden doch beide Zahlen nach 2 verschiedenen 
Prinzipen ausgewertet, also würde man z.b. die erste Zahl nach dem 
jetzigen Prinzip auswerten, hätte man die Sekunde 87??? Gibt es aber 
nicht... und andererseits wenn ich diese Zahl nach dem ersten Prinzip 
auswerte, hätte ich eine unmögliche Zahl, weil die Einerstelle 
undefiniert wäre.

Bin gerade etwas verwirrt, also wenn die Lösung ziemlich leicht ist, 
verzeiht mir bitte, ich stehe nur gerade auf der Leitung....

[hust (Gast)]

Also ich kenn mich da nicht so aus, aber im Datenblatt steht das es BCD 
kodiert ist. das geht nur von 0-9...

[Rene M. (gozu)]

Ja das weiß ich auch, das würde doch heißen, dass für die Sekunde 15 
folgender binärcode geschickt werden sollte:
0001 0101 ==> das erste Nibbel wäre dann 1 und das 2te wäre 5 und 
zusammen wäre das dann 15.... Aber mein Problem ist eben, dass ich binär 
0000 1111 bekomme, was eben nicht möglich sein sollte, weil es ja bcd 
code ist! Jemand ne Idee??

[Rufus Τ. F. (rufus)]

Deine Interpretation der Bits ist soweit richtig; im Datenblatt steht ja 
auch:

   The contents of the time and calendar registers are in the
   binary-coded decimal (BCD) format.

Daher sollte der Wert 15dez nie im Sekundenregister (Adresse 0) zu 
finden sein, ebenso kein anderer, bei denen der Wert von Bit3..0 größer 
ist als 9dez.

Könnte es sein, daß Du den Baustein mit ungültigen Daten initialisierst?

[Klugscheisser (Gast)]

Vielleicht solltest Du Dir Deine Interpretationen nocheinmal anschauen.
In Deinem Post kommt mir einiges unrichtig interpretiert vor. Daran 
liegt es vielleicht.

>87 in binär ist 0101 0111,
Das kommt darauf an:
87   (hexadezimal)  ist binär 1000 0111
87   (dezimal)      ist binär 0101 0111
57   (kodiert)      ist binär 0101 0111

>also bits 0-3 sind 0111 = 7 und 101 = 5 ==> Wäre das Sekunde 57! Soweit >sogut.
Das mit der 87 ist also ein Umweg, wenn Du von vorneherein weisst, das 
die Zahl BCD kodiert ist.

>Nehme ich aber z.b. 15, dann ist das binär 0000 1111
Das kommt eben wieder darauf an.
15 (hex) ist binär 0001 0101
15 (dez) ist binär 0000 1111
15 (BCD) ist binär 0001 0101

Ich nehme an, die nimmst die 15 daher:
>enn ich die Sekundenwerte am PC debugge, bekomme ich z.b. (in ascii)
>1,5,10,15,20,25....87,1,5 usw.
Das wäre aber nur möglich, wenn Du die Ausgabe dezimal machst, anstelle 
hexadecimal. "87" gibts in BCD nicht, also auch nicht in Hex.

Hex wäre halt einfach, weil die kodierung teilweise mit BCD 
übereinstimmt. Und wo sie nicht übereinstimmt, hat BCD keine Kodes. Sie 
treten nicht auf.

Du schreibst weiter:
>Aber mein Problem ist eben, dass ich binär 0000 1111 bekomme
Falls Du die Info von dem PC-Programm hast, von dem wie gesagt vermutet 
werden kann, das es dezimal ausgibt, dann ist sie falsch.

Hast Du das allerdings kontrolliert, dann mag der Tip mit der falschen 
Init richtig sein.