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
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
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
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
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
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
@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.
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
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
>>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.
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
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
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.
>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.
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
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:
1 | struct log_entry |
2 | {
|
3 | uint32_t timestamp; |
4 | uint8_t gps[12]; /* size just as an example */ |
5 | };
|
6 | |
7 | struct log_entry entry; |
8 | offset_t file_offset; |
9 | |
10 | /* ... open card/partition/file ... */
|
11 | |
12 | /* search end of last recording */
|
13 | while(fat_read_file(fd, &entry, sizeof(entry)) > 0) |
14 | {
|
15 | if(entry.timestamp != 0) |
16 | {
|
17 | file_offset = -((offset_t) sizeof(entry)); |
18 | fat_seek_file(fd, &file_offset, FAT_SEEK_CUR); |
19 | break; |
20 | }
|
21 | }
|
22 | |
23 | /* main recording loop */
|
24 | while(1) |
25 | {
|
26 | gps_receive(entry.gps, sizeof(entry.gps); |
27 | entry.timestamp = clock_now(); |
28 | |
29 | file_offset += fat_write_file(fd, &entry, sizeof(entry)); |
30 | }
|
Die eigentliche Realisierung ist aber Deine Aufgabe. Grüße, Roland
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.
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)
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=MjEzOTg3OTk=&ts=40
Hallo also etwa sowas ===>http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=B318;GROUPID=3148;ARTICLE=19396;START=0;SORT=user;OFFSET=16;SID=31XMMj3qwQAR8AAApHlEkae535059485831c5f64f055c1b01bd7a Wenn schon denn schon, das sind doch 470 mF oder habe ich mich vertan? MfG Achim
GPS'ler schrieb: > Hallo > > also etwa sowas > ===>http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=B318;GROUPID=3148;ARTICLE=19396;START=0;SORT=user;OFFSET=16;SID=31XMMj3qwQAR8AAApHlEkae535059485831c5f64f055c1b01bd7a 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.
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.