Hi,
ich bräuchte am PIC so ca. 10, optimal 16 Megabyte Speicher.
Den Einsatz von DRAMs scheue ich etwas, wegen der Refresh-Sache (hab
sowas noch nie praktisch gemacht), zudem brauche ich dort eine immense
Anzahl an Adressleitungen.
Deshalb frage ich mich gerade ob wohl der Einsatz von einer MMC/SD
Karte Sinn machen würde? Stimmt es das die Dinger bis zu 1 Mio
Schreibzyklen verkraften? Wie schnell kann ich die Daten dort
eigentlich seriell auslesen (ich bräuchte ca. 50 Kilobyte pro
Sekunde)?
Gruß
Matze
Wieso nicht? Einfacher und billiger geht es einfach nicht, als mit MMC.
Zudem sind die Dinger (richtig gehandhabt) extrem schnell. Mehr als
10MByte/s sind bei modernen Karten kein Problem.
16MB solltest du eigentlich umsonst bekommen, wenn man bedenkt, dass
128MB teilweise neu für 10,- EUR zu haben sind.
jörn
...belehrt mich eines besseren, aber die vorhandenen uC-Treiber samt uCs
für SD bzw. MMC Karten schaffen nichtmal 10 kByte/s. CF Karten die
parallel ausgelesen werden schaffen etwas mehr, aber auch sicher nicht
50 kB/s !
Vermutlich geht´s etwas schneller falls die Daten nicht in FAT32 etc.
gespeichert werden müssen...
Du kannst natürlich SD/MMC Karten verwenden und die Daten ganz einfach
auf z.B. 5 Karten aufteilen, aber ich denke das wäre zuviel des
guten...
Die Schreib/Lesezyklen hängen sehr vom Hersteller ab, aber 1 Mio dürfte
schon passen, wichtig ist, dass man imer nur ganze Blöcke schreibt - wie
z.B. bei exernen eproms.
Danke für eure Antworten.
Ein Dateisystem benötige ich nicht, es soll eh immer nur 1 (grosse)
Datei drauf.
Ich habs halt nur deswegen problematisch gesehen weil ich eben häufiger
Lösch- und Schreibzugriffe auf die Daten (immer komplett) haben werde,
aber pro Jahr max. 20.000, von daher sollte 1 Mio okay sein (ist eh nur
für mich selbst!).
Ich werde mir mal ein paar Quellcodes zum Thema reinziehen, da werde
ich ja sehen wieviel Speed drin sind :-)
Gruß
Matze
Was ist denn gegen statische RAMs einzuwenden, zur Not mit ´nem
Schieberegister für die Adressen, um Portpins zu sparen. Wenn´s nicht
so sehr auf Platz ankommt, dann halt ein paar ICs mehr nehmen.
Statische RAMs halten ewig (man kauft sie nur 1x) und sind sehr fix bei
der Sache.
Mit einem ATMega8 und 16MHz schaffe ich ohne Probleme 400-500KByte/s ~
4MBit/s mit einer SanDisk SD Karte. Die Aussage ist also schon richtig.
Das es Libraries gibt die nur 50Kb/s erreichen liegt wohl eher an den
Libraries.
Gruß Hagen
@Hagen: oha, 400-500 kB ist ja traumhaft :-) Also mir genügen 50 kB beim
Lesen schon völlig aus, beim Schreiben ist es sowieso egal.
@TravelRec: ja, das wäre sicherlich die eleganteste Lösung. Ich hab nur
Bammel vor dieser Refresh-Geschichte, weil ich damit bisher nie was
gemacht habe.
Am liebsten würde ich ja sowieso DRAMs nehmen, aber bei 10 MB wird das
dann nicht nur ein IC-Grab sondern auch viel zu teuer :-)
@MathiasM: Du hast TravelRec falsch verstanden. Statische RAMs
funktionieren ohne Refresh.
Allerdings werden AFAIK nach wie vor keine SRAMs mit mehr als 4 MBit
Kapazität hergestellt - für 10 MByte wären dann immerhin noch 20
(zwanzig!) Stück zu verbauen ...
Ich vermute, daß Du SRAM und DRAM verwechselst, denn anders kann ich
mir Deinen letzten Satz nicht erklären - DRAMs kosten signifikant
weniger als SRAMs.
Im Codesammlungs-Unterforum gibt es ein Beispiel von Benedikt, mit dem
normale DRAMs (dynamische RAMs) angesteuert werden - und der Refresh
auch erledigt wird.
Hi,
>Allerdings werden AFAIK nach wie vor keine SRAMs mit mehr als 4 MBit>Kapazität hergestellt - für 10 MByte wären dann immerhin noch 20>(zwanzig!) Stück zu verbauen ...
ISSI stellt auch 8Mbit Srams her.
Es waere moeglich einen CPLD als Memory Controller zumissbrauchen fuer
DRAMS.
Die Kostenguenstigste und nicht aufwendigste Moeglickeit waere es mit
SD Card.
Gruß,
Dirk
@Hagen :
...schaffst du 500 kByte/s mit Dateisystem oder ohne ?
Kurzzeitig oder auf Dauer ?
500 kByte/s mit uC und SD/MMC höre ich zum ersten Mal (glaub´s aber
gerne), wie pufferst du die Daten (ich gehe davon aus, dass du die
Daten blockweise in einem Rutsch überträgst)?
> CF Karten die parallel ausgelesen werden schaffen etwas mehr, aber> auch sicher nicht 50 kB/s !
Da geht definitiv mehr, betreibe an einem ATmega128 (8MHz) eine 64MB
CF-Karte. Mit meiner ersten grottenschlechten Software kam ich schon
auf knapp 100 kByte. Dateisystem ist übrigens FAT32.
@O.J.
Ohne FAT, SPI2X und maximaler Takt, gemessen wurde Lesezugriff
wiederholter 512 Bytes Blöcke. Also ohne irgendwelches weiteres
Prozessing und damit stösst man an die Leistungsgrenze des SPIs des
AVRs bei 16MHz Takt. Das was es später so langsam macht ist der FAT
Zugriff und eventuell weiteres Processing.
Die 400-500Kb sind also idealisiert der maximal mögliche Datendurchsatz
beim Lesen meiner SanDisk SD Billig-Karte. Mit einer NoName MMC Karte
erreichte ich sogar noch höhere Werte ~590KB/s.
Das einzigste was im AVR lief war das HW-SPI und ein Timer zum Messen
und nach der Messung (1 Minute) wurden die Werte übern UART
ausgegeben.
Gruß Hagen
Theoretisch wären auf einem AVR mit 16MHz ja 8MBit SPI möglich, ergo
ohne MMC/SD Karten Protokoll Overhead maximal 1Mb/sec.
Die 500Kb sind also schon recht langsam.
Gruß hagen
Relativ hohe Anzahl Rewrites ist ein Vorteil der SD-Karten (mglw. auch
bei anderen Bauformen). Es werden Reserve-Sektoren vorgehalten, die
aehnlich wie bei (halbwegs modernen) Festplatten bei Bedarf von der
Kartenelektronik "eingeblendet" werden. Atmel Dataflash und die
aehnlichen Produkte der Mitbewerber haben diese Funktion m.W. (noch)
nicht (laesst sich aber in Software nachbilden). Die Dataflashs
verfuegen allerdings ueber zwei RAM-Buffer, auf die man gezielt
verteilen kann (z.B. einen Puffer intern in das Flash-Array
uebertragen, der andere steht fuer neue Daten von der SPI-Schnittstelle
bereit).
Falls doch "echtes" FATxy-Dateisystem auf Speicherkarte: ein paar
"Software"-Puffer implementieren, sonst kommt des bei der
Clusterbelegung mglw. zu ungewollten Verzoegerungen.
Martin Thomas
Eine eigene Frage?
Dieser Thread ist über 21 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
