Spara nr/position innan Arduino stänger ner

[arvidb]

johano: Det där är ju en smart lösning!

Ett alternativ är att skippa att skriva ner aktuell plats. Istället söker man igenom flashet efter positionen med det största räknarvärdet. Med divide-and-conquer bör man klara det med på max N läsningar med 2^N lagringspositioner. Sedan skriver man nästa värde på positionen efter (med uppräknad räknare förstås).

Man får ha tungan rätt i mun bara när det blir overflow på räknaren. Kan vara idé att initialisera räknaren till nära maxvärdet så att eventuell overflow-bugg dyker upp snabbt, medan man kommer ihåg vad man höll på med!

[johano]

ja man kan ju komma undan "indexet" om man vid uppstarten går igenom "platserna" från 0 och uppåt och stannar på den första som har "antal_skriv" < 100000.

Då kommer ju uppstarten ta längre och längre tid över åren men det är nog försumbart.

[Magnus_K]

_Antalet_ skrivningar sparas tillsammans med det värde man vill spara och flyttas till en ny plats var 100000:e skrivning (och nollställs naturligtvis då).
_Indexet_ över vilken plats som för tillfället gäller skrivs alltid till samma plats (2bytes, förslagsvis på första och andra plats) och behöver bara skrivas var 100000:e gång.

En läjjaut skulle kunna se ut såhär:

layout.png

Nu har inte TS varit jätteaktiv i tråden så hoppas att jag får kapa den lite. Annars får du säga till Fosfor!

Jag försöker förstå mig på det här, för det känns som en väldigt bra metod.
Tyvärr vill cellerna inte spela på samma planhalva just nu...

I mitt projekt, och sett till värsta tänkbara scenario, så kommer jag behöva skriva 2 byte ~50ggr per dag till EEPROM:et.
Tyvärr är "payloaden" inte liten nog för att rymmas på 1 byte, utan kring 10-11 bitar, vilket gör att man kan nyttja några bitar per skrivning för indexeringen.
Går det få en livslängd på 10 år så är det fantastiskt.
Är det enligt den här metoden man bör anamma eller vad säger ni som verkar kunna detta?

Om EEPROM:et är 512 bytes stort, och man hittar ett sätt att integrera indexering och "payload" i samma 2 bytes, så borde det ju gå.

[mrfrenzy]

Eftersom jag har reparerat en hel del bilelektronik kan jag återberätta hur dom gör för att lagra mätarställningen utan att slita ut minnet vilket kanske kan ge viss inspiration.
Dom har en lång radda med bits
0000000000000000000000000000000000000000000000000000000000000

Ska du ändra en 0 till 1 måste du ju radera ett helt block, men om du ska ändra en 1 till 0 skriver du bara till den bitten.
Man börjar längst till höger och raderar en byte eller hur stort ett block nu är
0000000000000000000000000000000000000000000001111111111111111
Spara i RAM att vi jobbar nu med byten längst till höger.
När värdet ökar så ändrar man bara en bit i taget till 0 enligt nån smart algoritm. När alla bittar utom någon av dom fyra första är 0 så ändrar man dom till ett annat värde, raderar så allt till höger blir 0 igen och börjar om.
Typ:
1111111111111111
1111111111111110
1111111111111100
...
1111000000000000
1110111111111111
1110111111111110
1110111111111100


När alla dom fyra första 1111 blivit 0 så har man "slitit ut" byten längst till höger så då hoppar man ett steg till vänster.
Då ser det ut såhär:
0000000000000000000000000000011111111111111110000000000000000
Ettorna byts ut enligt mönstret ovan såklart.
Man sparar nya index för minnespositionen i RAM.

Efter varje reboot söker man från vänster till första ettan och sparar index i ram.

För att förhindra korruption vid plötsligt strömavbrott är ovanstående information tredubblad på olika platser i minnet som uppdateras en i taget.

Logik finns som vid reboot jämför dom tre minnespositionerna och tar lämpligt beslut om dom skiljer mer än X.

[Magnus_K]

Det där var väldigt intressant!

Om man skulle nyttja typ samma metod, och i mitt fall dela upp "blocken" i 2 bytes, så skulle man ju enbart behöva uppdatera indexerings-blocket den gången man bytt block.
Eller nej, det går ju bra på en ökande mätarställning men jag måste "nolla" varje gång. Dvs måste jag i så fall även spara föregående data för att kunna subtrahera.

[mrfrenzy]

Observera att ovan bara är "pseudokod", jag har inte analyserat exakt storleken på dom olika delarna av datat. För det borde man göra en kalkyl baserat på applikationen och antal skrivningar för minnet i fråga.

Förmodligen finns det någon appnote för nästan alla biltillverkare gör likadant.
Edit: Nu hittade jag appnoten! https://www.nxp.com/files-static/microc ... HC11RM.pdf

På sidan 143-157 diskuterar dom just olika sätt att skriva variabler som ändras och kommer fram till att lösningen "program-more-zeroes" passar sig för odometer.
Också intressant information: An EEPROM having a life expectancy of 5,000 write-erase cycles at 125°C typically has a life expectancy of 100,000 write-erase cycles at 55°C

Kan du skriva en lista med exempel på 10 värden som du skulle behöva lagra efter varandra?

[Shimonu]

Eftersom jag har reparerat en hel del bilelektronik kan jag återberätta hur dom gör för att lagra mätarställningen utan att slita ut minnet vilket kanske kan ge viss inspiration.
Dom har en lång radda med bits
0000000000000000000000000000000000000000000000000000000000000

Ska du ändra en 0 till 1 måste du ju radera ett helt block, men om du ska ändra en 1 till 0 skriver du bara till den bitten.
Man börjar längst till höger och raderar en byte eller hur stort ett block nu är
0000000000000000000000000000000000000000000001111111111111111
Spara i RAM att vi jobbar nu med byten längst till höger.
När värdet ökar så ändrar man bara en bit i taget till 0 enligt nån smart algoritm. När alla bittar utom någon av dom fyra första är 0 så ändrar man dom till ett annat värde, raderar så allt till höger blir 0 igen och börjar om.
Typ:
1111111111111111
1111111111111110
1111111111111100
...
1111000000000000
1110111111111111
1110111111111110
1110111111111100


När alla dom fyra första 1111 blivit 0 så har man "slitit ut" byten längst till höger så då hoppar man ett steg till vänster.
Då ser det ut såhär:
0000000000000000000000000000011111111111111110000000000000000
Ettorna byts ut enligt mönstret ovan såklart.
Man sparar nya index för minnespositionen i RAM.

Efter varje reboot söker man från vänster till första ettan och sparar index i ram.

För att förhindra korruption vid plötsligt strömavbrott är ovanstående information tredubblad på olika platser i minnet som uppdateras en i taget.

Logik finns som vid reboot jämför dom tre minnespositionerna och tar lämpligt beslut om dom skiljer mer än X.

Jag förstår inte riktigt. Har man en annan representation av tal för att utnyttja den här tekniken eller räknar man fortfarande vanligt binärt?

[mrfrenzy]

Man har en annan representation

Exempel på hur man kan göra
1111 11111111 = 0+0
1111 11111100 = 0+2
1111 11111000 = 0+3
1111 00000000 = 0+8
1110 11111110 = 8+1
1110 11111100 = 8+2
1101 11111111 = 16+0
1100 11111111 = 24+0
1100 11111110 = 24+1

( med reservat för att jag räknat fel på mobilen)

[arvidb]

I mitt projekt, och sett till värsta tänkbara scenario, så kommer jag behöva skriva 2 byte ~50ggr per dag till EEPROM:et.
Tyvärr är "payloaden" inte liten nog för att rymmas på 1 byte, utan kring 10-11 bitar, vilket gör att man kan nyttja några bitar per skrivning för indexeringen.
Går det få en livslängd på 10 år så är det fantastiskt.
Är det enligt den här metoden man bör anamma eller vad säger ni som verkar kunna detta?

Om EEPROM:et är 512 bytes stort, och man hittar ett sätt att integrera indexering och "payload" i samma 2 bytes, så borde det ju gå.

Med 512 byte EEPROM och payload plus index som tar upp tre bytes så har du ju 170 tillgängliga positioner (512/3). Med 50 skrivningar per dag och skrivtålighet på 100000 gånger så får jag det till 931 år. (170*100000/50/365 ≈ 931,5.) Gör du inget alls för att sprida skrivningarna så blir det drygt fem år vilket ju låter lite snålt.

mrfrenzys metod bygger väl om jag fattar rätt på att man har ett värde som ökar stadigt i ganska långsam takt. Den funkar nog inte för generell lagring?