Hi,
ich tue mich gerade schwer folgendes zu berechnen (habe bislang noch nie
etwas mit SD/MMC_Karten gemacht):
Mal angenommen ich möchte eine SD/MMC im MMC Mode am SPI meines µC
betreiben und organisiere meine Daten strikt in 512 Byte Blöcken (das
ist ja die Standard Blocksize einer Karte <= 2 GB, oder?).
Nun möchte ich der Karte per µC sagen "gib mir Block #1", die Karte
schickt mir den 512 Byte großen Block #1, danach möchte ich z.B. den
Block #300.
Die Zeit bis die Karte auf den 300sten Block umgeschwenkt hat, bevor sie
mir dessen 512 Byte schickt nennt man doch die Seek-Time, oder?
Falls ja: kann mir jemand aus Erfahrung sagen wie lange die Karte
Pi-mal-Daumen für so einen Blockwechsel (nur beim lesen) benötigen wird?
Denn ich finde hierzu im Netz völlig wiedersprüchliche Aussagen, wäre
daher sehr froh wenn mir jemand mit Erfahrung mit SD/MMC etwas dazu
schreiben könnte :)
Danke & Grüße
Goa
Hallo,
ich weiß es auch nicht genau.
Aber, da keine Leseköpfe oder andere Hardware bewegt werden muss, könnte
ich mir vorstellen, dass das immer ungefähr konstant ist.
Wo hast Du denn unterschiedliche Infos gesehen?
Grüße
Daniel
Konstant ist schon mal gut :)
Ich habe bei Google gesucht und in verschiedenen Foren Werte von 150 ms
bis unter 10 ms gefunden. Für meinen Zweck wären 150 ms jedenfalls viel
zu langsam, darum frag ich.
>könnte ich mir vorstellen, dass das immer ungefähr konstant ist.
Ist es aber nicht. Dann wären die Karten beim lesen
alle gleich schnell;)
Nach einem Blick in alte LOG Dateien lesen meine
Karten (32MB-16GB) eine 2MB Datei mit 180-500kB/s. Gut da ist noch FAT
mit im Spiel, aber die langsamste Karte mit 180kB/s war eine
2GB Karte und damit Mittelfeld. 2MB bedeutet 4000 Sektoren.
Bei 500kB/s sind das 4s für 4000 Sektoren. Das ist jetzt leicht
zu rechnen und gibt 1ms pro gelesenem Sektor. Bei 180kB/s sind das
11s und 2.75ms pro gelesenem Sektor. Die Wahrheit liegt wohl irgendwo
dazwischen;)
Danke Holger, allerdings meine ich nicht die Lesegeschwindigkeit,
sondern die Blockwechsel-Zeit, da ich ja Blockweise arbeiten möchte.
Und da müsste ich eben die Zeitspanne wissen, die die Karte braucht um
einen der 4000 Blöcke anzuwählen. In einem Datasheet einer CF Karte habe
ich eben etwas von 10 ns gelesen, dass deckt sich nun mit den 10 bis 150
ms in den Foren überhaupt nicht mehr lach.
PS: mein PIC-Controller hat 40 MIPS @ 160 MHz, der sollte also kein
Nadelöhr darstellen.
>allerdings meine ich nicht die Lesegeschwindigkeit,>sondern die Blockwechsel-Zeit, da ich ja Blockweise arbeiten möchte.
Beim lesen von 2MB Dateien fallen eine Menge Blockwechsel an;)
>PS: mein PIC-Controller hat 40 MIPS @ 160 MHz, der sollte also kein>Nadelöhr darstellen.
Hab jetzt grad noch mal bei meinen ARMLPC2138 Versuchen nachgesehen.
Maximum 640kB/s lesen bei CPU Takt 60MHz und SPI 20MHz. Also auch nicht
so viel schneller als der kleine ATMega.
>In einem Datasheet einer CF Karte habe>ich eben etwas von 10 ns gelesen, dass deckt sich nun mit den 10 bis 150>ms in den Foren überhaupt nicht mehr lach.
Das waren die Schreibzeiten. Allerdings hab ich statt 150ms schon mehr
als 270ms gemessen.
Ok, aber Du musst bei Dir ja sicher erst in der FAT Tabelle den nächsten
Block suchen. Bei meiner Anwendung ist der Block bekannt, da er ganz
einfach errechnet werden kann.
Das was ich suche, nennt sich wohl Address Setup Time, statt Seek-Time
(denn die schließt wohl den ganzen FAT Krempel mit ein).
>Ok, aber Du musst bei Dir ja sicher erst in der FAT Tabelle den nächsten>Block suchen. Bei meiner Anwendung ist der Block bekannt, da er ganz>einfach errechnet werden kann.
Sicher, aber auch nur alle Nase mal wenn eine neue Clusternummer
ansteht. Bei 4kB Clustern ist dann erst nach 8 Sektoren mal ein
neuer FAT Read notwendig. Und der FAT Sektor steht bei mir dann
schon im RAM. Bei FAT32 muss ich den auch nur alle 128 Cluster
mal neu lesen. Bringt also nicht viel Versatz.
>Das was ich suche, nennt sich wohl Address Setup Time, statt Seek-Time>(denn die schließt wohl den ganzen FAT Krempel mit ein).
ROFL;)
Wie schnell solls denn werden?
Also am liebsten hätte ich alle 40 ms 1024 Byte (die 1024 Byte setzen
sich aber immer aus 2 aufeinerfolgenden Blöcken zusammen, so dass nur 1
Seek à 1024 Byte nötig ist).
Beispiel:
1. Lese Block #1 und #2 à 512 Byte
2. Seek auf Block #301
3. Lese Block #301 und #301 à 512 Byte
Punkte 1 bis einschl. 2 sollten in 40 ms durch sein.
Die Frage ist jetzt ob das ohne großes Buffering überhaupt möglich ist.
Bzw. ob es selbt mit Buffern überhaupt möglich ist...
Bin wohl fündig geworden:
http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManRS-MMCv1.3.pdf
Da steht ist der Seite 2-2 eine Read Access Time von "Typical 0.5ms" und
"Max. 100ms" angegeben.
Die 0.5 ms klingen ja Traumhaft :-)
Aber warum ist die Bandbreite von 0.5 bis 100ms so groß?
Unter welchen Konditionen tritt dieser Worst-Case von 100ms ein?
Fragen über Fragen :-)
>Aber warum ist die Bandbreite von 0.5 bis 100ms so groß?>Unter welchen Konditionen tritt dieser Worst-Case von 100ms ein?
Wenn vorher ein Block geschrieben wurde könnte darauf noch
WearLevelling erfolgen. Also ein ersetzen des Blocks weil
er zu oft beschrieben wurde. Das beim reinen Lesen solche
Verzögerungen auftreten halte ich für unwahrscheinlich.
Aber bei diesen MMC/SD Mistdingern muss man mit allem rechnen;)
Ah okay! Na gut, dann scheint mein Vorhaben ja vermutlich doch zu
funktionieren freu :)
Werde in 2-3 Wochen hier dann mal berichten, ob es auch in der Praxis
funktioniert, sobald die Platine eintrudelt :)
