Erfahrung Atmel AT25DFxx vs. Numonyx/ST M25Pxx

OP (Firma: Schweigstill IT) Persönliche Seite #1571129
Hallo,

gibt es hier Entwickler, die schon Erfahrungen mit dem Einsatz der
Flash-Bausteine Atmel AT25DFxx (speziell: AT25DF161) und Numonyx bzw.
ST M25Pxx (speziell: M25P16) haben?

Die Bausteine von Atmel sind ja im 150mil-SOIC-Gehäuse nur mit sehr
langen Lieferzeiten in Serienstückzahlen erhältlich, wobei sich das
bei Numonyx noch in Grenzen hält.

Die Bausteine scheinen ja auch einigermaßen kompatibel zueinander zu
sein. Gibt es hier jemanden, der schon bei einem der genannten Bausteine
einen so massiven Bug gefunden hat, dass er nicht oder nur mit
erheblichen Umwegen nutzbar ist?

Gibt es Erfahrungen in Verbindung mit einem Flash-Dateisystem, vorzugs-
weise mit Wear Leveling?

Mit freundlichen Grüßen
Andreas Schweigstill
Gast
>Gibt es Erfahrungen in Verbindung mit einem Flash-Dateisystem, vorzugs-
>weise mit Wear Leveling?

Die Chips haben sowas nicht. Das gibt es bei SD/MMC/SDHC/CompactFlash,
aber nicht bei controllerlosen schnöden Flash Chips.
OP (Firma: Schweigstill IT) Persönliche Seite
Hallo!

holger schrieb:
>>Gibt es Erfahrungen in Verbindung mit einem Flash-Dateisystem, vorzugs-
>>weise mit Wear Leveling?
>
> Die Chips haben sowas nicht. Das gibt es bei SD/MMC/SDHC/CompactFlash,
> aber nicht bei controllerlosen schnöden Flash Chips.

Ich habe nicht geschrieben, dass die Bausteine so etwas enthielten.
Dennoch ist es möglich, das Wear Leveling im Rahmen des Flash-
Dateisystems zu realisieren, wie z.B. bei JFFS(2). Bei den genannten
SD/MMC/SDHC/CompactFlash muss der Speicherbaustein/-controller
bestimmte Annahmen über die Struktur des Dateisystems machen. Das
funktioniert aber nur zuverlässig bei Standard-Dateisystemen wie z.B.
FAT, obwohl FAT normalerweise die größte Katastrophe hinsichtlich der
Abnutzung darstellen würde. Alternativ muss für jeden Block/Sektor
(/sonstige Organisationeinheit) ein Abnutzungszähler verwendet werden,
was wiederum Speicherplatz kostet.

Atmel hat ja bei den Dataflashes der AT45-Familie die Möglichkeit
vorgesehen, "krumme" Blockgrößen von z.B. 512+16 Byte zu verwenden,
um Verwaltungsinformationen in den Zusatzbytes zu speichern. Leider
gibt es aber kaum ein Dateisystem, das dies zum Zwecke des Wear
Levelings zu nutzen weiß. Und unter Linux war es ein jahrelanger
Kampf, bis JFFS2 endlich mit den krummen Sektorgrößen zurechtkam.
Einige AT45-Bausteine konnte man notfalls auch in den 2^n-Modus
schalten, was aber Speicherplatz verschwendet hat.

Gruß
Andreas Schweigstill

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 16 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.