Hallo Bisher habe ich ausschließlich die allseits bekannten W25Qxx SPI NOR Flash verwendet. Früher nutzte ich SPIFFS, aber mittlerweile greife ich nur noch auf LittleFS zurück. Diese Kombination ist eigentlich ziemlich praktisch, jedoch sind diese SPI NOR-Chips in Bezug auf Größe und Geschwindigkeit eher begrenzt. Es gibt einige ziemlich vielversprechende NAND-Bausteine wie den GD5F1GQ4 mit 1Gbit, allerdings handelt es sich hierbei um NAND-Chips und nicht NOR. Kann ich weiterhin SPIFFS/LittleFS verwenden oder benötige ich dafür eine andere Bibliothek?
Wie beschränkt? Digikey hat ca. 20 verschiedene 1GBit NOR auf Lager, auch W25Q01J in SO-16 und DFN-8. Bevor ich mir NAND-Flash antue, mache ich lieber die Platine größer.
Zitat:
1 | Spiffs is inspired by YAFFS. However, YAFFS is designed for NAND flashes, and |
2 | for bigger targets with much more ram.... |
Also: https://yaffs.net/
Wie der Chip intern aufgebaut ist, ist doch egal. Such Dir einfach einen nach Größe und Geschwindigkeit aus. Z.B. im W25Q01NW-DTR Datenblatt steht überhaupt nicht drin, ob NAND oder NOR, es ist einfach ein "SERIAL FLASH MEMORY". https://www.mouser.de/datasheet/2/949/W25Q01NW_DTR_RevB_07122021-2584409.pdf Ebenso interessiert sich das FS auch nicht dafür.
Peter D. schrieb: > Ebenso interessiert sich das FS auch nicht dafür. Das sollte es aber! Edit: übrigens, das W25Q01 N läuft mit 1.8V. Und das in diesem 5V-Forum :)
:
Bearbeitet durch User
Peter D. schrieb: > Ebenso interessiert sich das FS auch nicht dafür. LOL Du hast keine Ahnung was NAND Flash bedeutet. Kleiner Tipp: Bei NAND bedeutet bereit das Lesen "wear". Pages müssen alle x-tausend Lesezyklen neu geschrieben werden. Und vorher dementsprechend der ganze Block gelöscht. Da sollte man und das FS wissen was man/es tut, sonst ist der Flash ganz schnell fertig.
Tom schrieb: > benötige ich dafür eine andere Bibliothek? Wer macht das Wearleveling und die Error-Correction? Peter D. schrieb: > im W25Q01NW-DTR Datenblatt steht überhaupt nicht drin, ob NAND oder NOR Es ist natürlich ein NOR. Dort in der Mitte finden sich die W25Qxx: https://www.macronix.com/zh-tw/products/Documents/Macronix%20NOR%20and%20NAND%20Flash%20Cross%20Reference%20Guide.pdf
:
Bearbeitet durch Moderator
Andreas M. schrieb: > LOL Du hast keine Ahnung was NAND Flash bedeutet. Kleiner Tipp: Bei NAND > bedeutet bereit das Lesen "wear". Pages müssen alle x-tausend Lesezyklen > neu geschrieben werden. Und vorher dementsprechend der ganze Block > gelöscht. Hast du irgendeine Referenz dazu? Zumindest das Löschen halte ich für Quatsch, da man das nur benötigt, wenn man ein Bit von 1 auf 0 ändern muss. Wenn sich der Inhalt aber nicht ändert sollte das überflüssig sein. Michael
Michael D. schrieb: > Andreas M. schrieb: >> Kleiner Tipp: Bei NAND bedeutet bereit das Lesen "wear". > Hast du irgendeine Referenz dazu? Wohlbekannter Effekt: https://www.google.com/search?q=nand+flash+read+disturbance - https://us.transcend-info.com/embedded/technology/read-disturbance Und dann gibt es noch die Program Interference und sonst noch alle möglichen Interference auf so eine NAND Flashzelle: - https://people.inf.ethz.ch/omutlu/pub/cai_iccd13_talk.pdf - https://nepp.nasa.gov/DocUploads/9CCA546D-E7E6-4D96-880459A831EEA852/07-100%20Sheldon_JPL%20Distrub%20Testing%20in%20Flash%20Mem.pdf?q=disturb-testing-in-flash-memories Wenn man diese Effekte kennt, macht man sein Update künftig auf mehrere SSD.
:
Bearbeitet durch Moderator
Andreas M. schrieb: > Bei NAND > bedeutet bereit das Lesen "wear". Pages müssen alle x-tausend Lesezyklen > neu geschrieben werden. Ich denke mal nicht, daß das generell so ist. Es sollte ja im Datenblatt des konkreten Chips drin stehen. Ich habe auch noch nie solche riesen Chips selber verbaut. Da nehme ich dann z.B. SD-Karten. Oft will man große Datenmengen ja auch schnell übertragen, z.B. auf einen PC.
Peter D. schrieb: > Andreas M. schrieb: >> Bei NAND bedeutet bereit das Lesen "wear". Pages müssen alle x-tausend >> Lesezyklen neu geschrieben werden. > Ich denke mal nicht, daß das generell so ist. Naja, alle kochen mit dem selben Wasser... > Es sollte ja im Datenblatt des konkreten Chips drin stehen. Der Entwickler, der die Technologie anwendet, muss die Technologie so anwenden, wie der Hersteller das in seinen AppNotes beschrieben hat. Und eben nicht nur so, wie es im detailierten Datenblatt einees Chips steht. Sowas wie "Wearleveling" steht ja auch nicht im Dtanblatt, es muss trotzdem beachtet werden: - https://www.micron.com/-/media/client/global/documents/products/technical-note/nand-flash/tn2961_wear_leveling_in_nand.pdf Das Problem betrifft grundsätzlich auch weniger die SLC mit ein paar MByte, die ein Entwickler auf seine Leiterplatte lötet, sondern vor allem die MLC, TLC oder gar 3D-Flashs, bei denen der "Speicher" einer Zelle grade noch auch ein paar Atomen besteht. Und da ist der Chip dann inzwischen im TB Bereich. Drum tauchen auch alle bekannten Flashhersteller bei den entsprechenden Internetsuchen zu Interference und Disturbance auf.
:
Bearbeitet durch Moderator
Michael D. schrieb: > Hast du irgendeine Referenz dazu? > > Zumindest das Löschen halte ich für Quatsch, da man das nur benötigt, > wenn man ein Bit von 1 auf 0 ändern muss. Wenn sich der Inhalt aber > nicht ändert sollte das überflüssig sein. Das Problem bei NAND ist, das bei jedem Leseprozess eine minimale Ladungsmenge aus der/den Zelle entnommen werden können. Das führt dazu, das in durch Lesen einer Page, die Bits in anderen Pages kippen können. D.h. wenn ich eine Page nur oft genug lese, dann entstehen in NAchbarpages des gleichen Blocks Bitfehler. Das ganze nennt sich "Read-Disturb Error". Spätestens wenn ein Bit innerhalb einer Page auf diese Weise umkippt, muss diese neu geschrieben werden, bevor noch mehr Bits kippen. (Das ist übrigens der Grund warum man bei NAND fast immer mit ECC arbeitet, damit man diese Situation erkennen und behandeln kann) Bevor ich eine Page jedoch neu schreiben kann, muss sie zunächst gelöscht werden (auf "1" stellen). Dummerweise können NANDs fast ausschließlich blockweise gelöscht werden was bedeutet das der Inhalt von noch viel mehr Pages gesichert werden müsste. Deswegen verwendet man beim Wear-Leveling von NAND flashes Reserveblöcken/Pages. Statt also die "zerschlissene" Page neu zu schreiben nimmt man eine Freie/Reserve Page (die früher gelöscht wurde) und schreibt den Inhalt da hinein und merkt sich wo die Daten jetzt stehen für die nächsten Zugriffe. Optimalerweise wartet man dann mit dem Löschen des Blocks mit der "zerschlissenen" Page bis dort noch mehr, möglichst alles Pages "zerschlissen" sind, bevor man den Block löscht. Das Löschen dauert leider vergleichsweise lange. Das ist der Grund warum SSDs physikalisch mehr Flash-Kapazität haben, als angegeben, die Schreibzugriffe gehen immer in Reserve Blöcke gehen. Man versucht das Löschen zu bündeln und im Hintergrund durchzuführen. Kombiinstrumente in PKWs verlagern den Löschzeitpunkt daher oftmals auf den Abschaltzeitpunkt, also dann wenn der Zündschlüssel gezogen wird und das Instrument hoffentlich nicht gleich weder gebraucht wird. Diese Funktionsweise ist übrigens auch der Grund warum MLC/QLC/TLC NAND weniger zuverlässig und weniger schreib-schnell als SLC NAND ist. Da müssen nämlich nicht nur High/Low Pegel sondern gar mehrere Spannungslevel unterschieden werden können. Man sollte im übrigen nicht auf die Idee kommen, dass man ja die Zelle, wo nach vielem Lesen eine "1" (wie bei gelöscht) statt der vorherigen "0" steht einfach ohne Löschen überschreiben kann um die "0" wiederherzustellen. Oberflächlich betrachtet mag das bei SLC noch funktionieren geht früher oder später fast immer in die Hose. Es können dabei die Merkwürdigsten Seiteneffekte auftreten. Weder bei NAND noch NOR sollten geschriebene Zellen ohne Löschen nochmal beschrieben werden. Schaut man sich die Datenblätter der Hersteller an, dann steht auch nirgends, das das geht. Wir durften selbst mal die leidliche Erfahrung mit einem Winbond NOR Flash (SPI) machen. Dort haben wir byteweise Daten abgelegt (eine Art Logger) In dem wir ein und die selbe Page (komplett) mehrfach beschrieben haben, immer ein Byte mehr mit Daten befüllt. Mit der alten Revision der Flashes hat das wunderbar funktioniert. Bei einer neuen Revision des Flashes führte das mehrfache Beschreiben der gleichen Bytes dazu, das an völlig anderer Stelle auf einmal Bits kippten. Es stellte sich heraus, das im neuen Chip die Flash-Zellen anderes angeordnet waren und es eine räumliche Nähe zwischen logisch weit entfernten Speicheraddressen gab. Das mehrfache Beschreiben ohne Löschen hat nun scheinbar zu einem Übersprechen zwischen den Zellen geführt. Bei vorherigem Löschen des Blocks trat das Problem nicht mehr auf. Das Fehlerbild nennt sich "Over-Programming-Error" Nicht zum Spaß steht in den Datenblättern von Winbond jetzt "In **some** cases, less than xyz bytes ( a partial page) can be programmed without having a effect..." Ich hoffe Micron reicht Dir als Referenz: https://media-www.micron.com/-/media/client/global/documents/products/technical-note/nand-flash/tn2917.pdf
Peter D. schrieb: > Ich denke mal nicht, daß das generell so ist. Es sollte ja im Datenblatt > des konkreten Chips drin stehen. Doch. Nennt man Physik. Und jeder der mit solchen Dingen regelmäßig arbeitet weis das. Spätestens nachdem Ihm der erste Kunde das nach kurzer Zeit defekte Produkt um die Ohren gehauen hat. Peter D. schrieb: > Ich habe auch noch nie solche riesen Chips selber verbaut. Da nehme ich > dann z.B. SD-Karten. Und jetzt rate mal warum eine SD-Karte einen Controller hat, und was dieser Controller tut. Kleiner Tipp: Wenn du Sektor 0 der SD-Karte beschreibst, dann wird in den seltensten Fällen auch der Physikalische Sektor "0" des Flashes der SD Karte beschrieben. Dir ist bestimmt auch schonmal aufgefallen das man nicht mit konstanter Geschwindigkeit auf eine SD-Karte schreiben, sonders, das es alle x MByte einen kurzen Schluckauf gibt.
Andreas M. schrieb: > Und jetzt rate mal warum eine SD-Karte einen Controller hat Eben, warum soll ich mich mit dem low-level Kram abgeben. Da muß man schon für eine große Bude arbeiten, die USB-Sticks, SD, SSD, Smartphones usw. anbietet. Für den gemeinen Geräteentwickler ist das uninteressant.
Peter D. schrieb: > Eben, warum soll ich mich mit dem low-level Kram abgeben. > Da muß man schon für eine große Bude arbeiten, die USB-Sticks, SD, SSD, > Smartphones usw. anbietet. > Für den gemeinen Geräteentwickler ist das uninteressant. Du solltest nicht von Dir auf andere schließen. Nur weil Du gerne in Deiner kleinen Welt bleibst heißt das nicht, dass diese Themen für andere nicht relevant wären. Und natürlich muss man dafür nicht in einer "großen Bude" arbeiten.
Andreas M. schrieb: > Nur weil Du gerne in > Deiner kleinen Welt bleibst Mit zunehmenden Alter begreift man, daß man nicht alles vom Urschleim an selber entwickeln kann, wenn das Projekt noch zu Lebzeiten fertig werden soll. Man muß Fremdleistungen in das Projekt mit einbinden, wo sinnvoll. Soweit ich mich erinnere, hatte die Speichermedienhersteller ganz zu Anfang Probleme mit der Implementierung des Wear-Leveling und die Medien versagten unerwartet schnell. Daneben ist es auch nicht popeleinfach, die Medien bei unerwartetem Spannungseinbruch in einen sauberen Zustand runter zu fahren. Es gibt daher spezielle Medien für den harten Industrieeinsatz, wo dicke Stützkondensatoren mit eingebaut werden. Der einzelne hat also gar nicht die Zeit, die ganzen Entwicklungsetappen nochmal zu durchlaufen, um sein Produkt zuverlässig zu machen. Man muß Black Boxes zukaufen und hoffen, daß deren Entwickler seine Hausaufgaben ordentlich gemacht hat.
Peter D. schrieb: > Daneben ist es auch nicht popeleinfach, die Medien bei unerwartetem > Spannungseinbruch in einen sauberen Zustand runter zu fahren. Es gibt > daher spezielle Medien für den harten Industrieeinsatz, wo dicke > Stützkondensatoren mit eingebaut werden Das ist eine Frage des richtigen Dateisystems und dazu passenden FTL Layers. Bei puren NANDs brauchts keine Kondensatoren. Das braucht man nur bei so integriertem Zeug wie SD-Karten, die ein Eigenleben haben. Peter D. schrieb: > Der einzelne hat also gar nicht die Zeit, die ganzen Entwicklungsetappen > nochmal zu durchlaufen, um sein Produkt zuverlässig zu machen. Natürlich. Deswegen werden in diesen Bereichen fast überall nur noch fertige eMMCs eingesetzt. (Auch in Smartphones). Die haben das Wear-Leveling eingebaut. Trotzdem sollte man hier das richtige Dateisystem verwenden, eins was der Controller in der eMMC versteht und das Wear-Leveling darauf ausrichten kann. Peter D. schrieb: > Man muß Black Boxes zukaufen und hoffen, daß deren Entwickler seine > Hausaufgaben ordentlich gemacht hat. Man sollte aber die Grundlagen können. Und wenn ich eine SD-Karte als Speichermedium einsetze, dann sollte ich zumindest Wissen, das man diese nicht mit NTFS, BTRFS oder ähnlichem formatieren sollte, weil der Controller in der SD-Karte diese Dateisystem nämlich nicht versteht und das Wear-Leveling dann nicht optimal funktioniert. Ich sollte auch wissen wozu der "Discard" Befehl da ist, wann ich den verwenden sollte und das sich der bei guten SD-Karten hinter "CMD38" versteckt. Und um das zu Verstehen sollte man wenigstens die Grundlagen kennen...
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.