Mathias hat geschrieben:Was ist der Grund, das man diesen Umweg machen muss ?
Dass man zu blöd ist, mit packed BCD Zahlen zu rechnen?
BCD heisst ja, dass die Zahlen 0..9 als binär %0000 bis %1001 gespeichert werden, oder hex $00 bis $09. Das passt nun locker in 4 Bit, also hat man noch 4 Bit in einem Byte frei. In die packt man jetzt die zweite Dezimalstelle der Zeit. $21 (wohlgemerkt Hex) entspricht also 21 Uhr, nämlich 2 * 16 + 1.
BCD war früher üblich, als es noch 4-Bit µC gab, und damit konnte man schon super rechnen. Viele I2C-Uhrenbausteine liefern Zeit und Datum als packed BCD. Will man das als übliche Binärzahl auf dem µC haben, muss man allerdings die höhere Stelle umrechnen. Dazu dienen die beiden Funktionen.
Das div 10 geht allerdings gar nicht, dafür braucht der µC Software Division. Nicht schön.
Man kann übrigens Zeiten auf dem µC komplett in packed BCD verwalten. Meine Heizungssteuerung verwendet für Tagesprofile, Nachtabsenkung usw. nur packed BCD, weil das so aus der RTC kommt. Man kann genauso gut vergleichen, addieren, subtrahieren wie mit Binärzahlen, und man kann viel einfacher von und in Strings wandeln: Nur die Stelle holen und plus 48 rechnen => BCD zu ASCII, oder minus 48 => ASCII zu BCD. Das war übrigens der Grund, warum man das früher in Rechenmaschinen genommen hat: Einfache Ein- und Ausgabe von Dezimalzahlen, ohne div und mul.
Achso: Falls Du Dich schonmal gefragt hast, wofür Dein ATmega eigentlich dieses mysteriöse Half-Carry-Flag im Statusregister hat - das ist genau für das Rechnen mit diesen BCD-Zahlen gedacht.