search

RF1000community / Repetier-Firmware

Community version of the firmware for the Renkforce RF1000 and RF2000 3D Printers
http://www.rf1000.de
16 stars 12 forks source link

Werte im EEPROM ablegen. #23

Closed Nibbels closed 7 years ago

Nibbels commented 7 years ago

Einige Modfunktionen, wie

Sollten im EEPROM abgelegt und wieder geladen werden. Ablegen und laden ist kein Problem, allerdings muss man sich darum auf eine Struktur einigen und die richtige Adressenkonvention klären. Es scheint z.B. als wäre im ersten EEPROM (RF2000 hat zwei) oberhalb der neunten Z-Matrix noch einiges an Speicher frei.

Ebenfalls sollte man sicherstellen, dass die Chance klein ist, dass RF1000 in der offiziellen Firmware diese Adressen einmal für sich verwenden will.

Ebenfalls sollte man sicherstellen, dass wilkürliche Zufallswerte aus diesen Bereichen nicht geladen werden. (Macht man für sowas n CRC/Fletcher-Check? Ist das generell schon in irgendeiner Art integriert?)

Nibbels commented 7 years ago

https://github.com/RF1000community/Repetier-Firmware/issues/11

Nibbels commented 7 years ago

Ich habe hier was gelesen. https://arduino.stackexchange.com/questions/226/what-is-the-real-lifetime-of-eeprom

Wäre es nicht klug, wenn wir bei Funktionen wie 

    static inline void eprSetByte(unsigned int pos,uint8_t value)
    {
        eeprom_write_byte((unsigned char *)(EEPROM_OFFSET+pos), value);

    } // eprSetByte

zuerst lesen, ob der Wert derselbe geblieben ist? Also dort und in den Funktionen für die anderen Datentypen noch ein Read und Vergleich einfügen?

Warum die Frage: Eigentlich klar! Aber entgegen der Meinung der Leute im Thread könnte eine Funktion wie eeprom_write_byte sowas bereits automatisch checken?

LG

Nibbels commented 7 years ago

Ok, meist wird danach die Checksum upgedated. Das ist auch noch sone Sache. In den Funktionen ist diese Abfrage nicht zwingend am idealsten. Wenn wir einfach nur einen End-Wert sichern wollen, der genutzt wird, ist ein Lesen vor dem Schreiben evtl. am sinnvollsten. Dann kann man auch das Checksum-Update aushebeln. > Da sammeln sich die Writes.

mhier commented 7 years ago

Es spricht doch nicht dagegen, zuerst zu lesen und zu vergleichen, oder? Also würde ich sagen, das sollte unbedingt so gemacht werden. Das Schreiben ins EEPROM kostet eh immer einiges an Zeit.

Ich bin eigentlich auch der Meinung, dass einige Sachen einfach nicht ins EEPROM gehören würden. Das ist vielleicht hier und da Geschmacksache, aber m.E. ist es eigentlich nicht einzusehen, warum z.B. die Schrittweiten im Positionsmenü gespeichert werden. Das sind doch nur unnötige Writes. Wenn, wie du sagst, auch noch jedes Mal ein Checksum-Update geschrieben wird, geht das ja auch noch immer auf die selbe Zelle. Braucht man die Prüfsumme überhaupt?

Nibbels commented 7 years ago

Dass ich immer vorher lese und abgleiche ob der Wert schon drin steht ist seit ein paar meiner Patches drin. Auch schon in der Community-Development. https://github.com/Nibbels/Repetier-Firmware/commit/10dd53cf663e85d45edc57431875e589b96bf25d#diff-4bb2681d584024bccf2e702e6ff445e6R511

Das macht glaub schon einiges besser und auch wenn die Checksum gleich bliebe ist die dadurch abgesichert. Die Checksum wird mit ebenfalls eprSetByte verändert. Wir sparen nun also prozentual vermutlich einige Writes.

Meine Einstellung ist: Alle Werte, die man kaum/selten verändert, können im EEPROM stehen bleiben, aber Einstellungen, welche wirklich ständig einem Update unterstehen sind gefährlich. Jetzt sind nur noch die Werte gefährlich die sich wirklich ändern.

Was evtl. ganz cool wäre, wäre die Checksum in die extrenen Flash-Chips umzuleiten, denn die haben sehr viel mehr Zyklen, als das interne. Da bin ich aber noch nicht eingearbeitet. Ich sehe das auch noch nicht so sehr kritisch.

Was wir im Grunde auch tun könnten wäre auf die Checksum verzichten und nach dem Schreiben den Flash lesen und direkt abgleichen ob das auch drinsteht was rein sollte. In diesem Fall könnte man ne Meldung aufs Display schicken, mit betroffener Zelle und Errorbeschreibung.

Oder vier+ Checksum-Zellen nutzen. 2 Blöcke je 2 Zellen: Sobald nach dem parallelen Beschreiben eine Zelle im ersten Block anders ist als die andere, wird der Wert so stehen gelassen und die Checksum geht in die zwei neuen Zellen. Immer vor dem Checksum schreiben wird geprüft, ob unterschiedliche Werte drin stehen und wenn ja, dann wird der zweite Block benutzt. So könnte man Das Leben der Checksum-Funktion verdoppeln, verdreifachen etc.

LG

Nibbels commented 7 years ago

Laut RF1000 können wir ca. 100000 Schreib-Zyklen auf eine Zelle. Ich weiß nun generell über die Problematik Bescheid und habe an ein paar Stellen optimiert. Wenn so ein Fall aktuell wird, dass das EEPROM spinnt, würde ich mir darüber wieder Gedanken machen, aber auf diese Anzahl Writes muss man mit manueller Bedienung erstmal kommen.

Ich werde zukünftig mehr sinnvolle Werte im EEPROM ablegen, aber niemals welche, die sich ständig ändern.