Hallo
ich wollte mal fragen, ob man irgendwie als Ottonormalverbraucher an
Flash-Speicher-Chips mit höherer Kapazität (z. B. 4-8 GBit) kommt? Also
so was, was auch in den USB-Sticks, Mp3-Playern, Handys, SSDs... - was
weiß ich wo noch überall :P - eingebaut ist.
Wenn man nach sowas sucht, finde ich immer nur News von 2004 usw. die
besagen, dass solche Chips vorgestellt wurden. 512 Mbit war das einzige,
wa ich noch gefunden hab...
Kann mir da einer weiterhelfen? Danke vielmals :]
Solche Flash Speicher sind wohl am billigsten und einfachsten zu
bekommen, wenn man einen USB Stick bzw. SSD kauft und den Flash
auslötet. Ich habe noch ein paar solche Flashspeicher hier, bis 4 GByte
pro Chip.
Hallo,
ich kann dir 2 Stück K9LBG08U1M schenken, die ich noch übrig habe.
Es sind 32GBit (4 GByte x 8 bit) 25ns NAND Flash von Samsung.
Gehäuse: TSOP48
MfG aus Westerwald
Ich habe meine 8 Gbit Micron über DigiKey gekauft... Die zwanzig
32 Gbit habe ich allerdings NUR über Micron direkt bekommen wofür
ich zudem noch ein NDA unterzeichnen mußte.
Mittlerweile weis ich aber, das ich die SDRAM/NAND bei der Memphis AG
in Deutschland wesentlich besser und einfacher bekommen kann..
Achja, die Memphis AG hat mir auch Sourcecode (8051 + ARM) zu Wear-
Leveling geliefert...
Grüße
Michelle
Ich bräuchte vier 29f64g08cfaba-wp NAND ICs von Micron.
Das Problem ist allerdings, dass ich sie via Memphis AG nur in
kompletten Reels zu 1000 Stück beziehen kann.
Hat irgendjemand zufällig solche NANDs über oder kann diese besorgen?
Gruß
Björn
A. K. schrieb:> Michelle Konzack schrieb:>>> Achja, die Memphis AG hat mir auch Sourcecode (8051 + ARM) zu Wear->> Leveling geliefert...>> Ohne NDA?
Wenn Du bei denen die Chips kaufst, bekommste automatisch die Sources
abhängig von Deinem Project. Sowas nennt sich Kundenservice.
Memphis WAR mal ein NUR Speicherriegel hersteller und hatte so
ziehlich alle Chiphersteller als Lieferanten und SEHR erfolgreich,
was zur folge hatte, das die Chiphersteller die Memphis AG nicht
dropen konnten, als die angefangen haben, als Speicher-Chip
Distributor zu agieren...
Sprich, der UMSATZ macht die Musik...
Achja, ich kannte die Firma Memphis AG nicht, bis ich eine E-Mail
und eine Anruf wegen eines Problems mit dem OMAP L-138 (TI-Forum)
bekommen hatte. Memphis hat mein Problem SEHR schnell gelößt gehabt.
Die Auswahl an RAM und FLASH Speichern ist einfach gewalltig.
Du schreibst denen eine Mail oder rufst sie an, stellst Dein Project
vor und bekommst entsprechend Chips presentiert. Dabei spiet es
keine Rolle, ob Du ein Hochleistungs Long-Term-Usage-Device baust
oder nur ein billiges Consumer Teil, was die 2 Jahre gesetzliche
Garantie aushalten muß... (kein Witz)
Grüße
Michelle
Björn schrieb:> Ich bräuchte vier 29f64g08cfaba-wp NAND ICs von Micron.> Das Problem ist allerdings, dass ich sie via Memphis AG nur in> kompletten Reels zu 1000 Stück beziehen kann.
Das ist quatsch...
Bei einem kompletten Reel bekommste höchsten DIE RICHTIGEN Preise
und Memphis verkauft auch einzeln als MUSTER, kann aber dann sein,
das dies um ein paar Ecken geschieht, wenn sie nichts auf Lager
haben....
> Hat irgendjemand zufällig solche NANDs über oder kann diese besorgen?
Also prinzipiel sollte ich sie besorgen KÖNNEN.
Habe mal eine Anfrage gemacht...
Grüße
Michelle
Digikey bietet 4GBit fuer runfd 20 Euro. Fuer mich ist nur das
Wearlevelling interessant. Mal ne Frage dazu: Wieviel RAM braucht man
dafuer? Mindest-RAM gleich der zu loeschenden Blockgroesse?
Der compilierte Code ist gut 8 kByte groß
und benötigt mindstens 15 kByte RAM.
Da normalerweise bei USB-Sticks 8051er verwendet werden, welche
normalerweise 32+32 kByte haben, ist die der Verbrauch akzeptabel.
Grüße
Michelle
Den Block im RAM zum löschen zwischenpuffern wäre ohnehin keine gute
Idee, weil Inhalt komplett weg wenn Strom weg.
Der Weg heisst umkopieren. Flashs werden nicht 1:1 adressiert. Neuer
Block ersetzt alten Block an gleicher logischer Disk-Adresse.
danke Michelle für den Tipp mit der Memphis-AG
Die werde ich mal anschreiben - mal schauen ob sie mir was geben
@Falk: Ne micro-sd Karte hatte ich auch schon überlegt, die ist aber
angeblich nicht robust genug, um längere Zeit bei nicht
erschütterungsfreier Umgebung zu überleben (sehr dünne Leiterbahnen mit
Bondingverbindungen auf die Kontakte gehen da anscheinend kaputt...)
@Dimi: Danke fürs Angebot, aber ich fürchte zwei sind zu wenig :)
@fse: verstehe ich nicht: Wind Deal Mall - wo gibts da Flash-Chips? :)
@Michelle
Ich habe bei Memphis angefragt, worauf es hieß, dass sie diese ICs nicht
auf Lager haben und ein komplettes Reel mit 1000 Stück ordern müssten.
Vielen Dank für die Anfrage, ich hoffe, dass das klappt!
Gruß
Björn
Luk4s K. schrieb:> Michelle Konzack schrieb:>> Anm.: Ich bin auf der Suche nach einem OSS Wear-Leveling code...>> JFFS2 kann in das mehr oder minder
Nunja, die Infos die ich fand sind schon urig alt... Die schreiben
immer noch von MByte Flash... und ich bin bereits bei 128 GByte...
Muß mal den den source genauer ansehen...
Dumm nur, das er auf Linux basierend ist.
Danke
Michelle
Wie ist denn eigentlich die gängige Herangehensweise bei soetwas? Ich
habe hier jetzt einen 16 GBit MLC Speicher im Auge.
Wenn ich diesen mit einem Microcontroller ansteuern will bzw. Daten
darauf schreiben will, brauche ich dann als weiteres Bauteil noch einen
speziellen Controller?
Wenn ja: was wären denn typische Controller?
Vielen Dank
Ja, das hattest du schon geschrieben. Es ist aber die gängige
Herangehensweise wenn man nicht zu jenen gehört, die USB Sticks oder
Flash_Filesysteme für embedded Linux Systeme implementieren..
Ok :) - dann ziehe ich meine Frage nach der gängisten Herangehensweise
zurück. Ich möchte wissen, wie man mit dem Flashspeicher kommuniziert :)
Mein Wissensstand ist, dass es z. B. von Freescale µCs gibt, die
integrierte NAND-Controller haben. Ich würde gerne aber einen ARM Cortex
M3 verwenden und der hat sowas ja denke ich nicht. Deshalb brauche ich
wohl einen "externen Controller", weil ich ja nicht alles selber auf dem
µC programmieren will.
Jetzt frage ich mich eben welchen Controller ich dafür nehmen sollte (er
soll auf jeden Fall Wear Levelling unterstützen).Ich kenne mich leider
überhaupt nicht aus, was es da so gibt, und auf was man achten muss.
Also bei NAND Flash haste ja Blöcke und Du kannst nicht wahhlos
irgendeinen NAND Flash an einen Controller hängen, denn die NAND-
Flash MUSS zum Controller passen.
Es gibt 16 Gbit NAND welche Blöcke von 2 Gbit und 4 Gbit haben,
sprich, die haben dann entweder 8 oder 4 CS Leitungen...
WennD ein Contriller nur Addressleitungen für 2 Gbit hat und nur
2 CS Leitungen, wirste die NAND niemals ansteuern können.
Wenn DU natürlich einen NAND-Flash Controller implementieren willst,
wofür ein 8051er mit 40-80MHZ perfect ist, dann kannste machen was Du
willst, nur mußt Du das Timing, Wear-Leveling und so ALLES selber
impementieren.
Das ist das, was die USB-Stick-Hersteller machen...
Einen 8051er mit 32 Addressleitungen (4 ports), 8 bit Datenbus (1 port)
und 8 CS Leitungen (1 port)...
Ich habe sowas mit einem DS80C410 von Dallas/Maxim mal im kleinen (4
Gbit, Micron NAND-FLash) ohne Wear-Leveling als NAS implementiert und
ist nicht ganz ohne.
Grüße
Michelle
achso, d.h. jeder Controller in USB-Sticks, Mp3-Playern, Handys,...ist
wiederum irgendein x-beliebiger Microcontroller mit jeweils vom
Hersteller entwickelter Software dafür?
Michelle Konzack schrieb:> Luk4s K. schrieb:>> Michelle Konzack schrieb:>>> Anm.: Ich bin auf der Suche nach einem OSS Wear-Leveling code...>>>> JFFS2 kann in das mehr oder minder>> Nunja, die Infos die ich fand sind schon urig alt... Die schreiben> immer noch von MByte Flash... und ich bin bereits bei 128 GByte...
Ne Bemerkung an der Stelle: Ab vielen Megabyte wird JFFS2 beim mounten
langsam, die Checks gehen linear mit der Speichergrösse. Besser performt
dann ubifs. Wie's da mit Sourcen unter non-Linux aussieht, ist mir aber
nicht bekannt, und ev. ist etwas Portierungsarbeit involviert.
@rene:
Ich kenne 14 asiatische Hersteller, aber die verkaufen NICHT
außerhalb Asiens und die Datenblätter sind ausschließlich auf
chinesisch, koreanisch oder tawanesisch.
Grüße
Michelle
rene p schrieb:> achso, d.h. jeder Controller in USB-Sticks, Mp3-Playern, Handys,...ist> wiederum irgendein x-beliebiger Microcontroller mit jeweils vom> Hersteller entwickelter Software dafür?
Ja, jede NAND Flash hat UNTERSCHIEDLICHE Timings und der
Microcontroller muß jedesmal die passenden Firmware für den
NAND-Spreicher bekommen.
Es sind Laut datenblätter 8 verschiedene Timing-Settings und dann die
unterschiedliche anzahl von Adressleitungen plus die unterschiedliche
anzahl von CS...
Informiere dich VORHER, bevor du sowas postest.
Achja, das SATA Protocoll zu implemmentieren ist 10 mal schwieriger als
PATA. Siehe T10 (ich bin auf deren Mailingliste und OS Implementer).
Grüße
Michelle
Michelle Konzack schrieb:> Informiere dich VORHER, bevor du sowas postest.
?
Worüber jetzt konkret? Ich hab natürlich über die Sache etwas gelesen,
aber konkrete Informationen bekommt man nur, wenn man konkret fragt.
Deine Antworten helfen mir leider nicht wirklich weiter, weil wir
irgendwie aneinander vorbeireden oder/und mein Wissensstand nicht
aussreicht.
Ich versuch es NOCH einmal:
Ich habe hier einen 16 GBit-NAND-Speicher von Micron. Ich möchte diesen
gerne VERWENDEN ohne dafür das Rad NEU zu erfinden.
Es gibt fertige, DISKRETE Controller und es gibt µC die eine
NAND-Controller-Einheit *"ONBOARD"* haben. Ich muss also keinen
Controller selber programmieren.
Meine Frage ist, ob jemand Erfahrung mit einem dieser beiden gerade von
mir beschriebenden Controllerarten (diskret, onboard) hat, oder ob alle
hier die mit NAND gearbeitet haben bisher immer selbst irgendeinen µC
als Controller programmiert haben.
Ich habe auch einen 4GBit NAND von Micron, und hatte mich damit
letztlich auch beschaeftigt.
1. Wenn wuerde ich so einen ATA nach NAND Converter nehmen, denn ATA
kann man gut implementieren (wie MMC nur mit 16Bit Breite). Dass man die
gut bekommt wage ich aber zu bezeifeln, da die Kombination externer
Controller + Microcontroller + NAND wahrscheinlich fuer die
Massenproduktion zu teuer ist. Daher wird es fuer dich auch schwer sein,
da was zu bekommen.
2. Die Controller mit NAND an Board sind die grossen Dinger von TI wie
OMAP etc. Da ist der Prozi selber schon mal eine Herausforderung und da
wuerde ich auf fertige Boards zurueckgreifen (Panda, Beagle, etc.)
3. Existierende Sourcen fuer deinen Controller portieren, ich denke da
konkret an YAFFS2. Aber die Sourcen sind kompliziert, das ist nicht mal
so eben gemacht.
Ich glaube nicht, dass du viel Unterstuetzung bei der Sache finden
wirst. Denn NAND ist in Einzelstuecken noch sauteuer, fuer das gleiche
Geld bekommt man 5 SD Karten oder 5 USB Stick mit jeweils der gleichen
Kapazitaet. Zudem gibts kaum offene Sourcen, die auf AVR, PIC32, ...
portiert sind. Einen Treiber fuer die NANDs von MC habe ich getestet und
erweitert, jedoch gibt da kein Wearleveling. Und ohne das kannst du die
Sache knicken. Punkt.
Daher ist im Moment die beste Wahl MMC, SD oder USB Stick.
rene p schrieb:> Ich habe hier einen 16 GBit-NAND-Speicher von Micron. Ich möchte diesen> gerne VERWENDEN ohne dafür das Rad NEU zu erfinden.
Du kannst NICHT jedes beliebige NAND an einen Microcontroller
anschließe auch wenn dieser ein NAND-Flash Interface hat...
Es gibt nicht allzuviele µC die 16 GBit schaffen. Selbst ARM9 können zu
95% nur 128-256 MByte (1-2 Gbit).
Was hast Du für einen COntroller?
Um 1 GByte (8 GBit) anzusteuern ist es selbst bei einem Marvel Kirkwood
oder Discovery zu ende welche Arm Cortex A9 sind. Der Marvel Armada
300 ist ebenfals ein ARM Cortex A9 kann aber 2 GByte (16 Gbit)...
> Es gibt fertige, DISKRETE Controller und es gibt µC die eine> NAND-Controller-Einheit *"ONBOARD"* haben. Ich muss also keinen> Controller selber programmieren.
Diskrete Controller gibt es NUR für PATA/IDE und SATA, bzw. CF.
Willst Du das PATA/SATA Protocoll selber implementieren?
> Meine Frage ist, ob jemand Erfahrung mit einem dieser beiden gerade von> mir beschriebenden Controllerarten (diskret, onboard) hat, oder ob alle> hier die mit NAND gearbeitet haben bisher immer selbst irgendeinen µC> als Controller programmiert haben.
Ich verwende den Armel AT91SAM9263 mit 512 MByte NAND passend genauso
wie die Marvel Kirkwood/Discovery/Armada aber jeder Microcontroller
bekommt ein passendes NAND Flash...
Sprich, die Microcontroller KÖNNEN 512MByte, 1GByte oder 2GByte direkt
ansteuern da benötige ich nichts zusätzliches.
Sag erst mal WELCHEN Mikrocontroller Du verwendest.
Grüße
Michelle
@Hans: danke für deine ernüchternden Worte :) - es scheint also wirklich
nicht so easy zu sein...hm
@Michelle: danke für die Infos bzgl. der Microcontroller. Ich wollte die
Auswahl von dem µC so wählen, dass es eben mit dem NAND-Speicher
funktioniert. Momentan habe ich also noch keinen. Ich habe auch keinen
Controller.
Ich entnehme deiner Aussage, dass es evtl. zweckmäßiger wäre, kleinere
Speichereinheiten zu verwenden. Hm..
Michelle Konzack schrieb:> Diskrete Controller gibt es NUR für PATA/IDE und SATA, bzw. CF.> Willst Du das PATA/SATA Protocoll selber implementieren?
Das verstehe ich nicht so genau. Brauch ich SATA um mit Flash zu
kommunizieren? Ich raff irgendwie überhaupt nichts mehr.
Alles was ich will ist mit einem (mehr oder minder) beliebigen µC Daten
ansammeln (über mehrere Jahre) und auf einem Flash-Speicher abspeichern
:) - insofern wäre sogar Wear Levelling nicht nötig, weil die alten
Daten nicht gelöscht werden, sondern nur neue dazu kommen (bzw.
ausgelesen wird)
>Das verstehe ich nicht so genau. Brauch ich SATA um mit Flash zu>kommunizieren? Ich raff irgendwie überhaupt nichts mehr.
Es wird dem Controller vorgegaukelt, es waere eine Festplatte mit SATA
oder PATA angeschlossen. PATA laesst sich auf einem uC gut realisieren,
dazu gibts auch Beispiele.
>Alles was ich will ist mit einem (mehr oder minder) beliebigen µC Daten>ansammeln (über mehrere Jahre) und auf einem Flash-Speicher abspeichern>:)
Dann mach dir das Leben leicht und nimm ne MicroSD Karte. Den NAND
kannst du erstmal in der ESD Tuete lassen.
>insofern wäre sogar Wear Levelling nicht nötig, weil die alten>Daten nicht gelöscht werden, sondern nur neue dazu kommen (bzw.>ausgelesen wird)
Das mag sein, aber trotzdem musst du noch von den 2kB Sektoren auf die
512Byte Sektoren mappen.
Hans W. schrieb:> Es wird dem Controller vorgegaukelt, es waere eine Festplatte mit SATA> oder PATA angeschlossen. PATA laesst sich auf einem uC gut realisieren,> dazu gibts auch Beispiele.
Wer genau gaukelt was vor?
Der µC gaukelt dem Controller vor, dass er (der µC) eine SATA-Platte ist
und der Controller schaufelt dann Daten vom Flash-Speicher auf die
"SATA"-Platte?
Hans W. schrieb:> Dann mach dir das Leben leicht und nimm ne MicroSD Karte. Den NAND> kannst du erstmal in der ESD Tuete lassen.
Würd ich echt gern, aber mir wurde gesagt, des geht nicht, weil die
Karten kaputt gehen, wenn Erschütterungen auftreten (und die sind zu
erwarten)
rene p schrieb:> Würd ich echt gern, aber mir wurde gesagt, des geht nicht, weil die> Karten kaputt gehen, wenn Erschütterungen auftreten (und die sind zu> erwarten)
Erschütternd, dann kannst du sie wohl nicht einsetzen. ;-)
MfG Klaus
>Würd ich echt gern, aber mir wurde gesagt, des geht nicht, weil die>Karten kaputt gehen, wenn Erschütterungen auftreten (und die sind zu>erwarten)
Wer sagt das?
HTC verwendet in seinen Windowphone 7 Geräten auch eine Micro SD Karte
als Speicher, und ein Handy ist ja offensichtlich auch Erschütterungen
ausgesetzt. Also die Aussage, dass das mit SD Karten nicht geht halte
ich für Unfug.
Zumal du ja mit dem NAND keine wirkliche Alternative hast mangels
brauchbarer Ansteuerung...
Hans W. schrieb:> Also die Aussage, dass das mit SD Karten nicht geht halte> ich für Unfug.
SD-Karte: Drahtbonden zwischen Flash und Kontakte - viele, viele
hochfrequente Erschütterungen über die Jahre (ähnlich Ultraschall):
Bonding geht ab. Kontakt weg. Daten weg. Schelcht bzw. zu unsicher.
rene p schrieb:> SD-Karte: Drahtbonden zwischen Flash und Kontakte - viele, viele> hochfrequente Erschütterungen über die Jahre (ähnlich Ultraschall):> Bonding geht ab.
Das wäre ein Umfeld, in dem dann annähernd alle anderen Halbleiter auch
versagen - denn die sind weitestgehend auch mit Drähten gebondet. Nur
bei recht hochpoligen oder stark miniaturisierten Bauteilen wird mit
"flip-chip" direkt mit einem Substrat kontaktiert, aber ob die weniger
empfindlich gegen Erschütterungen sind, die einen Bonddraht zerlegen?
Was bitte soll denn das für ein Umfeld sein, in dem derartige
Bedingungen herrschen?
naja ok - war vielleicht etwas übertrieben :]
Ao schlimm wirds hoffentlich nicht sein. Aber mir wurde halt gesagt,
dass SD-Karten nicht gehen. Aber vielleicht sollte ich da nochmal
ansetzen..
Wenn Du statt SD-Karten Micro-SD-Karten verwendest, dann kannst Du als
Argument anführen, daß die Dinger komplett vergossen sind.
Es gibt Micro-SD-Sockel mit Klappbügel, die lassen sich notfalls mit
einem Lötzinnklecks zulöten, so daß auch bei heftigen Erschütterungen
die Micro-SD-Karte nicht herausfallen kann.
rene p schrieb:> SD-Karte: Drahtbonden zwischen Flash und Kontakte - viele, viele> hochfrequente Erschütterungen über die Jahre (ähnlich Ultraschall):> Bonding geht ab. Kontakt weg. Daten weg. Schelcht bzw. zu unsicher.
Dann solltest du alle elektronischen Bauteile, die mit Draht gebondet
sind. vermeiden. Machs wie die alten Egypter, meissel deine Daten in
Stein. das hält leicht 4000 Jahre.
MfG Klaus
Klaus schrieb:> Dann solltest du alle elektronischen Bauteile, die mit Draht gebondet> sind. vermeiden. Machs wie die alten Egypter, meissel deine Daten in> Stein. das hält leicht 4000 Jahre.
In unserem Klima nicht unbedingt. Wüste ist da praktischer. Und
Ultraschall ist sehr ungut.
Ich hab passend hierzu noch eine weitere Frage (weil des mit den
Steintafeln klappt nicht, ich hab zuviel Ultraschall rumliegen...:P):
Kann mir einer erklären, was denn ein serieller Flash-Speicher ist (z.B.
A25L032)?
Ist das ein NAND-Speicher-Chip, der den Controller integeriert hat und
bei dem die Ansteuerung über SPI oder I2C erfolgt?
Zumindest schaut das für mich so aus. Nur dann frag ich mich, warum es
den nur in so kleinen Größen gibt?
Und dann habe ich wiederum die Vermutung, dass meine Vermutung, was ein
serieller Flash-Speicher ist (siehe oben), falsch ist :)
Danke euch!! :]
> Ist das ein NAND-Speicher-Chip, der den Controller integeriert hat und> bei dem die Ansteuerung über SPI oder I2C erfolgt?
Ja, so sieht es zumindest aus
> Zumindest schaut das für mich so aus. Nur dann frag ich mich, warum es> den nur in so kleinen Größen gibt?
dafür gibs SD Karten etc
microSD und A25L032 sind warscheinlich mechanisch gleich stabil.
Ich würde SD nehmen und versuchen die Erschütterungen zu Dämpfen. z.B.
Ultraschall aus der luft mit Schallschutz. Ultraschall aus
Trägermaterial mit weichen Füllstoffen dazwischen usw. eventuell sogar
luftgelagert. oder mit Gummibänder in einer Kugel gehaltert.
Uwe schrieb:>> Ist das ein NAND-Speicher-Chip, der den Controller integeriert hat und>> bei dem die Ansteuerung über SPI oder I2C erfolgt?> Ja, so sieht es zumindest aus
Eher unwahrscheinlich, ist vermutlich SPI-angesteuerter NOR-Speicher.
Datenblatt sollte Gewissheit bringen.
Ich schrieb:> Datenblatt sollte Gewissheit bringen.http://www.amictechnology.com/pdf/A25L032.pdf
Tut es leider nicht - zumindest für mich nicht :).
Ich finde dort weder eine Aussage zu NOR noch zu NAND - aber die kleinen
Speichergrößen könnten ein Hinweis auf NOR sein.
rene p schrieb:> Steintafeln klappt nicht, ich hab zuviel Ultraschall rumliegen
Das sollte ein Scherz sein :] - Ultraschall gibt es in der Anwendung
hier gar nicht :)
Seufz, was mach ich jetzt? Ich würd ja echt gern SD-Karten nehmen...
Gibts irgendwo eine wissenschaftliche Arbeit über die Haltbarkeit von
SD-Karten?
Das ist so doof, weil die Firmen ja alle ihr Wissen für sich behalten :)
- bzw. irgendwie auch verständlich. Aber für mich isses halt doof, weil
ich hier neu an der Uni bin, und ein Projektpartner der festen
Überzeugung ist, das SD-Karten nix taugen - und das ist halt ein "alter
Hase" - insofern is meine Ansicht dazu nichts wert, solang ich sie nicht
irgendwie belegen kann :]
Also mal ehrlich...
Du baust da was 'industrielles', wenn Du so mit Vibrationen und so
weiter zu tun hast. Also geht es um Machbarkeit und Haltbarkeit, was
letztendlich immer ein Kompromiss ist.
MicroSD Karten sind absolut robust, musst ja nicht eine 32GB No-Name
Karte kaufen, sondern was namhaftes.
Was machbar ist:
Für MicroSD gibt es dutzende Libraries, die sie auf einem
Microcontroller ansprechbar machen. Der berühmteste Kandidat ist
ChanFAT. Du kannst dazu den simplen SPI Bus verwenden, andere Controller
(CortexM3 STM32F10x/20x) haben ein MMC/SD Card Interface und fertige
Beispiele.
Haltbarkeit:
Du traust einer SD-Card nicht, also nimm zwei oder drei. Du kannst die
SD-Cards alternierend beschreiben und im Falle eines Überlaufs am Ende
kannst Du Deinen Daten einen Timestamp verpassen. Dann suchst Du beim
Auslesen, nach dem ältesten Datum und liest (mit Überlauf am Ende) bis
zum jüngsten Datum.
Was die gängigen CortexM3 leider nicht können ist eine ECC, Du könntest
aber in der Software zu jedem Sektor-Paar einen weiteren Sektor mit XOR
bilden und diesen auf einer dritten Karte speichern. Kann eine der
Karten nicht gelesen werden, kannst Du die fehlenden Daten zurück
rechnen.
Das mit dem Stromausfall lasse ich nicht gelten. Man kann einfach ein
wenig mehr uF im Netzteil vorsehen und eine Spannungsübeerwachung per
Interrupt vorsehen. Dann ist Zeit genug angefangene Sektoren aus dem RAM
auf die SD-Cards zu verteilen.
Lediglich bei den SD-Card Sockeln muss man auf gute Qualität achten.
Aber ATA ist immer noch nicht Tot und es gibt industrielle CF-Cards. Ein
ATA Interface ist schnell zusammen geschrieben und gibt es bstimmt auch
schon open Source. CF-Cards gibt es, ebenso wie deren Sockel/Steckplätze
in ausgezeichneter Qualität, da sie in vielen industriellen Steuerungen
und Industrie-PCs vorkommen.
Auch hier kannst Du entweder Deine Sektoren selbst mit Daten füllen,
oder eben ChanFAT benutzen um ein Dateisystem zu haben, damit Du die
Karte einfach an den PC stecken kannst.
Ich weiß, Du hast da ein paar Chips, aber damit wirst Du nicht
glücklich.
Ich wollte auch meinen Server einen internal USB-Stick bauen. Die
Controller dafür (USB->SLC/MLC) könnte ich auch als Muster kostenfrei
bekommen, aber deren 8051er ist eben leer und man darf sich plötzlich
mit wear-leveling und Unterschieden zwischen SLC und MLC herum schlagen.
Es besteht aber noch eine gute Chance, dass Du Deine Chips noch brauchen
kannst, Du müsstest Dich nnur durch einen passenden Linux Treiber
Quelltext wühlen.
Gruß, Ulrich
Ulrich P. schrieb:> Was die gängigen CortexM3 leider nicht können ist eine ECC
Dass sie das nicht in Hardware gegossen haben bedeutet doch nicht, dass
es nicht ginge. Ist halt langsamer als in Hardware.
Abgesehen davon: Arbeiten SD Cards nicht sowieso intern mit ECC, so dass
man sich auf höherer Ebene schon deshalb auf grössere Ausfallsituationen
vorbereiten sollte? Wie eben dieses XOR.
Natürlich haben die SDs intern eine Sicherung, aber das nützt ja nichts,
wenn die Daten nicht verloren gehen dürfen. Ist die interne ECC
ungültig, bekommt man eben nur Schrott. Ob das an einem Schreibabbruch
liegt wegen Spannungsausfall oder Absturz oder Kontaktproblemen.
Daher entweder RAID-1, also einfach zwei SD-Cards und spiegeln, oder 3
SD-Cards mit RAID-5:
Sektor 1 im RAM puffern,
Sektor 2 im RAM puffern,
Sektor 3 als XOR von Sektor 1 und Sektor 2 errechnen
Sektor 1 -> SD-Card-0, Sektor 2 -> SD-Card-1, Sektor 3 -> SD-Card-2
Das kann man natürlich optimieren, während man Sektor 1 und Sektor 2 per
DMA auf die Karten schiebt, kann man parallel die XOR ausrechnen und den
3. Transfer per DMA anwerfen. Kommt auf die Chips an, ob sie mehrere DMA
auf mehrer oder das gleiche SD-Card Interface erlauben.
Wobei man bei Flash mit RAID verfahrentechnisch etwas anders umgehen
kann als als bei Festplatten. Während man bei Platten danach trachten
sollte, read-modify-write Vorgänge aufgrund der hohen Zugriffszeit zu
vermeiden, ist das bei den sehr schnell lesenden Flashes weniger
problematisch. Grössere Pufferungen, um Lesevorgänge zu vermeiden, sind
folglich nicht annähernd so lohnend.
Junge Junge,
erst kommt er mit GBit NAND, jetzt 32MBit. Was willst du eigentich
aufnehmen? Sind das paar DAten oder Gigabytes ?
Ich empfehle dir dir: Lass es! Du hast einfach eine Ahnung. Die beste
dir hier schon mehrfach vorgeschlagene Lösung ist die microSD in einem
guten Sockel. Wenn es nur paar Bytes sind dann nimm diese Atmel Chips,
zB AT45DB161D. Da kannst du im Notfall auf das Wear Levelling verzichten
und direkt FAT drauftüddeln.
Es kamen hier schon viele gute Vorschläge und du sagt immer nur : "Nein
das geht nicht weil bla." Ich verstehe nicht warum du nicht die Ideen
umsetzt da du keine bruachbare Alternative hast, die dich nicht maßlos
überfordert.
Und die von dir gekaufen NAND Chip die kannst du bei deinem aktuellen
Wissensstand getrost vergessen...
Gruß
Stefan
A. K. schrieb:> Grössere Pufferungen, um Lesevorgänge zu vermeiden, sind> folglich nicht annähernd so lohnend.
Also bei einem Daten-Logger muss man vermutlich eher weniger als 512
Bytes / 1 Sektor schreiben. Also müsste man lesen, anfügen, zurück
schreiben.
Dafür braucht es einen Puffer von der größe eines Sektors.
Dann kann man auch gleich den Sektor als Puffer anmelden, 512 Bytes
darin puffern und dann schreiben.
Voraussetzung ist ein zuverlässiges Power-Management, damit man
rechtzeitig noch den angefangenen Sektor sichern kann, bevor der Saft
weg ist.
