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.
Noch einfacher ist die direkte Verwendung einer Micro SD-Card.
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
Michelle Konzack schrieb: > Achja, die Memphis AG hat mir auch Sourcecode (8051 + ARM) zu Wear- > Leveling geliefert... Ohne NDA?
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
Anm.: Ich bin auf der Suche nach einem OSS Wear-Leveling code... Grüße Michelle
Ok, das heisst du brauchst nur 15kB RAM obwohl die Minstestgroesse zum loeschen eines Blockes mehr als 15kB sind ?
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 Konzack schrieb: > Anm.: Ich bin auf der Suche nach einem OSS Wear-Leveling code... JFFS2 kann in das mehr oder minder
@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
Nein. Wie schon erwähnt: die kommt aufgrund von mechanischer Instabilität nicht in Frage. Das hat mir auch besagte Memphis AG bestätigt.
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
Hi Michelle hm - wenn ich die Wahl habe, würde ich auf das selbst programmieren hier gerne verzichten :) Wo finde ich den fertige Controller? :)
Fertige Controller gibt es nicht, währe aber ein interessantes Open Hardware Project wenn sich ein paar Leute finden würden. 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?
oder hier: http://www.alibaba.com/product-gs/253477775/TDK_GBDriver_RS1_SATA_COMPATABLE_NAND.html Es gibt schon controller die man einfach so kaufen kann. Es gibt also schon fertige Controller - vielleicht liegt hier ein Missverständnis vor..
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
...und ich denke nicht, das der OP einen IDE-Controller haben wollte!
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.