SD kaart uitlezen

[bart0l0meus]

Hallo,

Ik ben bezig met een soort datalogger te bouwen.
Het is de bedoeling dat wanneer hij op de ADC van de uController een afwijkend spanningsniveau opmerkt, de waarden 30 seconden voor het incident en 90 seconden na het incident opslaat op een SD-kaartje.
Nu zit ik met het volgende probleem. Namelijk geheugen, want als ik het goed zie is dit een zware applicatie voor het uController geheugen en zal hij dit niet met zijn eigen sram kunnen oplossen.
De eis is namelijk ook dat er gemeten wordt met een baudrate van 200, wat dus neerkomt bij een 8bits ADC op 1B * 200 * 120 op 24000B als ik het goed bereken.
Is een SD kaartje snel genoeg om dit snel op te slaan?
En hoe zou ik dit het beste/slimste kunnen aanpakken?

[donzz]

dat ligt er natuurlijk aan hoe vaak die events voorkomen.. als je uC meer dan 24k geheugen over heeft, zetje het daar in, en begin je met wegschrijven als het event voorkomt.. daar kan je dan de tijd voor nemen tot het volgende event.
constant overschrijven van die 30 seconden op je sd kaartje zou ik niet aan beginnen, daar is flash niet zo goed in

[ Voor 9% gewijzigd door donzz op 02-09-2008 15:08 . Reden: verduidelijkt ]

[bart0l0meus]

we wouden eigenlijk de Mega88 gebruiken, maar volgens mij heeft die toch geen 24K geheugen, ik denk sowiso dat er neit veel uControllers zijn die zo veel geheugen hebben

[SA007]

Dan zou ik er een stuk sram aan gaan hangen wat dat wel heeft, want een stuk flash continue overschijven is een erg slecht idee.

Wat bedoel je trouwens met 'meten met een baudrate'?
een baudrate geeft een transmissiesnelheid aan, geen meetinterval ofzo.
Als je 200 metingen per seconde doet, op 8 bit is dat 5.86kB aan info voor de 30 sec die je in geheugen wil houden voor je het wegschrijft.

Dat is wel bijna 6x meer dan je Atmega in zijn eigen mem kan houden.

Wat voor signaal meet je? gewoon een stabiele spanning? dan kan je natuurlijk best je data (flink) compressen door van 8 naar 4 bit te gaan en alleen het verschil ten opzichte van de vorige meting aan te geven.

Maarjah, sram kost geen hout, dus zou gewoon een stuk aan je atmega knopen.

[Tim_bots]

Het is misschien niet helemaal wat je niet zoekt maar om de code om een SD kaart aan te sturen middels een Atmel-ic is te vinden op http://www.roland-riegel.de/sd-reader/index.html.

Met deze code is het mij gelukt om middels een overgeklokte Atmega32 (op 20MHz) met een constante baudrate van +- 2400baud een gedeelte van de data van een GPS ontvanger (origineel op 4800 baud) wegschrijven.

Mocht je meer willen weten stuur me maar een DM en mijn post over dit project hier op de GOT [AVR] Data van de UART/GPS op een SD kaart schrijven

[bart0l0meus]

Het is de bedoeling dat we continu een hartslag meten aan de hand van een ecg.
Hierbij zijn 2 eisen:
gevoeligheid van 1mv, dus dan hebben we minimaal een resolutie van 8Bit nodig en de AD-conversie moet worden gedaan met een 200 baud samplerate.

We willen hierbij ook een lcd scherm aansturen, een RTC uitlezen via I2C en nog wat andere I/O functies.

Zou een Atmega met 8K wel genoeg zijn, of zou dat nog erg krap zijn?
We zijn pas beginnelingen, dus we zullen niet de meest efficiënte code kunnen schrijven.

@Tim, Bedankt, ik had de link al gevonden!
Alleen 1 vraag, de data, is die op de pc beschikbaar in een .txt file, of als wat voor file?

[bobo1on1]

8 bits is genoeg als je een gevoeligheid van 1 mv wilt? Als je niet meer dan 255 mv wilt meten wel ja.

Met 200 bytes per seconde naar een sd card schrijven is niet zo erg, door de wear leveling kun je wel een jaartje of 3000 vooruit.
Een groter probleem is dat het geheugen van sd cards nogal slecht van kwaliteit is, als je zo'n ding koopt zijn er meestal al een paar blocks stuk en de kans is groot dat na een paar keer schrijven er nog een aantal stuk gaan, dat is niet erg als er maar een enkel bitje stuk is, alleen als er meerdere stuk zijn kan de geheugencontroller de data niet meer repareren en heb je dus een foute byte in de data zitten.
Dat kun je op zich prima opvangen door de data bijvoorbeeld 10x weg te schrijven, de kans dat er dan een sample corrupt wordt is dan ineens heel klein geworden.

[Tim_bots]

Middels de functie fat16_write_file in de library is het mogelijk om de data in een willekeurig formaat op te slaan. Als jij er dus ascii tekens in zet en je maakt een .txt file aan dan is het een txt bestand. Wil je graag iets anders is dat ook geen probleem.

Wat nog kan helpen bij de ontwikkeling van een dergelijk programma is om te beginnen met een grotere controller (atmega 168 = atmega 88 maar met 16K) en als het nodig is (en het past) een kleinere te pakken voor de productie.

Toch kun je in 8K ook al een behoorlijk programma kwijt.

[bart0l0meus]

Dankje Tim,
En hoe makkelijk is het om extern sram module te plaatsen?
Ik heb de ATmega 1284P gevonden die ideaal zou zijn voor ons project, maar die kan ik nergens op webwinkels vinden.

[ Voor 32% gewijzigd door bart0l0meus op 03-09-2008 21:15 ]

[ls470]

Als je rechtstreeks op een SD kaartje wilt opnemen is met een 200MHz MIPS processor een snelheid rond de 200kB/s mogelijk, terwijl je maar 200B/s nodig hebt. Een SRAM buffer gebruiken is dus helemaal niet nodig als je de nodige libraries hebt (of kunt schrijven) om rechtstreeks op een SD kaart te schrijven.
@bobo1on1: een SD kaart heeft een ingebouwde controller, waardoor het toch niet mag uitmaken dat er slechte blocks in het geheugen zitten? (de controller zorgt zelf dat die niet meer gebruikt worden, en heeft normaal voldoende ECC voor het type flashgeheugen dat gebruikt wordt)

[Nijn]

bobo1on1 schreef op dinsdag 02 september 2008 @ 23:03:
Een groter probleem is dat het geheugen van sd cards nogal slecht van kwaliteit is, als je zo'n ding koopt zijn er meestal al een paar blocks stuk en de kans is groot dat na een paar keer schrijven er nog een aantal stuk gaan, dat is niet erg als er maar een enkel bitje stuk is, alleen als er meerdere stuk zijn kan de geheugencontroller de data niet meer repareren en heb je dus een foute byte in de data zitten.
Dat kun je op zich prima opvangen door de data bijvoorbeeld 10x weg te schrijven, de kans dat er dan een sample corrupt wordt is dan ineens heel klein geworden.

Ik denk dat je toch even in de techniek moet gaan duiken. Allereerst gaan de gates vrijwel alleen kapot door naar de SD kaar te schrijven, niet door ze te lezen. Een veel betere manier zou dus zijn om na het wegschrijven de data te verifiëren. Maar zelfs dat is niet nodig, omdat de kaart zelf al een hoop voor je doet. De precieze algoritmes verschillen per fabrikant, maar dat zit wel goed hoor.

Mijn advies is dan ook: SD kaartjes zijn lekker makkelijk aan te sturen met AVR's. Blijf daar dan ook bij en gebruik lekker SD. Neem een kaartje dat wat meer capaciteit heeft dan jij nodig hebt. (Al zal dat niet gek lastig zijn). Aangezien je steeds met kleine datapakketjes werkt en nooit de hele kaart vol krijgt kan de wear leveling van de kaart prima zijn werk doen. Natuurlijk zullen er wat blocks uitvallen, maar de kaart registreert dat uit zichzelf en slaat ze in het vervolg over. Je zou het even moeten uitrekenen, maar ik denk dat als jij het kaartje eens per 2 maanden vervangt je al erg voorzichtig bent. (Natuurlijk ook afhankelijk van hoe lang je dat apparaat laat draaien)

[ Voor 3% gewijzigd door Nijn op 04-09-2008 00:46 ]

[bobo1on1]

Nijn schreef op donderdag 04 september 2008 @ 00:45:
[...]


Ik denk dat je toch even in de techniek moet gaan duiken. Allereerst gaan de gates vrijwel alleen kapot door naar de SD kaar te schrijven, niet door ze te lezen. Een veel betere manier zou dus zijn om na het wegschrijven de data te verifiëren. Maar zelfs dat is niet nodig, omdat de kaart zelf al een hoop voor je doet. De precieze algoritmes verschillen per fabrikant, maar dat zit wel goed hoor.

Ik denk dat jij moet leren lezen, je schrijft bijna precies hetzelfde als ik.

Waar sd cards stuk van gaan is het erasen, denk je dat het handig is om bijvoorbeeld een kilobyte te controleren elke keer als je een enkele byte wegschrijft? Waar ga je het mee controleren?

SD cards zijn best goed in het opvangen van fouten, maar ze zijn absoluut niet feilloos, als je data belangrijk is wil je wel enige redundancy.

[ Voor 22% gewijzigd door bobo1on1 op 04-09-2008 01:23 ]

[Nijn]

Waar sd cards stuk van gaan is het erasen, denk je dat het handig is om bijvoorbeeld een kilobyte te controleren elke keer als je een enkele byte wegschrijft? Waar ga je het mee controleren?

Ik zie het probleem niet hoor...

Afhankelijk van de kaart detecteren ze zelf al of er een gate defect is, verifiëren ze zelf de data of (in ieder geval) schrijven ze recovery data weg. Dat zou al ruim voldoende moeten zijn, en is het ook. Mits je natuurlijk geen prut-kwaliteit gebruikt of te oude kaartjes.

Als je dan toch zeker wilt zijn van je zaak, dan kun je, zoals ik al eerder zei, alle data nogmaals teruglezen. Als je dat een beetje slim programmeerd (bufferen) hoef je niet voor iedere byte een hele KB terug te lezen...

Dat is niet alleen minder time-consuming dan 10x wegschrijven, je hoeft ook veel minder rekening te houden met storingen door wear.

[ Voor 8% gewijzigd door Nijn op 04-09-2008 03:25 ]

[ls470]

Mensen, jullie zijn nogal extreem pessimistisch over die kaartjes!
Bij het schrijven en wissen detecteert de NAND chip zelf dat het faalt (verify fail), zodat de controller de beschreven sector als slecht aanduidt en de pagina opnieuw op een andere sector schrijft.
Alleen als je echt kritische data op die SD kaart zet (of een of andere antieke witteproduct-kaart koopt, liefst geproduceerd rond 1998-2000 toen SILC nog onderschat werd en onbetrouwbaardere geheugenchips gemaakt zijn) zijn meer voorzorgen nodig (maar dan zou je toch sowieso geen gewone microcontroller kunnen gebruiken omdat die ook niet voldoende betrouwbaarheidswaarborg geeft).
Als je rechtstreeks een NAND chip zou aansturen ligt de zaak anders, maar het mooie van SD kaartjes is dat de controller al het vuile werk al opknapt.