Hallo Community, ich will für mein nächstes Projekt den SD Karten zugriff von einem uC (ATmega88) aus realiesieren. Ich weis zu dem Thema SD Karte gibt es einige Threads hier, aber meine Frage hab ich direkt noch nicht gefunden. Ich werde vermutlich entweder die Lib von elm chan oder Daniel R. (also die Lib hier aus dem Forum) verwenden. So wie ich das verstanden habe, stehen bei erst genannten FAT32 oder exFat als Dateisysteme zur Auswahl. Meine Frage wäre jetzt, was die Vor- und Nachteile von FAT32 bzw exFat sind bzw worin die Unterschiede zwischen beiden bestehen. Schon mal vielen Dank im vorraus
Laut Standard gilt: SD nutzt FAT16, SDHC nutzt FAT32, SDXC nutzt exFAT. Treiber für FAT32 gibt es in so ziemlich jedem Betriebssystem und Gerät, die Unterstützung für exFAT ist wesentlich weniger weit verbreitet. Nachtrag: Der einzige relevante Unterschied scheint zu sein, dass exFAT auch Dateien mit mehr als 4 GB unterstützt. Für einen Atmega ist das relativ egal.
:
Bearbeitet durch User
Danke für die schnelle Antwort. Dann werde ich vermutlich FAT32 und die uC.net Lib verwenden
S. R. schrieb: > Für einen Atmega ist das relativ egal. Bei einem Datenlogger mit 1kB pro Sekunde sind die 4 GB schon nach 1 1/2 Monaten voll. ;-) Was hat das mit dem µC zu tun?
S. R. schrieb: > Der einzige relevante Unterschied scheint zu sein, dass exFAT > auch Dateien mit mehr als 4 GB unterstützt. Bei FAT16 (ohne VFAT) geht man anscheinend davon aus, dass das PD ist. Lange Dateinamen sind wohl wasserdichter patentiert. Aber für exFAT braucht man doch bestimmt eine Lizenz? Wolfgang schrieb: > Bei einem Datenlogger mit 1kB pro Sekunde sind die 4 GB schon nach 1 1/2 > Monaten voll. ;-) Wer schreibt schon monatelang in die gleiche Datei? Dann lasse ich doch das Dateisystem gleich ganz weg und brauche keinen Anwalt.
> Meine Frage wäre jetzt, was die Vor- und Nachteile von FAT32 bzw exFat > sind bzw worin die Unterschiede zwischen beiden bestehen. Bei der Verwendung eines Controllers mit 1kb Sram gibt es IMHO ganz andere Dinge ueber die du nachdenken solltest. .-) Olaf
Olaf schrieb: > Bei der Verwendung eines Controllers mit 1kb Sram gibt es IMHO ganz > andere Dinge ueber die du nachdenken solltest. .-) Lies mal nach, wie groß bei den jeweiligen Dateisystemen ein Cluster, also ein logischer Block im Dateisystem ist. Da du bei der Änderung eines Bytes den ganzen Cluster neu schreibst, mußt du den auch im RAM vorhalten können. Und nun gucke nochmal ins Datenblatt, wieviel RAM der von dir angepeilte µC hat. Die Frage nach den Dateisystem sollte allerspätestens jetzt geklärt sein ;-)
Gerald B. schrieb: > Da du bei der Änderung > eines Bytes den ganzen Cluster neu schreibst, mußt du den auch im RAM > vorhalten können. Mööp, falsch. Man muss nur den zu schreibenden 512 Byte Block im RAM halten können - aber auch das wird mit 1kB SRAM eher sportlich. Die 512 Bytes sind die minimale Schreibgröße ab SDHC - und in der Praxis auch für SD, denn die "schreibe weniger als ein Block" (write partial Block) Option habe ich auf keiner der verschiedenen Karten <=2GB hier jemals gesehen.
Ich bin bei kleinen Datenloggern ja immer noch bei EEPROM. Da muss man sich nicht mit Filesystemen rumschlagen.
Jim M. schrieb: > Man muss nur den zu schreibenden 512 Byte Block im RAM halten können - > aber auch das wird mit 1kB SRAM eher sportlich. Die Karten bieten zwar die Möglichkeit, einen 512B-Sektor zu beschreiben, allerdings machen die da auch einen Read-Modify-Write draus. Die tatsächliche Sektor-Größe ist IIRC bis zu 4 MiB. Wenn man jetzt nacheinander die 8192 512B-Sektoren, die so einen 4MiB-Block ausmachen, einzeln beschreibt, hat man (potentiell) 8192 Erase-Zyklen. Das ist langsam und nicht gut für die Lebensdauer (selbst mit Wear-Leveling - irgendwo müssen die ganzen Zwischenstände ja hin). Im Idealfall löscht man daher immer ganze 4MiB-Blöcke, und schreibt diese in einem Rutsch voll. Da das aber mit uC's schwierig ist, kann man auch weniger auf Einmal schreiben. Als guter Kompromiss haben sich hier 16 KiB ergeben. Durch das explizite Löschen weiß der Controller dass der Rest der Daten nicht benötigt wird und vermeidet (hoffentlich) die 8191 unnötigen Zyklen. Die optimale Größe variiert aber mit dem Hersteller. Manche Karten haben auch manchmal extreme Ausreißer bei den Schreib-Zeiten (z.B. SanDisk). Samsung ist hier recht gut. Bei so Mini-Datenraten ist das natürlich nicht so relevant.
> Die 512 Bytes sind die minimale Schreibgröße ab SDHC - und in der Praxis > auch für SD, denn die "schreibe weniger als ein Block" (write partial > Block) Option habe ich auf keiner der verschiedenen Karten <=2GB hier > jemals gesehen. Das habe ich sogar noch nie gesehen und als ich mein erstes FAT Dateisystem programmiert habe waren 8MB Karten mit FAT12 angesagt. .-) Das lesen von kleineren Bloecken hab ich aber irgendwann mal erfolgreich getestet. Man kann bei so kleinen Controllern zum zwecke der Datenspeicherung aber mit einem Trick arbeiten. Man loescht eine Karte komplett und legt da eine Datei drauf an. Da kann man sich dann nach meiner Erfahrung drauf verlassen das am Stueck geschrieben wird. Dann sucht man eine Magicnummer im ersten Sektor der Datei auf der Karte und kann danach Daten an festen Adressen schreiben um am PC mit den ueblichen Filekommandos lesen. Das ist aber eher eine Loesung fuer Entwickler die wissen was sie tun. Sobald Anwender in Spiel kommen gibt das Probleme... Da wir jetzt aber 20Jahre spaeter haben muessen schon sehr gute Gruende vorliegen um noch einen Controllern mit weniger wie 8kb Ram anzupacken. Olaf
Na ja, da in der uC.net SD Lib (unter mmc.h) auch unter anderem der ATMega8 aufgeführt ist, denke ich mal schon, dass der Ram ausreichend dafür ist, auch wenn ich mich dann das restliche Programm bedachter programmieren muss.
SD Card Neuling schrieb: > auch wenn ich mich dann das restliche Programm bedachter > programmieren muss. Ja und denk dran dass ein ATMega328 mindestens das xfache an Strom braucht, da handle ich mir auch lieber die Probleme mit dem kleinen RAM ein. Und immer dran denken den Airbag umzuschnallen wenn du vor die Haustür gehst. Es lebe der Kleingeist.
Angehängte Dateien:
-
ATmega8.png
250 KB -
ATmega328.png
280 KB
Sherlock Holmes schrieb: > und denk dran dass ein ATMega328 mindestens das xfache > an Strom braucht Wie meinst du das? Dass der ATmega328 viel mehr Strom braucht, als der ATmega8?
Alternativ: STM32F407 o.ä. mit 192 KB SRAM nehmen, da kann man schön
viel puffern. Der hat auch ein SDIO-Interface ("SD-bus"), womit man
größere Übertragungsraten erreicht (die Speed Class ist nur für SDIO
definiert, bei SPI ist keine Geschwindigkeit garantiert). Dank DMA kann
man den Prozessor selbsttätig große Datenmengen rausschieben lassen und
nebenher andere Dinge tun (z.B. schnelle ADC-Messungen auch mit DMA).
Der Trick mit der großen Datei ist dann auch nicht mehr so wichtig, weil
man hier recht problemlos nebenher leere Cluster suchen und merken und
an die Datei anhängen kann.
S. R. schrieb: > Der einzige relevante Unterschied scheint zu sein, dass exFAT > auch Dateien mit mehr als 4 GB unterstützt. Rein technisch ist das wirklich der einzig signifikante Unterschied. Rechtlich allerdings macht es einen enormen Unterschied, jedenfalls sobald man den Bereich der rein privaten Nutzung verläßt. Dann muss man nämlich bei exFAT für jede verkaufte Einheit Lizenzgebühren abdrücken. > Für einen Atmega ist das > relativ egal. Leider ist das nicht wirklich der Fall. Die Sache ist nämlich: entweder man zwingt den Nutzer bei entsprechend großen SD-Karten, diese standardwidrig zu formatieren, um sie in der eigenen Anwendung benutzen zu können (was den meisten Benutzern als Normal-DAUs schwerfallen dürfte, weil: Wixdos wird es wohl nicht unterstützen...) oder man löhnt die Lizenz. So sieht's aus. Eine MS-Gelddruckmaschine von Gnaden des SD-Konsortiums... Wenn ich was zu sagen hätte, müßte sowas auf globaler Ebene verboten werden. Offensichtliche Trivialitäten als Geldruckmaschine. Das geht garnicht.
c-hater schrieb: >> Für einen Atmega ist das relativ egal. > Leider ist das nicht wirklich der Fall. Warum nicht? Schreibe "SD-Karten bis 64 GB" in die Anleitung und dein kommerzielles Problem ist gelöst. Oder formatiere die Karte einfach im Gerät, wie es jeder dämliche Fotoapparat auch tut. Unter Windows kann man SD-Karten auch mit NTFS formatieren, die ganzen SBCs nutzen ext4 oder f2fs und manche Smartphones können das auch. Oder brauchst du wirklich eine 128 GB große SD-Karte an einem Atmega8? SD Card Neuling schrieb: > Na ja, da in der uC.net SD Lib (unter mmc.h) auch unter > anderem der ATMega8 aufgeführt ist, denke ich mal schon, > dass der Ram ausreichend dafür ist, Wenn du auf Schmerzen stehst, dann ja.
S. R. schrieb: > Oder formatiere die Karte einfach im Gerät, wie es jeder dämliche > Fotoapparat auch tut. Der formatiert die Karte aber spezifikationskonform. Sonst dürfte er das SD-Card-Logo nicht tragen.
> Der formatiert die Karte aber spezifikationskonform.
Noch viel schlimmer. Meine K1 weigert sich sogar mit anderswo
formatierten Karten mit FAT32 zu arbeiten wenn die groesser wie 32GB
sind. Das ist schon eine ziemliche bevormundung. Schliesslich sind
SDkarten auch nichts anderes wie Festplatten mit denen man das gleiche
machen kann. Also beliebig partionieren und formatieren.
Olaf
S. R. schrieb: > Warum nicht? Schreibe "SD-Karten bis 64 GB" in die Anleitung und dein > kommerzielles Problem ist gelöst. SDHC geht aber bis 32GB; SDXC (32GB-2TB) nutzt exFAT. Olaf schrieb: > Noch viel schlimmer. Meine K1 weigert sich sogar mit anderswo > formatierten Karten mit FAT32 zu arbeiten wenn die groesser wie 32GB > sind. Ja, weil die SD-Spezifikation hier exFAT vorsieht. Olaf schrieb: > Schliesslich sind > SDkarten auch nichts anderes wie Festplatten mit denen man das gleiche > machen kann. Also beliebig partionieren und formatieren. SD-Karten haben Flash-Speicher und keine Magnetscheiben; die Pages von Flash-Speicher sind nur begrenzt oft beschreibbar, weshalb SD-Karten Wear-Leveling einsetzen. Je nach Implementation nutzt das Wear-Leveling die Informationen des Dateisystems um leere Blöcke zu finden, was nur funktioniert, wenn das Dateisystem dem spezifizierten entspricht - und die Spezifikation schreibt nunmal bei SDXC exFAT vor (und zwar immer nur genau 1 Partition). Natürlich kommen bestimmte Modelle mancher Hersteller auch mit anderen Dateisystemen klar - aber das ist Betrieb außerhalb der Spezifikation, und zur Sicherheit verweigert das Gerät diesen.
Olaf schrieb: > Das ist schon eine ziemliche bevormundung. Schliesslich sind SDkarten > auch nichts anderes wie Festplatten mit denen man das gleiche machen > kann. Nein, das sind sie nicht. Sie sind klar spezifiziert, und zur Spezifikation gehört auch das verwendete Dateisystem und die Art der Partitionierung. Das dient unter anderem auch der Vereinfachung der Implementierung von Geräten, die mit SD-Karten arbeiten sollen, weil sie sich z.B. nicht um Partitionstabellen, erweiterte Partitionen etc. kümmern müssen, und auch nicht mit Sonderlocken wie unerwartete Clustergrößen oder -Anzahlen zu tun haben müssen. Es ist eindeutig: Bis einschließlich 2 GByte - SD(SC) FAT16. Bis einschließlich 2 GByte - SDHC FAT32. Größer als 32 GByte - SDXC/SDUC exFAT. Gefallen muss einem das nicht, aber es ist so spezifiziert.
Rufus Τ. F. schrieb: > Der formatiert die Karte aber spezifikationskonform. Sonst dürfte er das > SD-Card-Logo nicht tragen. Im KLeingedruckten des Geräts steht dann oft SD bis .. GB. Wenn die größeren sich trotzdem durch formatieren mißbrauchen lassen, ist es Kundenrisiko.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.