Erfahrung Atmel AT25DFxx vs. Numonyx/ST M25Pxx

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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

[holger (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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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