mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Erfahrung Atmel AT25DFxx vs. Numonyx/ST M25Pxx


Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.