Blockwechsel beim lesen von SD/MMC, Zeitdauer?

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;)

Nachtrag: uC war ein Atmega32 mit 16MHz Takt und 8MHz SPI.
Sonst kann man ja keinen Vergleich zu anderen CPUs machen;)

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 ARM LPC2138 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 :)