Logga data i projekt, val av hårdvara och bra metod

[Magnus_K]

Ahaaa! Så detta minne har då 256 pages där varje page har 32 adresser där jag kan skriva en byte på var "rad"?

Du ska ha ett stort tack Mr Andersson för att du tagit dig tid. Det känns som att jag börjar förstå lite bättre hur det hänger ihop nu.

Jag ska läsa igenom databladet en gång till nu när jag har fått lite mer kött på benen.
Det känns som att man måste hålla stenkoll på storleken på datan och hur man nu löser det med att hålla koll på vilken data man skriver till vilken adress är för mig ännu en gåta att lösa.

[Icecap]

Om en page är på 32 bytes kan du skriva 32 bytes på en och samma page. Vad du INTE kan är att skriva till två olika pages i samma veva. Du måste skriva klart på ena pagen och finns det mer som ska skrivas får du vänta till den första page är klar innan du skriver vidare på nästa page.

Jag använder en EEPROM på 32kB med en page-size på 16 bytes. Jag har såklart en "skriv minnesbuffer till EEPROM"-funktion och den håller koll på om en page-gräns överskrids. Om den nås skrivs de inmatade data klart, en ny adressering sker och data överförs. Detta upprepas till allt är klart varför jag från programmet kan strunta blankt i vilken storlek minnesbuffer som ska sparas (om den inte överstiger vad EEPROM'et klarar).

[Micke_s]

Kör du med en atmega328 kan du även använda flashet. Processorn har stöd för self write. Se bara upp att du inte skriver över din egen applikation.

Är det en arduino så är bootloadern skyddad...

[Magnus_K]

@Micke_s:
Ska ha det här i bakhuvet när jag kommer till µC-valet dock börjar det luter mer och mer åt externt minne i DIP-kapsel så denna kan vara monterad i en sockel. Därmed relativt enkelt utbytbar om så behövs.

När det kommer till sättet som man skriver till minnet är jag lite fundersam.
Precis som Icecap är inne på så är det nog klyftigt att göra en färdig funktion för detta men sitter och klurar på hur man gör det på bästa/effektivaste/enklaste sätt...

Låt säga att jag väljer "Icecap-formatteringen" av datan jag vill logga. Som redan uträknat så blir datan 22 bitar lång och om man vill ha jämna bytes så blir det alltså 3 (24 bit).

Om jag nu vill spara det här så måste man ju ha något som håller koll på vilka adresser som är upptagna och inte. Eventuellt också en funktion som gör att när sista byten på sista sidan är skriven så "rullar" minnet om och man börjar skriva över den äldsta datan. Hur beter man sig för att göra det här?

Med min ringa kunskap, och om jag inte hade haft proffsen att fråga, så hade jag nog haft en variabel som innehåller antalet utförda loggningar/skrivningar. Utefter värdet på variabeln så räknra man ut ny adress för skrivning samt när det ska "rulla om".
Hade denna variabel tex varit "10" (vilket innebär 30 byte skriven data), så skulle jag ha någon funktion som anser dom två sista byten som "skräp" och välja första adressen på nästa sida.
När man till slut kommer till sista sidan (page:en) så nollas variablen och man börjar helt enkelt om från början.

Hade ni gjort något i närheten av vad jag beskriver ovan eller har ni lust att ge en hint om hur "man gör"?

Får också tillägga att det står så här i databladet:
If a Page Write command attempts to write across a physical page boundary, the result is that the data wraps around to the beginning of the current page (overwriting data previously stored there), instead of being written to the next page as might be expected.

[Icecap]

Mitt bud:
* Du har 2 bit över.
* En raderat byte brukar innehålla '1' i alla bits.

Lösning:
Läs från början och kolla om endera "använd"-bit är '0'. Är den '1' är det en tom plats och du skriver dit.
Såklart måste du skriva '0' till "använd"-bit'en.

Och du markerar "roll-around" vid att läsa byten efter senaste sparade block och säkra att "Använd"-bit'en sätts till '1'.

På detta sätt kommer den att fylla upp automatisk från raderat EEPROM till "överfull", helt utan ändring eller "specialfall" i mjukvaran.

Självklart kan du snabba upp det hela vid att ha en index-variabel i RAM och sedan sätta rätt värde i den vid uppstart, då släpper rutinen att läsa hela EEPROM'en från start när en ny block ska sparas.

[janno]

Kommer du ha en realtidsklocka med batteribackup?
Jag tänkte om du ska spara två värden per dygn så håller du säkert reda på tiden på något vis, kanske med en RTC. I de flesta RTC så finns det ett par byte där man kan spara t.ex. en indexräknare för den sista eller nästa post i EEPROMet vilket som man känner bäst för. O då hittar du nästa plats via:

Kod: Markera allt

 index * sizeof(datastruct)

Icecap's förslag fungerar ju också utmärkt, men det blir ju som han nämner massa mera läsning från minnet.

[Magnus_K]

Ja det är kloka tips ni ger.

Bra tips att använda de två outnyttjade bitarna Icecap! En helt klart bra metod.

Att logga 2 ggr per dygn är inget direkt vetenskaplig uträkning men med tanke på att det här är ett hobbyprojekt så varför inte pressa in en RTC också? Har aldrig gjort det innan men det är nog på tiden.

Vet inte riktigt vad jag söka efter för parametrar till RTC:n men då det finns en ganska ny tråd om RTC MCP7940N så ser jag nog direkt vad du menar janno.
Här verkar dom kalla det minnet för SRAM.

Ska absolut klura vidare i dessa banor men då känns det som en ganska vettig lösning att spara index-variabeln i RTC:n.

Tyvärr förstår jag inte kodsnutten du postat janno men jag ska kolla vidare på det. sizeof(datastruct) lär ju i alla fall ge tillbaka storleken på "datastruct", men vad index * gör vet jag inte.

[Mr Andersson]

Om du har ett index på hur många loggningar du redan sparat och multiplicerar med storleken på en logg (förutsatt att storleken inte ändras mellan loggningar) så får du adressen du ska spara nästa logg på.
Eller så kan du göra tvärtom, om du håller reda på nästa lediga adress så får du antal sparade loggar med adress / sizeof(datastruct).

[Magnus_K]

Jo precis. Det var så jag försökte förklara att jag hade gjort utan att veta om det är bästa metoden eller inte. Problemet är väl just att om µC:n blir spänningslös en längre tid så förloras ju just värdet i index-variablen.

Som jag förstod det så var det här RTC:n kom i bild. Om man ändå har en sån så kan index-variabeln sparas/hämtas därifrån.
Nej jag vet inte, det kanske är att krångla till det också.
Kanske är en metod att använda de två första byten på EEPROM:et som ett avsett "detta-är-nästa-skriv-adress"-utrymme?

Så vid varje loggning så lägger man också på en skrivning till dom två första byten på minnet där nästa adress sparas.
När µC:n kommer online efter ett tag utan spänning så får logg-funktionen börja att hämta värdet från EEPROM:et och sen skriva.

Låter det klokt?

[Mr Andersson]

Jo så har jag gjort tidigare (sparat 'nästa lediga adress' på minnesadress 0) och jag tycker det fungerar fint i de lägen när man inte behöver ett fullständigt filsystem.

[Icecap]

I grunden fungerar det helt fint att spara Index i EEPROM - men rör det sig om många skrivningar kommer den lokation att skrivas sönder långt innan resten av minnet är slitet.

Det är enkelt att - vid reset - läsa igenom EEPROM'et efter senaste entry om man markerar som jag beskrev ovan.
Denna sökning tar lite tid - men sker bara vid just reset. Sedan kan man spara Index i RAM-minnet på µC'n och EEPROM'en belastas lika över hela arean.

Ska du använda en RTC anser jag att loggningen bör innehålla datum & tid ut över data, evt. en "slog på yyy-mm-dd hh:mm:ss" och sedan loggning av data. Detta blir mer komplicerat att styra men kan spara mycket plats i loggningsminnet. Man får helt enkelt välja rätt metod och basera vad "rätt metod" är på vilka behov som finns.