im Rahmen eines aktuellen Projekts werde ich vermutlich Probleme bekommen, mit den 512 Bytes des EEPROMs klarzukommen.
Was ich abspeichern möchte:
30 Mal möchte ich jeweils die Reihenfolge der Zahlen 1 bis 8 speichern.
Hierfür hatte ich zunächst ein byte-Feld mit 30 Reihen und 8 Index vorgesehen.
Das wären somit 240 Bytes.
Zusätzlich möchte ich 30 Mal jeweils einen Wert zwischen 100 und 10000 speichern. Schritte im Abstand von 100 würden mir hierbei ausreichen. Wenn ich hierfür die Werte einzelner Bytes nehmen und diese jeweils mit 100 multiplizieren würde, käme ich mit einem weiteren byte-Feld mit 30 Reihen und 8 Index hin. Beispiel: Abgespeichertes Byte: 10 * 100 = errechneter Wert: 1000.
In Summe bräuchte ich somit 480 Bytes.
Das belegt mir jedoch bereits schon zu viel Platz.
Was wäre aus Eurer Sicht eine Alternative, das sinnvoller/speicherschonender zu speichern.
a) einen Prozzi mit mehr EEPROM nehmen, wobei meine Unos eigentlich schon 1024 hätten.
b) für 1-8 brauchst du kein ganzes Byte, da reichen 3bit, kannst du also mindestens halbieren.
c) wenn immer noch zu wenig: für 1-100 brauchst keine 8 bit, da reichen 7.
aber eigentlich würde ich die Anforderung überdenken.
Warum müssen diese Werte dauerhaft gespeichert werden,
für wie lange,
in welchem Intervall wird geschrieben (auch wegen der limitierten Schreibzyklen),
weshalb reicht es nicht die Werte im RAM zu halten?
noiasca:
sein 30 mal 1-8 habe ich eher so interpretiert 30 mal 8 Werte (von 1-8)
Ja, so meint er das.
Einen anderen Prozessor möchte er nicht nehmen. In‘s EEPROM soll deshalb gespeichert werden, weil die Werte auch bei einer Stromunterbrechung erhalten bleiben sollen.
Es geht um Prioritäten und Laufzeiten von acht PTZ-Kameras und 30 Szenen.
Momentan programmiere ich noch auf einem Uno, später sollte es eigentlich ein Digispark werden. Alternativ wird es eine Kombi aus einem kleingesägten Pro mini und einem FTDI.
OT: Wenn ich mir deine bisherigen Posts ansehe - ich würd' an deiner Stelle wirklich mal einen ESP8266 12E in die engere Wahl nehmen, ob der für deine Zwecke nicht x mal besser wäre: Mehr Ram, mehr EEPROM, sogar ein Filesystem, Alternativen zur Seriellen (WiFi) ...
muss ein paar Zwischenfragen stellen.
Warum soll man sich die Bit Knauserei antun wenn man eh nur Byteweise lesen und schreiben kann?
Warum soll man sich das packen von 2 Werten in ein Byte antun, wenn der Speicher ausreichend ist?
Damit ist auch die Rechnung 3Bit und 4Bit nur Theorie. Mehr wie 2 seiner Werte seines Wertebereiches passen nicht in ein Byte.
480Byte sind kleiner wie 512Byte verfügbarer. Wo ist das Problem?
Da fang ich doch nicht an mit irgendwelcher Bitschieberei. Nur das der "halbe" Speicher unbenutzt bleibt?
Simulator und IDE trennen Welten**!** Ich finde es persönlich auch nicht gerade nett jemanden ungetesteten Code vor die Füße zu knallen.
sketch_may19a.ino: In function 'void pack3(byte, byte*)':
sketch_may19a.ino:13:28: warning: second operand of conditional expression has no effect [-Wunused-value]
constrain (myValue,1,8); // gegen falsche Werte absichern
sketch_may19a.ino:13:28: warning: second operand of conditional expression has no effect [-Wunused-value]
sketch_may19a.ino.cpp:1:0:
AppData\Local\Temp\arduino_modified_sketch_69921\sketch_may19a.ino:13:16: warning: third operand of conditional expression has no effect [-Wunused-value]
constrain (myValue,1,8); // gegen falsche Werte absichern
AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.209\cores\arduino/Arduino.h:95:74: note: in definition of macro 'constrain'
#define constrain(amt,low,high) ((amt)<(low)?(low):((amt)>(high)?(high):(amt)))
noiasca:
OT: nett, also nett wäre gewesen du hättest einfach deine Version vorgestellt, oder hättest es ausgebessert.
So leicht solltest du dich nicht aus deiner Verantwortung stehlen. Es ist immer noch dein Sketch.
Das Problem anderen aufzuhalsen ist auch nicht gerade nett. Nur weil sie sich dazu geäußert haben.
Den OT hättest du dir einfach schenken können und alles wäre i.O. gewesen.
Aber schön das du ihn korrigiert hast.
Chris72622:
Momentan programmiere ich noch auf einem Uno, später sollte es eigentlich ein Digispark werden. Alternativ wird es eine Kombi aus einem kleingesägten Pro mini und einem FTDI.
Gruß Chris
Wenn Du schon einen Hardware im auge hast dann ist es sinnvoll mit dieser Hardware zu arbeiten und nicht das Projekt nit einer anderen entwickeln und dann umschreiben.
Chris72622:
Hallo,
im Rahmen eines aktuellen Projekts werde ich vermutlich Probleme bekommen, mit den 512 Bytes des EEPROMs klarzukommen.
Falls nicht jemand letzte nach entschieden hat einen ATmega168 auf den UNO zu löten hat der Arduino UNO immernoch 1kByte EEprom. ansonsten ist über I2C leicht ein externes EEPROM anzuschließen. Wenn oft darauf geschrieben wird dann ein FRAM.
