Separera en Integer till två Byte(C)

[TomasL]

Jo, de flashbaserade filsystemen som håller på att utvecklas försöker kringå detta problemet genom att föröka undvika att skriva till samma cell.
Det finns naturligtvis diverse olika tekniker för detta, men i en sån här applikation där man bara har några få MB minne, är FRAM en betydligt bättre lösning och avsevärt snabbare.

[sodjan]

Normalt har "page-write" ingenting med att förlänga livslängden att göra,
det är helt och hållet en "performance feature". Minnet har alltså en 32 bytes
buffer som laddas först och som sedan överförs till cellerna i en enda (5 ms) write.
Slitaget på varje individuell cell är dock fortfarande detsamma...

[bearing]

Overcoming erase/write-
endurance limitations in EEPROMs

USING A SINGLE EEPROM
LOCATION AS A POINTER
TO TRACK WHERE YOU
WRITE DATA RESULTS
IN AN IMMEDIATE
ENDURANCE FAILURE IN
THE EEPROM.

Artikeln beskriver ungefär samma idé som jag hade, fast med räknarna/pekarna samlade i fasta sektorer. EEPROMet i exemplet i artikeln är dock större och har större sektorer, så det kanske inte går att överföra datastrukturen till det här mindre minnet.

[Icecap]

Och sedan ett enkelt sätt att spara blockar till EEPROM eller liknande:
Om vi antar att man har ett antal variabler och man deklarera dom i en block (jag har oftast "Config") som man vill spara & hämta från EEPROM kan man göra som följer:

Kod: Markera allt

struct
  {
  int Var_A;
  char Var_B;
  // Fyll i med vad som behövs
  } Config;

Om man sedan har en "spara i EEPROM"-rutin som behöver en unsigned char-pekare till de data som ska sparas samt antal bytes och startadress och den heter "Save2EEPROM(unsigned char Source, unsigned short Address, unsigned short Size)" är det ganska enkelt:
Save2EEPROM((unsigned char*)&Config, <startadress här>, sizeof(Config));
Att hämta från EEPROM sker med samma parameter och den rutin kan t.ex. heta "Load_From_EEPROM(unsigned char Source, unsigned short Address, unsigned short Size)" och kallas på precis samma sätt.

Man kan självklart göra en union i deklarationen och då adressera buffern direkt.

[jadler]

... Ifall minnet skrivs sekvensiellt i ring blir livslängden är 8000 miljoner sekunder och inte 1 miljon sekunder. Räknaren måste då sparas i ett minne som inte har begränsad livslängd. ...

Fick just en idé. Om du t.ex. har en realtidsklocka ansluten till den loggande kretsen så finns där ofta några bytes RAM som skyddas av samma batteri som håller klockan gående. Det borde vara en bra plats att lagra en räknare om du nu vill använda EEPROM för datalagring. Jag har t.ex. Sparkfuns DS1307-modul till mina Arduino-experiment, den använder I2C och har 56 bytes batteriskyddat minne (så länge batteriet räcker, garanterat nio år, typiskt 17 år utan yttre strömförsörjning).

Personligen tycker jag spontant att EEPROM inte direkt känns som förstahandsvalet för att lagra information högst tillfälligt, det känns mer som en teknik för att lagra information som inte kommer att ändras men som det är bra att någon gång vid behov ändå ha en möjlighet att ändra.

Jag håller så smått på med ett projekt som skall innefatta loggning, och jag lutar mer åt flashminne, antingen i form av vanligt USB-minne eller SD/uSD. Detta dels för att det är en spridd teknik, lätt att få tag på minnen till överkomliga priser, dels för att det vid behov är väldigt enkelt att läsa in den lagrade informationen i vilken dator som helst. Mitt projekt kommer att användas i bilen och jag kommer inte att vilja ta loss alla delar för att få den lagrade informationen till en mer användarvänlig datorplattform (en PC, i mitt fall). Jag leker också med tanken på att låta bil-delens Xbee-modul koppla upp sig mot hemmets Xbee-nät för att skicka över loggade data den vägen, vilket då kunde ske helt "automagiskt" när jag parkerar bilen hemma.

Tillägg:
Prisaspekten: 24LC64-I/P kostar 18 kr inkl moms på Electrokit, det är 64 kilobit minne, alltså 8 kilobyte. På Prisjakt hittar jag nu ett vanligt 2GB SD-kort för 34 kronor. Priset per gigabyte med ditt EEPROM blir 2304 kronor, med SD-kort 17 kronor. Även om man räknar in att du säkert får mängdrabatt om du skulle köpa 128 EEPROM-kretsar och att du nog vill ha ett anpassningskort för SD så blir det nog mer lönsamt i längden med t.ex. SD-kort.

[TomasL]

Och dessa Flashminnen såsom SD/CF mfl är just inget annat än EEPROM med samma begränsningar, dvs man skriver lätt sönder dem.
Det finns dock sk Industrial Grade CF-Minnen med högre endurans, men smakar det så kostar det.

Vidhåller fortfarande, skall man lagra data med återkommande skrivningar och överskrivningar är inte FLASH ett bra alternativ, oavsett om det är förpackat i en liten 3-bens TO92, 8 pinnars kapsel eller det står CF/SD mm på dem.
Det i dag enda rimliga alternativet upp till nån Mbit är FRAM minnen eller liknande teknologier.
Och dyra? Nej det tycker jag inte.
ELFA tar runt 50-lappen för 256Kbit i2c/SPI i enstyck.

[jadler]

Och dessa Flashminnen såsom SD/CF mfl är just inget annat än EEPROM med samma begränsningar, dvs man skriver lätt sönder dem.
Det finns dock sk Industrial Grade CF-Minnen med högre endurans, men smakar det så kostar det.

Vidhåller fortfarande, skall man lagra data med återkommande skrivningar och överskrivningar är inte FLASH ett bra alternativ, oavsett om det är förpackat i en liten 3-bens TO92, 8 pinnars kapsel eller det står CF/SD mm på dem.

a) Jag är ingen expert på området, men jag hade bestämt för mig att s.k. flash-minnen och EEPROM fungerade på helt olika sätt rent tekniskt/elektroniskt. Kanske spelar det mindre roll, som du skriver har båda begränsningar i antalet skrivningar per minnescell.

b) Mängden data som skrivs och skrivfrekvensen borde också spela in. Om jag skriver 1 byte per sekund till ett 2 GB SD-kort så tar det drygt tre veckor innan minnet är fullt och jag börjar om från början. Även om varje minnescell bara skulle klara 1000 skrivningar så borde jag kunna hålla på i 66 år innan jag får problem. Kostar minnet 34 kronor kan jag köpa ett hundrapack och byta var tredje vecka, så har jag också en löpande säkerhetskopia av all information.

Visst kan FRAM rent tekniskt vara bättre, men SD-kort, USB-minnen och SSD-"diskar" är bra nog för många applikationer. Duger det med flash i proffsens digitalkameror och i många nyare bärbara datorer så tror jag att det duger åt mig.

[TomasL]

Rent tekniskt så är minnescellerna likadana, SD-Kort och liknande kan skrivas via tvåtrådsbuss.
Det vi i dag kallar EEPROM är ju faktiskt FLASH.
Proffsen är mycket medvetna om problemet med sönderskrivna kort, och har följdaktligen reserver med sig, byter innan det är utslitet osv.
Dessutom använder proffsen inte SD kort utan CF som (för det mesta) är av högre kvalitet.

[sodjan]

> ...dels för att det vid behov är väldigt enkelt att läsa in den lagrade informationen i vilken dator som helst.

Det har mer med själva *formatteringen* att göra (d.v.s att det finns ett "filsystem" på minnet)
än att det är byggt med en viss minnesteknik. Om vill ha det som du beskriver (d.v.s att du
ska kunna läsa datat på "vilken dator som helst") så blir det å andra sidan lite mer jobb när
mikrocontrolern ska skriva till det (eftersom man sannolikt behöver en FAT stack eller liknande).

Om vi återvänder till det aktuella problemet, så tror jag mer på att spara räknaren
i minnet i processorn och skriva ut det till permanent lagring när ett strömavbrott
inträffar. Man får ha lite extra prylar för att dels detektera ett spänningsbortfall, dels
se till att man han en konding eller liknande som håller det hela igång medan man
sparar undan "status", men det är känd och beprövad teknik.

[jadler]

Rent tekniskt så är minnescellerna likadana, SD-Kort och liknande kan skrivas via tvåtrådsbuss.
Det vi i dag kallar EEPROM är ju faktiskt FLASH.

Jag läste på på ELFAs faktasidor, där gör man skillnad mellan flash och EEPROM. De skriver att flash-minnen bara kan raderas per sida, inte per minnescell som för EEPROM, och att EEPROM klarar 10-100 gånger fler skrivningar per cell.

Det har mer med själva *formatteringen* att göra (d.v.s att det finns ett "filsystem" på minnet)
än att det är byggt med en viss minnesteknik.

Självklart, men jag ser det som en fördel att minnet rent fysiskt enkelt kan anslutas till andra datorer. Visst blir det mer jobb för att skriva data i ett format som en PC kan läsa, men vill man föra över informationen dit kan det nog vara värt besväret, och det finns också många olika lösa kretsar och färdiga anpassningskort som hjälper till med detta.

Era lösningar är säkert bra, och jag tror säkert att FRAM kan vara mycket bättre rent tekniskt. Samtidigt tror jag att någon form av flash-minne kan passa bättre just för mig.

[Icecap]

Att det skiljer mellan flash och EEPROM i <RADERINGEN> betyder inte att de har olika teknologier, faktisk är det identisk teknologi i sparandet av data medan raderingskretsloppen skiljer.

Själv har jag haft detta med insamling av statistik och då använde jag en ledig flashbank i processorn men då tömde vi den å andra sidan varje månad eller så vilket ju ville ge ganska lång tid över garantitiden innan de 10k gångar den var garanterat till blev utnött. Tömde vi varje vecka ville det bli 400 år och jag tror knappast att de skyltar håller så länge ("DU KÖR FÖR FORT"-skyltar) och skulle de skiter jag i det, då har jag varit död länge.

[Klurige]

En liten kommetarer bara om hållbarheten på de minnen som omtalas. Man räknar inte skrivningar, som det så felaktigt står i många datablad på svenska, utan skrivcykler (eller raderingar).

En radering innebär att samtliga celler i en sida sätts till ettor. En skrivning ändrar sedan vissa bitar till nollor. Det skulle alltså gå bra att skriva upp till åtta gånger till en och samma byte inom en skrivcykel. (Nu är det rätt ovanligt att man nyttjar denna möjlighet, utom kanske i blocklagret i ett filsystem.)

Slitaget på minnet har alltså inte alls att göra med huruvida man skriver en, två eller fler bytes åt gången, utan hur ofta man raderar en sida.

När minnet slits går inte hela minnet sönder på en gång, utan en sida lite då och då. För NAND-flash är det dessutom så att vissa sidor är trasiga redan från början. Detta är rätt jobbigt att ta hand om detta i sin programkod, därför är det oftast att föredra att använda SSD-minnen istället. SSD-minnen är nästan uteslutande baserade på NAND, men innehåller även en kontrollkrets som gör att nand-minnet ser ut som en vanlig blockdevice (hårddisk). Kontrollkretsen ser till att trasiga sidor inte används och ser även till att slitaget på NAND-minnet sprids ut.
NOR-minnen är mycket lättare att hantera, men de är mycket dyarare och klarar inte lika många cykler. NOR och EEPROM fungerar i princip likadant.

[Anonym2]

Hej!

Jag måste erkänna att jag känner mig något förvirrad angående detta med EEPROM och antal skrivningar. Tempgivaren(DS18b20) leverar(efter lite formler och sånt..) 2st värden. heltal och decimal, i två stycken bytes. Heltalet sparas på ett minne, och decimalerna(2st) sparas på ett annat. Varje minne kommer följakligen att skrivas till 8000gånger under en full mätning(2timmar+ för 1 mätning i sekunden, eller 133timmar för 1mätning i minuten). Jag kan altså göra 125mätningar på 133 timmar innan minneskretsarna är avverkade(1.000.000/8.000). Har jag förstått det något så när rätt?

Att skriva till en byte på minnet 1.000.000ggr är altså lika skadligt som att skriva till varje byte på minnet 125ggr?(om man nu skriver byte för byte, eller "PAGEWRITE")

När varje mätning är klar, så raderas inte minnesplatserna. Alla mätvärden står kvar, men dom sista 2byten på ett av minnena ställs till 1, och programmet kommer således att starta om när man vill logga något annat vid ett annat tillfälle.

Jag har kikat lite på att använda SD/MMC, men som någon skrev så verkar dom ha samma problem. Men å andra sidan så har man ju mer utrymme, och dom är mer "prisvärda".

Tack för tipset om FRAM, tyvärr kan jag bara hitta ytmonterade(SO8), ska leta runt lite mer! Smidigt om dom har I2C eller OneWire interface!

Tackar för att alla visat sådant intresse för mitt problem!

//Alexander

[Klurige]

Ranstam: 8000 bytes * 1 miljon cykler blir 8 miljarder mätvärden.En mätning i minuten gör att ditt minne håller ca 15000 år. En gång i sekunden så håller kretsen bara 250 år.

[TomasL]

Finns också FRAM med SPI Interface, och då kan man köra minnet i 40MHz, I2C är begränsat till runt 3 MHZ, dock är ju max frekvensen på I2C 1 MHz, så det kanske räcker till.

SOIC är ju iofs inga problem, ELFA har adaptrar, annars gör du bara ett litet kort själv.