zu moppis Post:
stimmt, genau das mit dem dividieren eines int durch (int) 10 ergibt den resultierenden Rundungsfehler bei Hin- und Rückrechnung, den ich oben ansprach.
Zumindest Datenkorruption auf dem EPROM kann man ja jetzt wohl doch ausschließen.

Immerhin scheint es aber jetzt ja auf magische Weise nicht mehr relevant zu sein, daher würde mich schon interessieren, wie was vorher berechnet, gespeichert und zurückgerechnet wurde, als der Fehler beim Zurücklesen/rechnen des Speicherwertes noch auftrat.

was int, int16_t , unsigned int und uint16_t angeht:
ich würde hier ebenfalls zur originalen Typ Definition uint16_t raten, NICHT unsigned int und auch nichts anderes.

Grund: Vielleicht nicht hier und nicht hier bei diesem Programm und auf auf dieser AVR Plattform, aber C++ KENNT den generellen Unterschied zwischen dem Plattform-abhängigen unsigned int von nicht exakt definierter Größe und dem expliziten Datentyp uint16_t aus der <stdint> lib.

Auf ESP8266 oder Arduino Zero/Due z.B. ist int kein 16bit- sondern ein 32bit-Integer, also eher int32_t.

Und auch wenn C++ (gpp) es oft durchrutschen lässt, so erzeugt es dennoch manchmal Compilierungsfehler, wenn es zum impliziten Casting kommt, z.B. bei Funktionsparametern.

Also wenn die Lib uint16_t definiert, dann auch uint16_t verwenden, nicht unsigned int
- und keinesfalls int und auch nicht int16_t , und das wegen des komplett abweichenden Zahlen-Definitionsbereichs!