EEPROM - ausgelesener Wert ist ungenau

[Moppi]

Wenn man die Frequenztabellen ansieht, enden die meisten Sender eh auf "0" statt "5".
Das mit den Datentypen führt meist zu Problemen, die sich kaum finden lassen, wenn man darauf kein Augenmerk legt und sich dessen nicht bewusst ist.
Das ist natürlich richtig, dass bei unterschiedlichen CPUs die Datentypen unterschiedliche Bitbreite haben können. Deswegen wichtig: Datentypen kennen.

MfG

[HaWe]

Wenn man die Frequenztabellen ansieht, enden die meisten Sender eh auf "0" statt "5".
Das mit den Datentypen führt meist zu Problemen, die sich kaum finden lassen, wenn man darauf kein Augenmerk legt und sich dessen nicht bewusst ist.
Das ist natürlich richtig, dass bei unterschiedlichen CPUs die Datentypen unterschiedliche Bitbreite haben können. Deswegen wichtig: Datentypen kennen.

MfG

jain,
die Probleme mit uint16_t versus unsigned int treten auch bei identischen Plattformen im selben Programm auf, nicht nur bei verschiedenen, und auch wenn die Datengröße übereinstimmt, daher IMMER genau identisch verwenden - oder jedes Mal explizit casten!
Das gleiche gilt für long versus int32_t/int64_t, und ganz besonders auch für char, signed char, unsigned char, int8_t, uint8_t und byte (gerade bei char kann man sich bei Arduino vor Verzweiflung die Haare raufen!).

Da das Programm aber jetzt ja angeblich funktioniert, ist die Rundung um 0,5 ja offenbar nicht mehr das Thema, doch wie ich schrieb,

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.

[Moppi]

Das Problem lag wohl hier:


1. EEPROM.put(0, frequency); // neue Frequenz in EEPROM speichern
2. EEPROM.get(0, frequency);


EEPORM.put() wird wohl dann bei dem Wert 10625 nur 129 (die unteren 8 Bit) speichern, wenn die Funktion nur byteweise ins EEPROM schreibt. Damit ist die Frequenz futsch. Kann auch möglich sein dass die put-Funktion zwei Byte ins EEPROM schreibt, nämlich High und Low-Byte, aber nur ein Byte zurückgelesen wird, gäbe auch nichts genaues. Und falls das Folgebyte im EEPROM, an Position #1, für andere Zwecke gebraucht wird, würde das direkt mit überschrieben, falls zwei Byte ab Position #0 geschrieben werden.
Durch den Umweg mit Frequenz/10 minus 825, den basteluwe hinzugefügt hat, funktioniert es dann, er übergibt put() nur noch ein Byte und da ist die Frequenz dann drin. Vorher war sie ja in zwei Byte drin.

[HaWe]

Das Problem lag wohl hier:


1. EEPROM.put(0, frequency); // neue Frequenz in EEPROM speichern
2. EEPROM.get(0, frequency);


EEPORM.put() wird wohl dann bei dem Wert 10625 nur 129 (die unteren 8 Bit) speichern, wenn die Funktion nur byteweise ins EEPROM schreibt. Damit ist die Frequenz futsch. Kann auch möglich sein dass die put-Funktion zwei Byte ins EEPROM schreibt, nämlich High und Low-Byte, aber nur ein Byte zurückgelesen wird, gäbe auch nichts genaues. Und falls das Folgebyte im EEPROM, an Position #1, für andere Zwecke gebraucht wird, würde das direkt mit überschrieben, falls zwei Byte ab Position #0 geschrieben werden.
Durch den Umweg mit Frequenz/10 minus 825, den basteluwe hinzugefügt hat, funktioniert es dann, er übergibt put() nur noch ein Byte.

danke, aber das erklärt IMO die Abrundung bei 8820 zu 8800 nicht ausreichend (CMIIW).

Daher würden mich auch andere damalige aufgetretene "Fehler" interessieren, und auch der komplette Rechenweg.

[Moppi]

Aber so, wie es ausschaut, gab es kein anderes Problem. Ich denke, das wars.

@basteluwe weiß mehr, ist sein Projekt.

Gruß

[HaWe]

Aber so, wie es ausschaut, gab es kein anderes Problem. Ich denke, das wars.
@basteluwe weiß mehr, ist sein Projekt.
Gruß

Das kanns nicht gewesen sein, siehe 8820 -> 8800.
genau deswegen bat ich ja um weitere Informationen von basteluwe.

[basteluwe]

Oh Ha! Hier ging ja noch richtig die Post ab!
Danke für eure ganzen Beiträge. Ich gebe mal ein Update, um vielleicht etwas Licht in's Dunkel zu bringen.

Das Problem ist tatsächlich für mich gelöst! Der im Post #14 von mir gezeigte Code funktioniert einwandfrei unter den bei mir gegebenen Bedingungen:

Die wichtigste Änderung im neuen Code zum ursprünglichen ist der Punkt an dem ich radio.getFrequency() aufrufe. Ursprünglich habe ich das jedes Mal nach einem Scan-Befehl getan. Zum Debuggen hatte ich dann im Terminal die zurück gemeldete Frequenz anzeigen lassen. Die stimmte sehr oft nicht mit der aktuell wiedergegebenen überein. Pausen vor und nach dem Befehl änderten nichts an der Abweichung.
Schließlich habe ich getFrequency einfach in die Hauptschleife gebaut und über "millis" nur alle 5 Sekunden aufgerufen. Zusätzlich habe ich EEPROM.update entdeckt, das nur bei Änderungen einen neuen Wert in den EPROM schreibt. Mit diesen Änderungen läuft der Code seit Gestern ohne jedes Problem.
Ich habe aber nach wie vor keine Ahnung warum die Abfrage im ursprünglichen Code teilweise falsche Ergebnisse lieferte, aber egal: Problem solved!

Ich sollte noch was zu den Bedingungen sagen, die zu der verwendeten Umrechnung geführt haben:

Sämtliche Sender in unserer Ecke liegen im 100KHz Raster, der frequency-Wert endet also hier IMMER auf 0, niemals auf 5.
Bei einem Frequenzbereich 87,00 - 108,00 MHz ergaben sich also 210 mögliche frequency-Werte.
Um von den richtigen Werten (8700 bis 10800) auf byte-Format zu kommen, das EEPROM.put und EEPROM.get verlangt, habe ich die Formel storeFreq=(frequency/10)-825 "erfunden". Damit liegen die Speicherwerte zwischen 45 (87,0 MHz) und 255 (108,0 MHz).

Mir ist klar, das das nur für meine spezielle Anwendung geht und nicht sehr elegant ist. Es erfüllt aber meinen Zweck, ich bin halt kein Profi-Coder.

Ich bin wirklich dankbar für Eure Hilfe, das ist schon ein Spitzen-Forum hier!

Uwe

- - - Aktualisiert - - -

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.

Sorry, die Frage hatte ich überlesen.
Im ursprünglichen Code gab es keine Umrechnung! Ich hatte get und put für den EEPROM verwendet, weil ich meine, dass die integer handeln können. Also habe ich den Wert aus getFrequency direkt in den EPROM gespeichert.
Im neuen Code verwende ich für den EEPROM update, das leider nur byte akzeptiert. Daher jetzt die Umrechnung storeFreq = (frequency/10)-825;

Uwe

[HaWe]

Ursprünglich habe ich das jedes Mal nach einem Scan-Befehl getan.

aha, und was macht dieser Scan-Befehl genau, wie lautet und funktioniert er, und warum liefert er falsche oder schwankende Ergebnisse?