Flash-ROM am AVR-Bus?

Ja, sofern man die Timinganforderungen des konkreten Typs einhält, spricht nichts dagegen.

Ich kenne es von einem 1MBit-Winbond-Teil (W29EE011). Da brauchst du zwischen den einzelnen Bytes nicht zu warten, ja du darfst nichtmal allzu lange warten, sonst beginnt er schon ungewollt mit dem eigentlichen Flashen. Geschrieben wird in einen internen SRAM-Puffer mit der Page-Größe. Warten mußt du erst, wenn du den vollgeschrieben hast, denn dadurch stößt du den eigentliche Flash-Zyklus erst an. Und auf dessen Ende mußt du natürlich dann auch noch warten.

Noch viel billiger wäre möglicherweise der Ersatz des AVR gegen ein Modell mit größerem Flash, dann könnte das ganze externe Geraffel eventuell komplett eingespart werden. Der Flash der ATMegas läßt sich ja zur Laufzeit beschreiben. Ob das in Frage kommt, ist natürlich abhängig von der benötigten Speicherkapazität. Auch gewisse Softwarerestriktionen gilt es zu beachten, wenn der Mega während des Flashens noch irgendwas anderes tun muß.

Hallo Heiko!

Klar, das muss ich dann im Detail noch prüfen.

OK, dass macht die Sache noch deutlich einfacher.

Einen AVR mit 8Mbit internem Flash gibt es aber leider nicht.

Erstmal soll das ganze soweit wie möglich abwärtskompatibel sein, d.h. eine Firmware sollte möglichst beide Designs abdecken können. Damit kann ich den EOL des Designs noch ein bischen verschieben. Die nächste Generation wird dann Corex M3 basiert sein und einiges mehr können.

Gruß Thorsten

Interessantes Teil. Aber ein Standardfeature ist das nicht. Ich hatte bis jetzt WIMRE Spansion, Micron und Intel in den Händen, die brauchten zum Schreiben explizite Befehle. Als nichtflüchtiger Ersatz für einen langsamen RAM taugen die also nicht.

Stefan

Dir ist aber klar, daß man Flashs nicht einfach Byteweise beschreiben kann, sondern daß zum Schreiben eines Bytes mehrere Schreibzyklen auf das Flash nötig sind?

zumindest das wirst Du in der Software also anpassen müssen.

cu Michael

Das ist wohl sicher. Die Algorithmen zum Programmieren sind vielfältig.

Das allerdings ist Unsinn. Man muß einfach nur genau das tun, was die Teile jeweils brauchen. Es gibt ganze Datenblätter, die das beschreiben.

Fakt ist: Solange die Steuerung mit den drei Leitungen CS, OE und WE auskommt, geht es in praktisch jedem Fall. Und in den meisten anderen Fällen ist der einzige Hinderungsgrund die Notwendigkeit einer zusätzlichem Steuerungsleitung mit höherer Spannung.

Die wenigen Mißgebilde, die den oben formulierten Regeln widersprachen (also nicht JEDEC-kompatibel waren), sind zum Glück inzwischen schon längst wieder ausgestorben. Leider nicht mit ihnen auch alle Firmen, die so einen erbärmlichen Scheißdreck in Umlauf brachten...

Bis zu welcher Groesse gibt es die SPI-EEPROMs bzw. SPI-Flash? So kurz mal per Google geschaut finde ich das M25PE80-V von ST. Waere das eine Alternative?

Gerrit

Er wollte doch das Design möglichst wenig ändern. Wenn Speicher per SPI anbindbar wäre, würde sich die Frage nach ausreichender Kapazität kaum stellen, denn dann könnte er die schier unendliche Vielfalt spottbilliger SD-Karten als Speicher verwenden.

Wobei man mit SD-Karten auch ziemlich reinfallen kann. Ich hab bisher zwei Stück beerdigen dürfen. Gar nicht so oft benutzt. Die eine brachte auf einmal Lesefehler (immer derselbe Bereich) und die andere (eine SanDisk) war von jetzt auf nachher einfach weg. Ähnliches bei USB-Sticks.

Als Ersatz für ein batteriegepuffertes SRAM wäre mir das nicht zuverlässig genug.

Gerrit

Irgendeinen Fehler in deiner Programmierung? Ich habe auch noch einen kleinen Berg defekter SD-Karten. Die stammen aber noch aus der Anfangszeit meiner SD-Programmierung also noch einiges schief gelaufen ist.

Ich wuerde aber trotzdem lieber SPI-Flash als SD-Karte nehmen weil es billiger und einfacher sein duerfte weil man auf den Sockel verzichten kann.

Sehe ich das eigentlich richtig das ein SPI-Flash genau dasselbe ist wie das was man in einer SD-Karte hinter dem Controller finden wird?

Das kann man ja sowieso nicht vergleichen. Der OP will ja sicher auch sein Programm in diesem Flash ablaufen lassen oder auf Daten ueber ein normales Record zugreifen.

Olaf

Ich hab sie nur mit einem normalen Kartenleser benutzt um einmal die Woche ein Backup wichtiger Daten draufzuschreiben (Rotation ueber mehrere SD-Karten). Also eigentlich korrekte Anwendung. Die anderen verwendeten Karten (SanDisk) funktionieren bisher und haben jetzt deutlich mehr Zyklen als die ausgefallenen.

Da ist eher ein anderer Controller vorgeschaltet, einer mit SPI und ohne die Sonderfeatures des SD-Controllers ('secure'). Direkt mit dem NAND-Flash willst du nicht reden, die Kopfschmerzen sollen sich andere machen. :)

Dann muesste er eher in Richtung EEPROM oder NOR-Flash denken. Die billigen NAND-Flash aus SSDs, USB-Sticks und SD-Karten taugen dafuer nicht.

Gerrit

Am 06.03.2011 09:28, schrieb Olaf Kaluza:

Die setzen normalerweise NAND Flash ein, also sehr parallel:

Vermutlich um einfacher und schneller das Wear-Leveling zu implementieren. Und ich gehe mal davon aus, daß in modernen SD-Karten auch Fehlerkorrekturverfahren implementiert sind und automatisch defekte Blöcke in ungenutzte Bereiche umgeschrieben werden, transparent für das SPI-Protokoll.

SPI-Flashs sind dagegen recht simpel gehalten und werden wohl auch kein Wear-Leveling unterstützen. Wenn du da also 100.000 mal denselben Sektor beschreibst, dann geht der kaputt, oder vielleicht auch andere Speicherbereiche. OOB-Daten mit ECC-Checksumme usw. musst du auch alles selber implementieren. Ist dafür aber natürlich ziemlich preiswert mit einem halben Euro für 64 kByte:

Für Anwendungen ohne viel Schreibzugriffe durchaus sinnvoll. Die größeren Chips dieser Sorte werden vielfach bei FPGAs eingesetzt (sofern nicht per Microcontroller geladen).

Ja, bei SD muss man wohl auch noch eine Lizenz [1] bezahlen wenn man ein Geraet mit so einem Slot verkaufen will.

Eher nicht. Die gaengigen SPI-Flashes duerften NOR sein, neuere SD-Karten dagegen NAND.

Micha

Interessant, wusste ich noch garnicht. Was passiert wohl wenn man ein Geraet mit einem MMC-Slot verkauft der zufaellig so dick ist das der Anwender verbotenerweise auch SD-Karten da reinstecken kann?

Olaf

Dann spricht das Gerät mit der SD-Karte im MMC Modus.

Falk

Ich habe hier noch einige Dutzend M25P16 (auch von ST, jetzt wohl Numonyx) im SO16 rumfliegen, also 16MBit. Das sind bisher die größten, die ich in real existierenden Produkten (tm) gesehen habe.

Gruß,

Martin

Unterstuetzen SD-Karten das ueberhaupt? Ich kenne es eigentlich nur andersrum (MMC-Karte in SD-Slot).

Micha

Bei mir hat's immer gklappt.

Aber nach Nachlesen muß ich mich korrigieren: Es war jeweils der SPI-Modus:

Falk

Die Frage ist: unterstützt der Host das überhaupt? Eine SD-Karte stellt sich taub, wenn man sie wie eine MMC anquatscht. Jedenfalls im nicht-SPI-Modus.

Stefan

wir haben einige 100 M25P128 in einem Projekt 2009 (800 Ogg Vorbis-Spieler in Gruppen zu je 16 Stk von jeweils einem embedded Linux -System gesteuert...) verbaut. bisher keine Probleme, es wird allerdings fast nur gelesen.

Grüße

- Michael Wieser