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!
https://www.cs.utexas.edu/~simon/395t/resources/Part_1_Physical_Layer_Simplified_Specification_Ver_3.01_Final_100518.pdf google geht grad wieder mal ;)
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.
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?
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.
Mylie schrieb: > Aber man kann doch auch SDCards mit z.B. ext4 formattieren Kann man, das ist dann halt nicht spezifkationskonform.
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.
Angehängte Dateien:
-
FAT.jpg
140 KB
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.
:
Bearbeitet durch User
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"?
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.