www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SD Card GPS Logger optimieren?


Autor: Sucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich speile derzeit mit einm GPS Modul und möchte die Daten auf ne SD 
Karte loggen. Die einzelnen Projekte habe ich mir schon angeschaut und 
auch die Suche benutzt.
Es gibt ja viele verschiedene SD (GPS)Karten Anbindungen mit nem 
AtmegaXX. Ich bin jedoch (noch?) nicht in der Lage die einzelnen 
Feinheiten zu erfassen. Das Problem ist doch folgendes: Eigentlich 
möchte man jede Sekunde einige NMEA Strings auf die Karte schreiben. 
Wenn man das aber so macht ist die Karte (Flash) bald hinüber. Bei den 
einzelnen Implementierungen ist für mich nicht ersichtlich, wann zum 
Beispiel die FAT neu geschrieben wird. Das sollte man ja auf ein Minimum 
reduzieren,oder?
Die Daten zu sammeln ist ne andere möglichkeit, erfordert aber auch viel 
Ramspeicher. Welche FAT bzw. SD Card Anbindung ist dafür geignet, ohne 
dass man die Tiefen der SD Anbindung verstehen muß?
Könnten da welche Tipps geben die sich mit dieser Thematik beschäftigt 
haben und sowas realisiert haben?

Vielen Dank
Achim

Autor: Uwe Berger (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MoinMoin,

> Die Daten zu sammeln ist ne andere möglichkeit, erfordert aber auch viel
> Ramspeicher.
>
der Ansatz ist doch schon mal gar nicht so schlecht. Es kommt doch nur 
darauf an, soviel Daten zu puffern, um z.B. soviel zusammen zu haben, 
dass die Schreibroutinen nicht unnötig auf die kleinst mögliche Einheit 
(besagte 512Byte Blockgröße) mehrmals updaten. D.h. doch also nur, dass 
du solange sammelst bis 512Byte zusammen sind und schreibst dann auf die 
SD-Card.

Ok, dass könnte nun bei kleineren MCs (m8, m168 usw.) zu Platzproblemen 
führen, denn die haben nur 1KByte SRAM und damit wären sie schon 
"ausgebucht". Aber wie wäre es, ein externes Speichermedium von ein paar 
kByte mit einzubeziehen. Da gibt es doch einiges, was via SPI, TWI oder 
1wire leicht anschließbar ist.

Grüße Uwe

Autor: Sucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

@Uwe das mit den Datenblöcken von 512 Byte ist mir in der Zwischenzeit 
klarer geworden. Das Problem ist doch aber die FAT die wird doch wohl 
bei jedem Blockwrite aktualisiert, oder ist das falsch? Das würde doch 
bedeuten, dass der Sektor mit der FAT am ehesten kaputt geht, oder wie 
kann man dieses Problem umgehen?
Das andere Problem ist ja, wenn man nicht zwischendurch flusht oder 
closed, dass die Daten bei einem Absturz oder Spannungsausfall weg sind 
bzw nicht verkettet sind? Ich sammle eben Tipps, die diese Probleme 
minimieren?

Hast Du ne Hausnummer von Reichelt für einen SPI (S)-Ram-Speicher?

MfG
Achim

Autor: Roland Riegel (roland) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Achim,

In der Regel puffert man 512-Byte-Blöcke, die man als ganzes auf die 
Karte schreibt. Ich denke, das bei Karten, die nicht zu alt sind, die 
Wear-Leveling-Algorithmen schon weit genug ausgereift sind, so dass man 
sich um dieses Thema keine allzu großen Sorgen machen muss.

Bei meinem sd-reader wird automatisch ein Schreibpuffer von 512 Bytes 
verwendet, so dass Du das nicht mal in der Anwendung zu erledigen 
brauchst. Allerdings musst Du dann vorher die Datei auf die gewünschte 
Größe aufblasen, damit bei Zugriff auf Verwaltungsstrukturen der Puffer 
nicht doch schon rausgeschrieben werden muss.

Zur FAT: Die FAT verwaltet nur Cluster, d.h. Einheiten von mehreren kB 
Größe. Sie muss also nur geschrieben werden, wenn beim Vergrößern 
Clustergrenzen überschritten werden.

Etwas anderes sind die Verzeichniseinträge der einzelnen Dateien, die 
die genaue Dateilänge Byte-genau speichern. Diese Einträge müssen also 
wirklich bei jeder Dateigrößenänderung verändert werden. Deshalb rate 
ich, die Dateien vor dem ersten Beschreiben auf die gewünschte Endgröße 
zu vergrößern, das bietet zusätzlich auch Performance-Vorteile.

Viele Grüße,
Roland

Autor: Potter68 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Zusammenhänge von Cluster und Sektoren sind für die verschiedenen 
SD-Karten abhängig von deren Größe. Wenn man z.B. von 1 GByte-Karten 
ausgeht, so hat man eine Sektorgröße von 512 Byte (wie Roland schon 
sagte) und eine Cluster-Größe von 32 Sektoren. D.h. alle 32*512 Bytes 
wird ein neuer Eintrag in der FAT notwendig.

Man kann jetzt hergehen, und eine Datei anlegen, die man fortwährend 
beschreibt - also Sektor für Sektor und Cluster für Cluster. Was bei 
einem Stromausfall allerdings zum kompletten Datenverlust führt (die 
Daten sind zwar auf der Karte aber die Dateigröße ist nicht entsprechend 
angepasst. Immer vorausgesetzt, man aktualisiert nicht fortlaufend den 
Dateieintrag). Oder man beginnt spätestens nach 32*512 Bytes eine neue 
Datei. Den neuen Cluster muss man sowieso anlegen und zusätzlich sind 
die bereits gesammelten Daten gespeichert.

Gruß Potter68

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Man kann jetzt hergehen, und eine Datei anlegen, die man fortwährend
>beschreibt - also Sektor für Sektor und Cluster für Cluster. Was bei
>einem Stromausfall allerdings zum kompletten Datenverlust führt (die
>Daten sind zwar auf der Karte aber die Dateigröße....

Im Prinzip kann man auf der µC-Seite auf ein Dateisystem verzichten. Auf 
einer leeren Karte am PC eine Datei in der Grösse des freien 
Speicherplatzes anlegen und mit einem Diskeditor den Anfang ermitteln. 
Der µC braucht dann nur ab der Stelle anfangen zu Schreiben.

MfG Spess

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@spess

Es ist aber ziemlich unflexibel.
Man könnte ja glatt mal auf die Idee
kommen beliebige Karten zu benutzen.
Mit einem vernünftigen FAT Dateisystem kann man den
Einsatz des Diskeditors vermeiden.

Die Lösung von Roland gefällt mir immer noch
am besten. Datei mit fester Größe anlegen. Diese
kann ja durchaus die gesamte Karte belegen. Alle
Cluster sind dann belegt, und die FAT sowie die Dateigröße muß
nicht mehr aktualisiert werden.

Das Problem bei der großen Datei ist rauszufinden ab
wo man Daten wieder dranhängen kann.

Mehrere kleine Dateien zu benutzen wie Potter68
vorschlägt ist auch eine praktikable Lösung.
Erfordert aber wesentlich mehr Schreibzugriffe.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso so einen Pfusch mit der vorgefertigten Datei machen wenn es auch 
ordentlich geht?
Man nehme ein ordentliches Dateisystem wie z.B. das hier:
http://elm-chan.org/fsw/ff/00index_e.html
Das schreibt nur wenn ein Sektor voll ist. Man sollte aber alleine aus 
Gründen des Datenverlusts bei plötzlichem Spannungsausfall häufiger mal 
auch die FAT Tabelle abspeichern. (Abschnitt "Critical Section" auf 
dieser Seite: http://elm-chan.org/fsw/ff/en/appnote.html)

Davon abgesehen würde ich mir bei einem Preis von <5€ für eine SD Karte 
keine großen Gedanken um die Lebensdauer machen:
Bei einer Lebensdauer von sagen wir mal 10000 Schreibzyklen und einer 
NMEA Datensatzgröße von 256Bytes dauert es etwa 48 Tage bis eine 1GB 
Karte voll ist. Dann ist jeder Block einmal beschrieben. Ok, die FAT 
Tabelle gibts auch noch, also wird jeder Sektor häufiger beschrieben 
durch das wear Leveling. Selbst wenn man hier einen Faktor von 10 lebt 
die Karte dann immer noch 131 Jahre.

Und wenn man ganz faul ist, nimmt man direkt die fertige Lösung:
http://elm-chan.org/works/glg/report_e.html

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Das Thema lautete: '... optimieren'. Und ich finde es optimal, wenn ich 
in einem speziellen Fall keinen unnötigen Ballast habe.

>Das Problem bei der großen Datei ist rauszufinden ab
>wo man Daten wieder dranhängen kann.

Dann fehlt es dir an Fantasie. Z.B. den ersten Sektor dafür opfern?

>Wieso so einen Pfusch mit der vorgefertigten Datei machen wenn es auch
>ordentlich geht?

Dort wo es notwendig ist , ja.

>Davon abgesehen würde ich mir bei einem Preis von <5€ für eine SD Karte...

Und genau deshalb kann man sich ein paar Karten für diesen Zweck 
spendieren und lebt sorglos bis das der....

Mfg Spess

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Das Problem bei der großen Datei ist rauszufinden ab
>>wo man Daten wieder dranhängen kann.

>Dann fehlt es dir an Fantasie.

Danke! Ich weiß schon wie man das macht.
Und ich weiß auch wie man das richtig macht.

Deinen Schrott mit Diskeditor kannst du dir an
die Backe schmieren. Sowas machen nur Pfuscher.

Autor: GPS'ler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

zusammen. Bitte keinen Streit!
 Der Thread heißt optimieren. Ich möchte nicht die Lebenszeit von 130 
Jahre auf 135 Jahre erweitern. Ich möchte nur Klarheit darüber, wie man 
einen Dauerlogger (ständig erfassen) unter den einzelnen 
Implementierungen betreibt. Der Datensektor ist schon klar. 512 Byte 
Zwischenpuffern und rausschreiben. Nur mir ist halt nicht klar wie und 
wann in der FAT rumgenudelt wir. Und es ist doch nicht verboten, sich 
darüber Gedanken zu machen, selbst wenn ne SD Karte 5€ kostet und 100 
Jahre hält.
Bei einem Batteriegerät sollten eben auch bei einem AUsfall wenig Daten 
verloren gehen. Einen Tag loggen und dan Ausfall sollte nicht sein.

Also falls die entprechenden "Realisierer" mitlesen, bitte ich um die 
"richtige" Vorgehensweise für folgende

Aufgabe:

Kontinuierlicher Datenstrom aufzeichen (Dauerbetrieb) und bei Ausfall 
möglichst wenig Datenverlust.


MfG
Achim

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Und ich weiß auch wie man das richtig macht.

Ich auch. Aber was ist richtig? Eine komplizierte Lösung für alle 
Probleme, oder eine einfache Lösung für ein spezielles Problem.

>Sowas machen nur Pfuscher.

Nein, nur Leute, die praktisch denken.

Da sich 'Sucher (Gast)' eh noch nicht wieder gemeldet hat, wird sich das 
sowieso erledigt haben.

MfG Spess

Autor: GPS'ler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Spess hat sich nicht erledigt Sucher=GPS'ler

Sorry

MfG
Achim

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GPS'ler schrieb:
> Nur mir ist halt nicht klar wie und
> wann in der FAT rumgenudelt wir.

Jedesmal wenn ein neuer Cluster angefangen wird (in der Praxis also alle 
4-16 Sektoren je nach Clustergröße). Wobei das Dateisystem aber auch das 
nur dann auf die Karte schreibt wenn die FAT in einen anderen Sektor 
rutscht der gerade nicht im RAM gepuffert wird.
Theoretisch müsste bei jedem Schreiben auch das Verzeichnis aktualisiert 
werden, da hier die Dateigröße verzeichnet wird. Dies wird aber 
üblicherweiße nur beim Schließen der Datei gemacht.

Die Optimierung bei einem Logger sollte daher eher in die Richtung 
gehen, wie man die Datensicherheit bei Spannungsausfall oder einem 
Absturz gewährleistet, also einen Kompromiss zwischen Pufferung im RAM 
und Anzahl an Schreibzugriffen zu finden.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>also einen Kompromiss zwischen Pufferung im RAM
>und Anzahl an Schreibzugriffen zu finden.

Und den besten Kompromiss bietet halt eine
Datei die schon vorhanden ist und deren Größe
nicht verändert wird.

Alle Cluster der Datei sind in der FAT Tabelle
dann bereits eingetragen. Der Verzeichniseintrag
muß auch nicht aktualisiert werden. Es sei denn man
legt Wert darauf ein Schreibdatum einzutragen.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Problem dabei ist ja, dass es kein Journaling bei Fat gibt 
http://de.wikipedia.org/wiki/Journaling-Dateisystem

Klar, könnte man einbauen, aber wäre dann eben auch nicht mehr Fat.

Ich bin auch der Meinung, eine etwas schmutzige Lösung wie die 
angesprochene mit dem Vorverketten einer Datei zur Datensicherheit ist 
schon Ok. Aber gleich die ganze Karte?

Wenn man wirklich nur GPS loggen will, hat man ja auch immer eine 
Sekunde Pause zwischen den paar Bytes die man wegschreiben will. Da hat 
man massig Zeit für verschiedenste Ansätze (werden ja sogar bei den 
meisten Lib's noch 512 Bytes gepuffert also hat man noch länger Zeit).

Wer bei seinem mit Fat Formatierten Pc beim schreiben einfach den 
Stromstecker zieht hat auch Probleme mit den Dateien...

Den Controller mit Notstrom versorgen (großer Elko) wäre eine Hardware 
Lösung...

Grüße Daniel

Autor: Roland Riegel (roland) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Achim,

> Nur mir ist halt nicht klar wie und
> wann in der FAT rumgenudelt wir.

Wie oben schon beschrieben. Immer dann, wenn die Dateigröße geändert 
wird und dabei gleichzeitig ein Vielfaches der Clustergröße über- oder 
unterschritten wird.

Wenn Du vor Start der Aufzeichnung die Datei auf die vorgesehende 
Endgröße vergrößert hast, wird die FAT und auch der Verzeichniseintrag 
während der Aufzeichnung nicht mehr angefasst. Die aktuelle Position 
innerhalb der teilweise gefüllten Datei kannst Du Dir entweder z.B. in 
den ersten vier Bytes merken oder Du gehst die Datei sequentiell durch 
und schaust, wo der erste ungültige (d.h. nur mit Nullen gefüllte) 
Eintrag steht.

> Bei einem Batteriegerät sollten eben auch bei einem AUsfall wenig Daten
> verloren gehen. Einen Tag loggen und dan Ausfall sollte nicht sein.

Ist ja auch nicht so. Das Intervall, nach dem Du jeweils die gepufferten 
Daten rausschreibst, kannst Du selbst bestimmen. Beim sd-reader gibt es 
dafür die Funktion sd_raw_sync(), ansonsten aber spätestens nach jeweils 
512 Bytes.

> Aufgabe:
>
> Kontinuierlicher Datenstrom aufzeichen (Dauerbetrieb) und bei Ausfall
> möglichst wenig Datenverlust.

Pseudocode mit dem sd-reader:
struct log_entry
{
    uint32_t timestamp;
    uint8_t gps[12]; /* size just as an example */
};

struct log_entry entry;
offset_t file_offset;

/* ... open card/partition/file ... */

/* search end of last recording */
while(fat_read_file(fd, &entry, sizeof(entry)) > 0)
{
    if(entry.timestamp != 0)
    {
        file_offset = -((offset_t) sizeof(entry));
        fat_seek_file(fd, &file_offset, FAT_SEEK_CUR);
        break;
    }
} 

/* main recording loop */
while(1)
{
    gps_receive(entry.gps, sizeof(entry.gps);
    entry.timestamp = clock_now();

    file_offset += fat_write_file(fd, &entry, sizeof(entry));
}

Die eigentliche Realisierung ist aber Deine Aufgabe.

Grüße,
Roland

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann er nicht einen ADC Pin für die Spannungsüberwachung opfern.
Ab einem gewissen Spannungspegel vor dem Spannungsregler wird halt die 
Datei geschlossen. mit einem relativ großen Puffer Elko sollte das doch 
machbar sein. Den GPS Empfänger kann er ja gleich bei erkennen 
abschalten so das nur noch die Karte und der µC kurzzeitig versorgt 
werden müssen.

Autor: GPS'ler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

zunächst mal vielen Dank für die Antworten.

Kann mir jemand vom Gefühl oder Wissen sagen, wie groß in etwa der Elko 
für eine "letzte" Schreiboperation und schließen der Datei sein sollte?
Ich sehe zwischenzeitlich klarer.
Ich habe auch noch ne informative Seite dazu gefunden. Der Link wurde 
oben gepostet (http://elm-chan.org/works/glg/report_e.html).

>>Die eigentliche Realisierung ist aber Deine Aufgabe.

Das ist klar. Aber Augen zu und anfangen ist sicherlich nerventötend. 
Allso vielen Dank für die Tipps!


Vielen Dank
Achim

Sucher = GPS'ler (Sorry)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GPS'ler schrieb:
> Kann mir jemand vom Gefühl oder Wissen sagen, wie groß in etwa der Elko
> für eine "letzte" Schreiboperation und schließen der Datei sein sollte?

Davon ausgehend dass hier noch 1-2 Sektoren geschrieben werden müssen 
und das durchaus mal ein paar 100ms dauern kann wenn gerade das Wear 
Leveling aktiv wird, und eine SD Karte sich beim Schreiben auch mal 
einige 10 bis 100mA gönnt, sollten es schon ein paar mF sein. 470µF 
reichen jedenfalls nicht, das habe ich schon ausprobiert.

Sowas hier sollte aber reichen:
http://www.pollin.de/shop/detail.php?pg=Ng==&a=MjE...

Autor: GPS'ler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

also etwa sowas
===>http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=B31...

Wenn schon denn schon, das sind doch 470 mF oder habe ich mich vertan?

MfG
Achim

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GPS'ler schrieb:
> Hallo
>
> also etwa sowas
> 
===>http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=B31...

Nein.
Der Unterschied zwischen dem von Pollin und dem von Reichelt ist der 
Innenwiderstand:
Der von Pollin hat <100mOhm, der von Reichelt irgendwas im Bereich von 
>10 Ohm.
Letztere sind vor allem als Ersatz von Akkus in Uhren oder zum Erhalt 
von den Daten in Speichern gedacht, also auf wenig Leckstrom und geringe 
Stromentnahme optimiert.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte doch auch so Low ESR Standard Elkos nehmen wie z.B.
vom Conrad: Artikel-Nr.: 442602 - 62

Der hat 0,027-0,042 Ohm, den dann 2-3 mal parallel, also die drei mal 
(-) an Masse und die 3 mal (+) zur Schaltung.

Da könnte man dann, wenn ich mich nicht verrechnet hab, theoretisch 357 
A Max ziehen.
Oder was besser ist 400ms lang 124mA. Das sollte reichen !

Äh na ja, wenn man dann den Platz dafür hat... 18mmX36mm

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Low ESR müssen die Elkos nicht haben, bei sagen wir mal 100mA macht der 
Unterschied 10mOhm oder 100mOhm keinen großen Unterschied beim 
Spannungsabfall (1mV->10mV). Ob 50 Ohm (wie bei den normalen Goldcaps) 
oder <1 Ohm bei den besseren Ultracaps (oder wie auch immer die heißen), 
dagegen schon (5V -> 0,1V).
Es reichen also normale Elkos aus, solange die ausreichend Kapazität 
haben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.