Forum: Mikrocontroller und Digitale Elektronik Low Level SD Card Access


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

meine Frage wäre, wie man direkt die Bytes von einer SD-Karte über SPI 
liest oder schreibt.
Komplett ohne Filesystem oder Partitionen möchte ich einfach nur 
einzelne Bytes einlesen und vllt. manipulieren.
Gibt es da irgendeine Liste mit Commands, welche Befehle die SDCard 
entgegennimmt?
Ich brauche eben eigentlich nicht die ganzen Features, die die ganzen 
Libs wie http://elm-chan.org/fsw/ff/00index_e.html bieten.
Und ich will mir nicht den gesamten Speicher damit zubauen.

Danke!

von KI-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was musstest du googlen dafür? Nur interessehalber, was ich falsch 
gemacht habe.
Ich habe nämlich ~30Min. mit googlen verbracht. Ich kam immer nur auf 
irgendwelche Libs, meistens sogar dann noch Arduino-Libs.
Danke.

von J. S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich habe gerade „sd card commands“ gegoogelt und im ersten Ergebnis 
auf Seite 21 steht genau wie’s geht. Was hast du denn gegoogelt?

von Dr. Sommer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wobei es natürlich schlauer ist, die aktuelle Spezifikation direkt von 
der Quelle zu laden und nicht von irgendwem der das mal auf seinem 
Webserver vergammeln lässt:
https://www.sdcard.org/downloads/pls/index.html
Außerdem steht in Part 2 (der ist leider nicht öffentlich zugänglich), 
dass du FAT16 (SDSC), FAT32 (SDHC) bzw. exFAT (SDXC) in einer bestimmten 
Speicher-Anordnung verwenden musst. Tust du das nicht, ist das Betrieb 
außerhalb der Spezifikation. Das kann funktionieren, muss aber nicht, 
und ggf. reduziert sich die Performance oder Lebensdauer der Karte. 
Genaues kann dir der Hersteller verraten, wenn du dich auf einen 
Hersteller einschränken möchtest.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Ich brauche eben eigentlich nicht die ganzen Features, die die ganzen
> Libs wie http://elm-chan.org/fsw/ff/00index_e.html bieten.

Grade bei Chan Fatfs sind die eigentlich Zugriffsfunktionen (disk_*) 
doch schön im extra File angesiedelt.

Für Windows Nutzer würde ich aber den "Aufriss" für FAT wärmstens 
empfehlen, denn es macht das Handling sehr viel einfacher. Windows will 
ansonsten immer die Karte formatieren und/oder Fehler korrigieren.

von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Wobei es natürlich schlauer ist, die aktuelle Spezifikation direkt
> von
> der Quelle zu laden und nicht von irgendwem der das mal auf seinem
> Webserver vergammeln lässt:
> https://www.sdcard.org/downloads/pls/index.html
> Außerdem steht in Part 2 (der ist leider nicht öffentlich zugänglich),
> dass du FAT16 (SDSC), FAT32 (SDHC) bzw. exFAT (SDXC) in einer bestimmten
> Speicher-Anordnung verwenden musst. Tust du das nicht, ist das Betrieb
> außerhalb der Spezifikation. Das kann funktionieren, muss aber nicht,
> und ggf. reduziert sich die Performance oder Lebensdauer der Karte.
> Genaues kann dir der Hersteller verraten, wenn du dich auf einen
> Hersteller einschränken möchtest.

Woher bekommt man denn den Part 2?
Weshalb muss man denn genau diese Formatiertung verwenden? Das ist doch 
eigentlich vollkommen egal, oder nicht? Auf der SDCard sind ja 
eigentlich nur die Speicherzellen + der Controller, der aber immer genau 
die Zellen anspricht, auf die man den ansetzt.
Deshalb verstehe ich auch nicht, inwiefern bitte ein fehlendes 
Filesystem die Lebensdauer reduzieren kann. Performance kann gut sein, 
aber Lebensdauer?
Das ist wohl nur der Fall, wenn man halt die ersten paar Sektoren immer 
nur beschreibt und die sich dann quasi abnutzen, wie das bei 
Flash-Speicher nun einmal der Fall ist.

Jim M. schrieb:
> Mylie schrieb:
>> Ich brauche eben eigentlich nicht die ganzen Features, die die ganzen
>> Libs wie http://elm-chan.org/fsw/ff/00index_e.html bieten.
>
> Grade bei Chan Fatfs sind die eigentlich Zugriffsfunktionen (disk_*)
> doch schön im extra File angesiedelt.
>
> Für Windows Nutzer würde ich aber den "Aufriss" für FAT wärmstens
> empfehlen, denn es macht das Handling sehr viel einfacher. Windows will
> ansonsten immer die Karte formatieren und/oder Fehler korrigieren.

Es geht nur darum, dass eine kleine Melodie raw auf der SDCard 
abgespeichert wird. Diese wird dann einfach nur vom µC ausgelesen und 
abgespielt.
Windows ist da vollkommen uninteressant. Sollte ich die Melodie jemals 
verändern wollen, werde ich sowieso Linux verwenden.
Aber ich werde sonst einfach einmal testweise die Lib ausprobieren. Wo 
finde ich denn die unterstützten Geräte? Da konnte ich auf die Schnelle 
nichts finden.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Woher bekommt man denn den Part 2?

sdcard.org , kostet aber Geld. Oder Google. Es steht aber praktisch nur 
die FAT Spezifikation drin.

Mylie schrieb:
> Auf der SDCard sind ja eigentlich nur die Speicherzellen + der
> Controller, der aber immer genau die Zellen anspricht, auf die man den
> ansetzt.

Keineswegs! Der Controller führt komplizierte Algorithmen fürs Wear 
Leveling aus. Aus der FAT sieht er, welche Blöcke  gelegt sind und 
welche wieder  verwendet werden können. Es gibt keine 1:1 Zuordnung 
zwischen der außen sichtbaren Sektor Nummer und der tatsächlichen 
Position im Speicher. Das kommt alles durcheinander wenn man kein FAT 
nutzt.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Wo
> finde ich denn die unterstützten Geräte?

Google. Gibt sehr viele - weil man mehr oder weniger nur korrektes SPI 
dranklöppeln muss, ist das oft bei den Beispielcodes der Hersteller 
schon dabei. In der ffsample.zip sind schon etliche verschieden µC Typen 
drin.

von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn das so ist, dann kommt man tatsächlich nicht wirklich um FAT herum.
Aber man kann doch auch SDCards mit z.B. ext4 formattieren (das habe ich 
auch schon gemacht) und theoretisch wohl auch mit jedem anderen 
Filesystem.
Oder sind die Controller nur dazu kompatibel?

Wenn es aber tatsächlich FAT sein muss, werde ich wohl doch nicht um 
solch eine Lib herumkommen.
Oder wie groß ist in etwa der Aufwand, das FAT-Filesystem zu 
implementieren? Hat das schon einmal jemand gemacht?
Oder sieht jemand sogar noch eine ganz andere Möglichkeit?

von Peter M. (r2d3)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Dr. Sommer,

Dr. Sommer schrieb:
> Keineswegs! Der Controller führt komplizierte Algorithmen fürs Wear
> Leveling aus. Aus der FAT sieht er, welche Blöcke  gelegt sind und
> welche wieder  verwendet werden können. Es gibt keine 1:1 Zuordnung
> zwischen der außen sichtbaren Sektor Nummer und der tatsächlichen
> Position im Speicher. Das kommt alles durcheinander wenn man kein FAT
> nutzt.

Bitte mal eine Quelle für das unterstellte Controller-Verhalten nennen!

Bei SSDs gibt es den TRIM-Befehl um dem Controller unbenützte Blöcke 
mitzuteilen.
Wenn Speicherplatzcontroller selbstständig Partitionen analysieren 
würden, bräuchte es keinen expliziten TRIM-Befehl mehr.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Aber man kann doch auch SDCards mit z.B. ext4 formattieren

Kann man, das ist dann halt nicht spezifkationskonform.

von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Mylie schrieb:
>> Aber man kann doch auch SDCards mit z.B. ext4 formattieren
>
> Kann man, das ist dann halt nicht spezifkationskonform.

Die SDCard in meinem Handy ist mit EXT4 formatiert und funktioniert 
einwandfrei. Das war notwendig, da es einmal Probleme mit der Erkennung 
mit FAT32-Formattierung gab.
Aber nett zu wissen, dass das eigentlich nicht spezifiziert ist.

Weiß denn noch jemand eine Antwort auf die Frage, welche µC von FatFS 
unterstützt werden?
Oder würdet ihr mir eher eine andere Lib empfehlen?

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Aber man kann doch auch SDCards mit z.B. ext4 formattieren (das habe ich
> auch schon gemacht) und theoretisch wohl auch mit jedem anderen
> Filesystem.
Ja. Kann funktionieren oder auch nicht.

Mylie schrieb:
> Oder wie groß ist in etwa der Aufwand, das FAT-Filesystem zu
> implementieren?
Ca 6 Monate (Fulltime).

Peter M. schrieb:
> Bitte mal eine Quelle für das unterstellte Controller-Verhalten nennen!
SD Specifications, Part 2, File System Specification

Peter M. schrieb:
> Bei SSDs gibt es den TRIM-Befehl um dem Controller unbenützte Blöcke
> mitzuteilen.
Bei SSD's ja. Bei SD-Karten nicht. SD-Karten-Controller erhalten die 
Information über nicht benutzte Blöcke aus der FAT.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Weiß denn noch jemand eine Antwort auf die Frage, welche µC von FatFS
> unterstützt werden?

Alle. Die benutzt nur Standard-C. Du musst nur den Low-Level-Zugriff auf 
die SPI/SD-Bus Schnittstelle einbauen. Da gibt es Beispiele u.a. für AVR 
und STM32.

Mylie schrieb:
> Oder würdet ihr mir eher eine andere Lib empfehlen?
Elm Chan's FatFs ist der de-facto Standard. Da macht man nicht viel 
falsch.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> SD-Karten-Controller erhalten die
> Information über nicht benutzte Blöcke aus der FAT.

Das hieße, dass sie mit etwas anderem als FAT nicht funktionieren würde 
- was nachweislich nicht stimmt. Threads dazu gab es hier im Forum schon 
mehrere, und auch Messdaten.

Es kann sein, dass manche Controller tatsächlich so arbeiten (und das 
wäre ebenfalls standardkonform), praktisch läuft es aber eher auf das 
hinaus, was eine SSD ohne TRIM macht.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Das hieße, dass sie mit etwas anderem als FAT nicht funktionieren würde

Das heißt nur, dass sie mit etwas anderem nicht funktionieren muss.

S. R. schrieb:
> praktisch läuft es aber eher auf das
> hinaus, was eine SSD ohne TRIM macht.
Ja, wahrscheinlich implementieren die meisten Karten einen 
Fallback-Modus, der wie bereits erwähnt, vermutlich eine geringere 
Performance & Lebensdauer aufweist. Ob man sich darauf verlassen möchte 
ist dann die nächste Frage.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
>>> SD-Karten-Controller erhalten die
>>> Information über nicht benutzte Blöcke aus der FAT.
>> Das hieße, dass sie mit etwas anderem als FAT nicht funktionieren würde
> Das heißt nur, dass sie mit etwas anderem nicht funktionieren muss.

Wenn die Controllerfirmware tatsächlich die FAT parst, um die freien 
Blöcke zu finden, dann funktioniert sie mit einem anderen Dateisystem 
schlicht garnicht. Von so einem Verhalten habe ich noch nie gehört.

Man kann auf SD-Karten relativ problemlos auch ext4, f2fs oder irgendwas 
anderes benutzen, aber mit manchen Karten kann man damit auch gewaltig 
auf die Schnauze fallen. Überhaupt betrachtet man SD-Karten besser nicht 
als zuverlässige Speicher, dann fährt man relativ gut.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Wenn die Controllerfirmware tatsächlich die FAT parst, um die freien
> Blöcke zu finden, dann funktioniert sie mit einem anderen Dateisystem
> schlicht garnicht.
Es sei denn die Karte erkennt anhand des MBR, dass es sich nicht um ein 
FAT handelt, und geht dann in einen "dummen" Fall-Back Modus.

S. R. schrieb:
> Von so einem Verhalten habe ich noch nie gehört.
Na dann muss es natürlich falsch sein.

S. R. schrieb:
> aber mit manchen Karten kann man damit auch gewaltig
> auf die Schnauze fallen.
Und wie kann das sein, wenn die Karte nicht die Eigenschaften von FAT 
nutzt?

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Wenn die Controllerfirmware tatsächlich die FAT parst, um die freien
> Blöcke zu finden, dann funktioniert sie mit einem anderen Dateisystem
> schlicht garnicht. Von so einem Verhalten habe ich noch nie gehört.

Macht sie auch nicht. Es gibt zum Sektor Löschen extra SD Befehle. Umd 
man erinnere sich an die ganzen Tools die gelöschte Fotos 
wiederherstellen können. Das geht nur weil die Datencluster gar nicht 
angefasst werden beim Löschen.

Wichtiger ist das die Verwaltung im Datesystem auf ganze 1MB/4MB Blöcke 
ausgerichtet ist, was mit FAT und dem SD Formatter Tool am Einfachsten 
geht.

von Norbert T. (atos)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die „SD Specifications Part 2 File System Specification Version 
2.00 May 9, 2006”: nirgendwo wird in diesem Dokument auf wear leveling 
eingegangen, es lässt sich daraus jedoch entnehmen, dass das File System 
völlig unabhängig vom Controller ist, d. h. die Karte kann man mit jedem 
beibiegen File System formatieren und benutzen, dies wird dann jedoch 
der Spezifikation nicht entsprechen und alle Mitglieder, die der SD Org 
angehören sind ja verpflichtet, die Hardware und Software so 
vorzubereiten, dass alle Karten mit der entsprechenden 
Software-Hardware-Kombination funktionieren.  Ein vernünftig 
implementiertes Filesystem wir die Lebensdauer der Karte nicht 
verkürzen.

> Aus der FAT sieht er, welche Blöcke  gelegt sind und welche wieder  verwendet 
werden können.

Das steht so nirgendswo in der Spezifikation. In Part 2 wird lediglich 
auf FAT12/16/32 eingegangen in Bezug auf die verschiedenen 
Kartenkapazitäten sowie auf die Unterschiede zu FAT von Microsoft, mehr 
nicht. CHS Parameter, Cluster-Größe usw. sind nicht festgeschrieben, es 
gibt dafür aber Empfehlungen. Im Anhang ein Screenshot, Seite 53 von 
Part 2: die Unterschiede zu MS FAT.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da ein Wear Leveling Pflicht für einen Flash-Speicher ist, SD-Karten 
Flash-Speicher verwenden und keinen TRIM-Befehl kennen, müssen die 
Controller die Information über nicht benutzte Sektoren aus der FAT 
auslesen. Das steht nicht in der Spezifikation, weil es 
implementationsspezifisch ist. Eine Karte welche kein Wear Leveling 
macht, braucht keine FAT - lebt dafür aber nicht lange. Die 
Erase-Befehle helfen hier auch nicht besonders, denn diese garantieren 
dass ein Block danach gelöscht ist, d.h. es muss tatsächlich eine 
Erase-Operation stattfinden, was langsam ist, sodass es sehr ineffizient 
wäre wenn der Dateisystemtreiber das immer nach dem Löschen einer Datei 
täte. Dass man Fotos wiederherstellen kann spricht auch dagegen dass 
alles erased wird. Daher bleibt nur die FAT als Information übrig.

von Peter M. (r2d3)


Bewertung
1 lesenswert
nicht lesenswert
Hallo Dr. Sommer,

Dr. Sommer schrieb:
> Da ein Wear Leveling Pflicht für einen Flash-Speicher ist, SD-Karten
> Flash-Speicher verwenden und keinen TRIM-Befehl kennen, müssen die
> Controller die Information über nicht benutzte Sektoren aus der FAT
> auslesen.

Nein. Es geht auch ohne eigenmächtige Deutung der Dateisystemstrukturen.

Die Karte braucht nur eine ausreichende Anzahl von Reservesektoren, auch 
wenn damit nicht die Lebensdauer eines Speichermediums erreicht wird, 
das den TRIM-Befehl unterstützt.
Insbesondere wenn die Karte niemals vollgeschrieben wurde, hat der 
Controller noch die Möglichkeit, verschlissene Sektoren gegen bisher 
noch nicht benutzte zu tauschen und damit einen Ausfall hinauszuzögern.

Das Thema wurde schon einmal hier im Forum besprochen. Das Fazit war, 
dass der Controller nicht selber anfängt, das Dateisystem zu deuten und 
dann eigenmächtig Inhalte zu überschreiben.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter M. schrieb:
> Das Fazit war, dass der Controller nicht selber anfängt, das Dateisystem
> zu deuten und dann eigenmächtig Inhalte zu überschreiben.

Ok. Warum sind dann Schreibzugriffe auf die FAT dann deutlich langsamer 
als solche auf Dateiinhalte?

Peter M. schrieb:
> Die Karte braucht nur eine ausreichende Anzahl von Reservesektoren,

D.h. wenn ich eine neue Karte einmal ganz vollschreibe, dann alle 
Dateien wieder lösche (der Controller aber nicht weiß dass die Daten 
hinfällig sind), dann eine kleine Datei anlege und immer wieder 
überschreibe,  erreiche ich schnell die maximale Lebensdauer dieses 
einen Blocks? Wenn der kaputt ist werden die Reserve Blöcke aufgebraucht 
und danach ist die Karte hinüber obwohl 99% des Speichers fast 
jungfräulich sind?

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
Natürlich stimmt es, dass die SD-Karten-Specs tatsächlich nur für FAT32 
und EXTFAT spezifiziert sind. Zumindest theoretisch muss die SD-Karte 
also nicht unbedingt mit anderen Filesystemtypen funktionieren.

Dass da allerdings die FAT-Sektoren ausgelesen werden, um freie Blöcke 
zu finden, glaube ich nicht.

Ich nehme an, dass die SD-Kartenhersteller für FAT-Sektoren (die ja bei 
jeder Dateioperation angefasst und im Vergleich zu anderen 
Datenbereichen unverhältnismässig hoch "belastet" werden) eine 
"Sonderbehandlung" bezüglich des Wear-Levelings zukommen lässt. Dazu 
hätten sie natürlich gerne, dass die FAT nach Möglichkeit an 
Flash-Sektorgrenzen beginnt und endet, damit nicht mehr Flash-Sektoren 
als unbedingt notwendig geschrieben werden müssen und verlangen deshalb 
eine "besondere" Formatierung.

Ext[234] schreibt die Information, welche Blöcke frei/belegt sind 
irgendwo auf das Medium, das bedeutet aber auch, dass diese Blöcke im 
Schnitt deutlich weniger belastet werden und die angesprochene 
Sonderbehandlung deutlich weniger nötig haben.

Beleg für diese Vermutung: die ExFAT-Spezifikation (zumindest, soweit 
sie bekannt ist). ExtFAT legt (wie ext[234]) für grosse Dateien eine 
Blockbitmap irgendwo auf dem Medium an und benutzt für solche Dateien 
die FAT nicht.

Das resultiert m.E. in einem zu ext[234] sehr vergleichbaren 
Schreib-/Leseverhalten - ich hätte deshalb keine Bedenken, zumindest 
SDXC-Medien mit ext[x] zu verwenden.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Die Festlegung auf ein spezifiziertes Dateisystem hängt wohl mehr damit 
zusammen, dass man eine Karte mit SD-Logo in ein Gerät mit 
SD-Karten-Slot (natürlich mit SD-Logo) stecken kann und es funktioniert 
einfach.
Was anderes als FATxx geht da nicht, sonst wäre die Mehrzahl der 
Windows-Nutzer außen vor.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Peter M. schrieb:
>> Das Fazit war, dass der Controller nicht selber anfängt, das Dateisystem
>> zu deuten und dann eigenmächtig Inhalte zu überschreiben.
>
> Ok. Warum sind dann Schreibzugriffe auf die FAT dann deutlich langsamer
> als solche auf Dateiinhalte?

Weil die Karte sinnvollerweise bei der FAT eine aufwändigere 
Blockersetzungsstrategie fährt. Die ändert sich ja öfters.

Dr. Sommer schrieb:
> dann eine kleine Datei anlege und immer wieder
> überschreibe,  erreiche ich schnell die maximale Lebensdauer dieses
> einen Blocks?

Nö. Die Karte ist schon intelligent genug andere Blöcke mit zu benutzen, 
auch wenn da Daten drauf sind.
Allerdings hatte ich ein paar extrem billige Karten hier wo das nicht 
geklappt/gereicht hat - die waren im Nu breit. YMMV.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Nö. Die Karte ist schon intelligent genug andere Blöcke mit zu benutzen,
> auch wenn da Daten drauf sind.

Mehrere Daten auf einem Block speichern? Wie geht das?

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@Mylie (Gast)

>Es geht nur darum, dass eine kleine Melodie raw auf der SDCard
>abgespeichert wird. Diese wird dann einfach nur vom µC ausgelesen und
>abgespielt.

Auch dazu nimmt man sinnvollerweise einen Standardlösung mit FAT. ISt 
auch weder schwer noch aufwändig.

>Wenn es aber tatsächlich FAT sein muss, werde ich wohl doch nicht um
>solch eine Lib herumkommen.

Sieht so aus.

>Oder wie groß ist in etwa der Aufwand, das FAT-Filesystem zu
>implementieren? Hat das schon einmal jemand gemacht?

Viele. Aber du mußt das Rad nicht neu erfinden, sondern vorhandene, gut 
getestete Libs einfach nutzen.

>Oder sieht jemand sogar noch eine ganz andere Möglichkeit?

Beitrag "Re: Arduino Nano, SD Card, PCM"

Alles ohne Tricks und doppelten Boden.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
>>Oder wie groß ist in etwa der Aufwand, das FAT-Filesystem zu
>>implementieren? Hat das schon einmal jemand gemacht?

Google: Chan FATFS. Hat vermutlich schon Beispielcode für Deinen 
Liebligs-µC dabei.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Google: Chan FATFS. Hat vermutlich schon Beispielcode für Deinen
> Liebligs-µC dabei.

Ich glaube das hat er schon gefunden (Ausgangspost lesen):

Mylie schrieb:
> Ich brauche eben eigentlich nicht die ganzen Features, die die ganzen
> Libs wie http://elm-chan.org/fsw/ff/00index_e.html bieten.

von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
>>Oder sieht jemand sogar noch eine ganz andere Möglichkeit?
>
> Beitrag "Re: Arduino Nano, SD Card, PCM"
>
> Alles ohne Tricks und doppelten Boden.

Möglichkeiten in C. Hätte ich vllt. noch dazu sagen sollen.
Und ich habe keine Lust, schon wieder eine ganze Arduino Lib 
umzuschreiben. Vor allem, weil da nicht immer qualitativ hochwertiger 
Code verwendet wird.

Jim M. schrieb:
> Falk B. schrieb:
>>>Oder wie groß ist in etwa der Aufwand, das FAT-Filesystem zu
>>>implementieren? Hat das schon einmal jemand gemacht?
>
> Google: Chan FATFS. Hat vermutlich schon Beispielcode für Deinen
> Liebligs-µC dabei.

Es gibt zwar entsprechenden Beispielcode, aber der muss dringend 
umgeschrieben werden. Der ist so für mich nicht benutzbar, da viel zu 
groß.
Außerdem habe ich bereits eine eigene schöne SPI-Implementierung, die 
ich verwenden möchte. Entsprechend schaue ich mir zwar die Grundlagen 
ab, aber muss letztendlich doch zumindest das Devicelayer noch einmal 
neu aufsetzen.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ Mylie (Gast)

>> Beitrag "Re: Arduino Nano, SD Card, PCM"
>
>> Alles ohne Tricks und doppelten Boden.

>Möglichkeiten in C.

Gibt es auch genug.

> Hätte ich vllt. noch dazu sagen sollen.
>Und ich habe keine Lust, schon wieder eine ganze Arduino Lib
>umzuschreiben.

Das ist keine Sekunde nötig.

> Vor allem, weil da nicht immer qualitativ hochwertiger
> Code verwendet wird.

Jaja, nur das Beste für den Herrn Maker. Mein Gott . . .

>> Google: Chan FATFS. Hat vermutlich schon Beispielcode für Deinen
>> Liebligs-µC dabei.

>Es gibt zwar entsprechenden Beispielcode, aber der muss dringend
>umgeschrieben werden. Der ist so für mich nicht benutzbar, da viel zu
>groß.

Jaja, du und deine Anforderungen. Komisch, daß der Rest der Welt damit 
klar kommt. Du weißt doch gar nicht, wieviel FATFS braucht.

>Außerdem habe ich bereits eine eigene schöne SPI-Implementierung, die
>ich verwenden möchte.

WOW! Eine eigene SPI-Ansteuerung! Na dann kann man ja UNMÖGLICH auf so 
Durchschnittskram zurückgreifen. Muss man alles umschreiben, oder noch 
besser, gleich komplett neu machen.

von Mylie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
>>Es gibt zwar entsprechenden Beispielcode, aber der muss dringend
>>umgeschrieben werden. Der ist so für mich nicht benutzbar, da viel zu
>>groß.
>
> Jaja, du und deine Anforderungen. Komisch, daß der Rest der Welt damit
> klar kommt. Du weißt doch gar nicht, wieviel FATFS braucht.

Ich brauche nur READONLY.
Und damit ist schlicht und ergreifend 80% des Beispielcodes überflüssig.

>>Außerdem habe ich bereits eine eigene schöne SPI-Implementierung, die
>>ich verwenden möchte.
>
> WOW! Eine eigene SPI-Ansteuerung! Na dann kann man ja UNMÖGLICH auf so
> Durchschnittskram zurückgreifen. Muss man alles umschreiben, oder noch
> besser, gleich komplett neu machen.

Es dab bei den Beispielen nebenbeibemerkt gar keine mitgelieferte SPI 
Implementierung.
Ich will lediglich alles so weit wie möglich reduzieren. Immerhin nimmt 
die Lib ohne irgendwelchen anderen Code im ReadOnly-Mode auch noch fast 
6KiB weg. Muss noch einmal schauen, wie ich das am Besten noch weiter 
reduzieren kann.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ Mylie (Gast)

>> Jaja, du und deine Anforderungen. Komisch, daß der Rest der Welt damit
>> klar kommt. Du weißt doch gar nicht, wieviel FATFS braucht.

>Ich brauche nur READONLY.
>Und damit ist schlicht und ergreifend 80% des Beispielcodes überflüssig.

Ja und? Da muss rein GAR NICHTS umgeschrieben werden sodnern nur read 
only KONFIGURIERT werden!

>Ich will lediglich alles so weit wie möglich reduzieren.

Fetisch?

> Immerhin nimmt
>die Lib ohne irgendwelchen anderen Code im ReadOnly-Mode auch noch fast
>6KiB weg.

Gibt es keine großen Controller mehr? Willst du 1 Million davon bauen?

> Muss noch einmal schauen, wie ich das am Besten noch weiter
> reduzieren kann.

Mit Lesen?

http://elm-chan.org/fsw/ff/00index_p.html

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
>> Wenn die Controllerfirmware tatsächlich die FAT parst, um die freien
>> Blöcke zu finden, dann funktioniert sie mit einem anderen Dateisystem
>> schlicht garnicht.
> Es sei denn die Karte erkennt anhand des MBR, dass es sich nicht um ein
> FAT handelt, und geht dann in einen "dummen" Fall-Back Modus.

Das halte ich schlicht für verdammt unwahrscheinlich, zudem wärs noch 
bescheuert. Eine SD-Karte funktioniert auch dann noch, wenn sie in einem 
Fotoapparat formatiert wurde, der sich einen Scheißdreck um die 
Ursprungsformatierung schert.

Dein Argument ist nicht unmöglich, aber es setzt wesentlich mehr 
Aufwand/Intelligenz in der Firmware voraus und widerspricht weitläufiger 
Erfahrung. Zudem hat Samsung mit f2fs gezielt ein Dateisystem mit 
ähnlichen Zugriffsmustern wie FAT, aber komplett anderen Datenstrukturen 
entworfen. Das werden die sicher nicht gemacht haben, wenn das nicht 
weitläufig funktionieren tät.

Davon abgesehen wäre so ein Verhalten, wenn real beobachtet, in gewissen 
Kreisen bekannt (die ganzen Embedded Boards laufen von SD mit ext4, 
Android nutzt sowas ebenfalls). Ist es aber nicht, von daher unterstelle 
ich dir einfach wilde Spekulation "könnte aber sein". Ja, könnte es, ist 
es aber mit an Sicherheit grenzender Wahrscheinlichkeit nicht.

So, und damit bin ich raus. :-)

von Peter M. (r2d3)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Peter M. schrieb:
>> Das Fazit war, dass der Controller nicht selber anfängt, das Dateisystem
>> zu deuten und dann eigenmächtig Inhalte zu überschreiben.
>
> Ok. Warum sind dann Schreibzugriffe auf die FAT dann deutlich langsamer
> als solche auf Dateiinhalte?

Wenn das so wäre, liegt es vielleicht daran, dass die Verschleissgrenze 
eines Blocks erreicht worden ist und die Information in einen anderen 
Block selten genutzten Block geschrieben werden muss, der aber schon 
belegt ist.

>
> Peter M. schrieb:
>> Die Karte braucht nur eine ausreichende Anzahl von Reservesektoren,
>
> D.h. wenn ich eine neue Karte einmal ganz vollschreibe, dann alle
> Dateien wieder lösche (der Controller aber nicht weiß dass die Daten
> hinfällig sind), dann eine kleine Datei anlege und immer wieder
> überschreibe,  erreiche ich schnell die maximale Lebensdauer dieses
> einen Blocks?

Ja.

> Wenn der kaputt ist werden die Reserve Blöcke aufgebraucht
> und danach ist die Karte hinüber obwohl 99% des Speichers fast
> jungfräulich sind?

Nein. Wenn alle Reserveblöcke aufgebraucht sind, ist die Karte nach 
meinem Verständnis noch lange nicht hinüber. Der Controller kann doch 
auch benutzte Blöcke tauschen um eine asymmetrische Schreibbelastung von 
Zellen, wie sie in der Natur von Dateisystemen liegt, zu verhindern.

Hier noch eine Quelle für SSDs, nicht SDs.
Die Ergebnisse sind wohl übertragbar:

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ssd-server-storage-applications-paper.pdf

Zitat aus Punkt 5.1:

[...The Intel SSD has a write-leveling mechanism that ensures that NAND 
wear is distributed evenly across the entire NAND capacity, even for 
workloads that have regions of high write activity mixed with regions of 
static data. As a result of write leveling, the difference between 
maximum and average program/erase cycles for different blocks of NAND is 
not significant for purposes of monitoring wear and estimating SSD 
lifetime...]

Wie sollte es auch anders sein.

: Bearbeitet durch User
von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Mylie schrieb:
> Ich will lediglich alles so weit wie möglich reduzieren. Immerhin nimmt
> die Lib ohne irgendwelchen anderen Code im ReadOnly-Mode auch noch fast
> 6KiB weg

Auf derselben Seite gibt es Petit fatfs 
(http://elm-chan.org/fsw/ff/00index_p.html) Damit habe ich mal einen 
(FAT32-fähigen) Bootloader gebaut der in eine 4K Page vom LPC176x passt.

Allerdings brauchte das ein paar Tricks, sonst ist bei Cortex-M3 schon 
die C-Lib (newlib bei GCC) zu groß (memcpy und co).

Bei AVRs sind 4K natürlich viel, aber das liegt vor allem daran das die 
Dinger technisch völlig veraltet sind.

Aber irgendwie scheint der OP keinen fremden Code lesen zu können, denn 
die ganzen Low-Level Funktionen zum Block lesen und Schreiben etc. 
werden einem ja wie auf dem Präsentierteller serviert.

Use the source, luke!

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> Bei AVRs sind 4K natürlich viel, aber das liegt vor allem daran
> das die Dinger technisch völlig veraltet sind.

Meinten Sie: "für einen anderen Markt entwickelt"?

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]
  • [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.