www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Blockwechsel beim lesen von SD/MMC, Zeitdauer?


Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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;)

Autor: holger (Gast)
Datum:

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

Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin wohl fündig geworden:
http://www.sandisk.com/Assets/File/OEM/Manuals/Pro...

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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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;)

Autor: Goa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.