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;)
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 :)
Bitte 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.