Svenska ElektronikForumet

För det första, god fortsättning!

Jag har aldrig testat att logga data och inte heller spara/hämta från externa minnen så det finns chans att det blir lite luddigt. Uppskattar om ni har lust att hjälpa mig på traven i så fall.
Detta projekt är inte riktigt vid det här stadiet än men jag ska försöka ta med så mycket relevant information som går.

Säg att jag har ett batteridrivet µC-projekt där jag vill logga diverse data. Samplingen ska göras 1-2 ggr/dag och sparas i ett minnesmedia.
Minnesmediat kan just nu vara precis vad som helst för jag vet inte riktigt skillnaden på de olika. Det skulle kunna vara ett minneskort men spontant känns det som att det är lite mer "tungdrivet" än tex ett EEPROM. Det som är ett krav är att minnet ska spara all data även om det är spänningslöst ett längre tag, tex månader.
Jag vill ha möjligheten att antingen dumpa hela loggen, läsa ut enbart senaste raden samt radera loggen.
Utläsningen ska kunna ske genom något seriellt interface men om det även går att ta bort och ersätta med nytt är bara en bonus.

När det kommer till storlek på datan så tycker jag det är lite svårt. Låt säga att datan som ska loggas ser ut ungefär så här:

• - Spänning: 4,00V
  - Temp: 10,2C
  - I/O #1: 1
  - I/O #2: 0
  - I/O #3: 1

Det enda jag kan komma på är att sparar en sträng som ser ut ungefär som 4,00;10,2;11;20;31.
Om detta är ASCII-tecken så borde den strängen bli 18 byte. Gör jag detta 2 ggr / dag i en månad så borde totala datan bli 18x2x30 = 1080 byte, dvs ~ 1kB.

Har ni lust att fylla i med lite "bra-att-tänka-på" och kanske andra bättre metoder för att logga data?

OpenLog ifrån Sparkfun är löjligt enkel och bra.
Skicka data seriellt i textformat till den så sparas det på ett microSD-kort.
Jag använder den i en temperaturlogger.
https://www.sparkfun.com/products/9530

* Hur lång tid ska du sampla data mellan tömningar?
Detta bestämmer storleken på minne, såklart ihop med sättet du packar ihop det.

Data kan med fördel packas ihop när det ska sparas.
- Spänning: 4,00V
- Temp: 10,2C
- I/O #1: 1
- I/O #2: 0
- I/O #3: 1

Kan packas som:
9 bits för spänningen i steg om 1/100V.
10 bit för temperatur i steg om 1/10°C. Detta ger ±51,1°C i område, man kan enkelt offsetta om det räcker i span men inte i absolut värde.
3 bit för I/O.
Totalt blir det 22 bits och med 3 bytes finns det 24 bits, det blir alltså 2 bits över på detta vis.

Varje loggning kan alltså bestå av 3 bytes.

Det finns seriella FLASH-minnen på flera MB, det finns EEPROM på 32kB osv. så att skriva till minnet är det minsta problem.

Att tömma data via en seriell länk fungerar helt fint, det är enkelt att läsa data i EEPROM och formattera dom som en utskrift.

Fördel är om det finns två kommandon, en för "Skicka alla data" och en annan för "Radera alla gamla data".

Dagens tips: vill man göra en textfil kompatibel med Excel ska man ha en Horisontell Tab ('\t') mellan varje värde och en CRLF ("\r\n") i slutet på varje rad.
Då kan filen importeras direkt i Excel/OpenOffice/LibreOffice.

@Noxin:
Den där modulen ser ju jättebra ut men känns lite väl dyr/overkill för ändamålet. Nu nämnde jag inget om budget i första inlägget men hade hoppats att man kunde komma undan lite billigare än 25 dollars.

@Icecap:
Enligt rutin ett bra svar! Tack för det.

Vet inte än ofta jag räknar med att tömma men detta kommer givetvis spikas innan storlek på minnet bestäms.
Ser också att du tänker lite mer effektivt än vad jag gjort när det kommer till hur man komprimerar datan. Som du gjort så blir det ju tillräcklig upplösning och formatteringen kan man lösa efteråt.
Tack för tipset om hur man kan underlätta exporteringen också!

Av ren lathet så ställer jag frågan här istället för att scanna internet. Kan man säga generellt att en skrivning till ett EEPROM kräver mindre ström än till ett FLASH-kort? Tanken är att µC:n ligger och vilar och likaså minnesmediat. Endast vid loggning ska dessa vakna till liv.
Ett EEPROM/FLASH kanske inte fungerar så? Dom kanske aldrig drar någon ström förrän du skriver/läser data?

Du har såklart en pinne som slår på strömmen till minnet när du behöver det! Då kan du spara väldigt på strömmen till detta.

Kolla på ELFA, de har lite seriella FLASH och EEPROM, jämför strömförbrukningen osv. Men med skrivning en eller ett par gg/dygn och behov av att snåla med strömmen är det klart att du slår av strömmen när du inte använder det. Med lite tur drar det mindre vid skrivning än en portpinne kan ge, då behöver du ingen transistor.

Kom bara ihåg att slå alla pinnar för kommunikation till '0' när du stänger av strömmen.

Kom ihåg att en MAX232 (eller liknande) drar en del ström! Det kan alltså löna sig i strömbudgeten att känna av om det är inkommande Rx-Data och då slå på kretsen. Jag har ibland använd ett par optokopplare som tar antingen -9V eller +9V (en OC för varje) och då ger signal till µC'n om att kretsen ska slås på. Självklart ska man styra Tx från µC'n också för att spara ström, den är ju '1' i viloläge.

om du använder uC och har dator ansluten så kan du kolla på mitt logg program.

http://elektronikforumet.com/forum/view ... =2&t=54104

Har kika lite mer på FLASH kontra EEPROM och slutsatsen blir nog den att EEPROM passar min applikation bäst.
Inte för att jag jämfört jättemånga alternativ men jag tycker ändå att det ser ut som att FLASH i regel har mycket större minneskapacitet men drar också mer ström än EEPROM:en.

Just nu lutar det nog åt 25LC640A.

Nja jag får grunna lite mer på den seriella kommunikationen för att läsa ur datan. Tack för lite heads-up där Icecap.

@lizerdboy:
Ska kika på ditt loggprogram också, tack för det!

Med tanke på att du kan lagra ganska många mätningar efter "komprimering" så borde det inbyggda 1K EEPROM i t ex AVRmega328 räcka ganska långt och du slipper externa kretsar.

Du har en mycket bra poäng där. Har inte valt vilken µC jag ska använda för projektet än heller men man skulle ju kunna lägga till EEPROM på krav-listan.
Kanon, tack ie!

EEPROM-fråga:

Läser lite i databladet nu (länkat att par inlägg upp) och det är en sak jag inte blir klok på.
När man skriver/läser ett EEPROM så ska man ange adressen där information ska läggas/läsas. Vart kan jag se vilket adress-spann som är möjligt att använda?
Kan väl göra en kvalificerad gissning på databladet men jag tror inte jag vet vad jag ska söka efter riktigt.

Adress 0 och framåt om jag inte missminner mig (på AVR).

Fast det gäller iofs i de EEPROM-funktioner som jag använt i CodevisionAVR och Arduino. Hur det är via assembler vet jag inte.

Magnus_K skrev:När man skriver/läser ett EEPROM så ska man ange adressen där information ska läggas/läsas. Vart kan jag se vilket adress-spann som är möjligt att använda?

0-0x1FFF, 16 bitars adress med 13 effektiva bitar. Tänk även på att det inte går att korsa page-gränser vid skrivning, lätt att missa.

Ah kanon, nu såg jag vad jag skulle leta efter! Tack ska ni ha.

Trodde att adresserna skulle vara något tydligt presenterat men jag gissar att när man väl lärt sig hur det är uppbyggt så kommer det säga sig självt.

Men det var svettigare än vad jag trodde!
Nu kanske jag generaliserar för mycket men om jag än en gång hänvisar till tidigare datablad (Microchip EEPROM), kan man säga grovt att det fungerar så här? :

Detta specifika EEPROM:et har 512 adressplatser med adressplatserna 0x0000 - 0x1FFF. Då varje adress är 16 bitar (3 MSB:s "skräp" och 13 effektiva) så kallas dom således tex 0x0000, 0x0010, 0x0020... 0x1FFE och 0x1FFF.
Varje adressplats är knuten(?) till en page där man kan spara upp till 32 bytes av data. Det totala användbara minnet blir då alltså 32 bytes x 512 pages = 131072 bitar (där har jag nog förstått något fel...)

Precis som Mr Andersson skriver så måste man tänka på att inte skriva mer data än vad en page är stor. Är datan större än så måste denna delas upp på flera pages och det görs inte automatiskt utan man måste sköta detta i mjukvaran.

Ovan är alltså hur jag förstått det efter en genomläsning av databladet. Det var tungt, lite väl mycket nytt på en gång tycker jag.
Jag skulle verkligen uppskatta om någon av er vill ge mig lite rättning vart jag förstått fel. Ni behöver inte förklara om ni inte vill utan bara nämna vad jag behöver läsa på igen.

0x0000-0x1FFF är 8192 adresser. (0x1FFF är 8191 decimalt, plus en plats på adress 0). Varje adress har 8 bitar data. ("8192 x 8-bit Organization" från databladet). Då får du totalt 8192x8=65536 bitar, eller 8192 bytes. Databladet säger även att det är ett 64kbit minne. Sen finns det säkert dom som vill argumentera för att det borde stå kibit istället för kbit.
Jag antar att du missat ett F när du fick 512 eftersom 511 decimalt är 0x1FF hexadecimalt

Pages kan man likna vid att skriva i ett anteckningsblock..
Om du har ett block där varje sida har 32 rader, så om du vill skriva mer än 32 rader (vi antar att du startar på första raden) så måste du ta en paus i skrivandet och vända blad. Samma sak om du är på rad 32 och vill skriva två rader.
Samma sak med minnet. Om du startar på en adress som är en multipel av page-storleken (0, 32, 64, 96, etc) så kan du skriva upp till 32 bytes i ett svep.
Men om du startar på t.ex. address 7 och vill skriva 30 bytes så måste du dela upp det på två skrivningar. 23 bytes med start på adress 7 (du behöver inte ange ny adress mellan varje byte så länge alla bytes skrivs i samma operation, minnet hoppar frammåt själv), och sen 7 bytes med start på adress 32.
Detta gäller alltså inte bara om du vill skriva data som är större än page-storleken utan varje gång du behöver korsa en page-gräns.
Dock kan jag inte svara på exakt varför det är uppbyggt såhär men det finns det säkert någon annan här på forumet som kan.

Hoppas det förklarade saken lite bättre.