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!
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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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.
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.
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?
@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.
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.
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.
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.
@ 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.
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.
@ 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
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. :-)
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.
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!
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"?
