Hi Zusammen
Ich will sequentiell in eine 2GB SD- Karte schreiben, jeweils drei
Blöcke a 512Bytes, alle 85ms. In der Karte werden nur Rohdaten von
Sensoren gespeichert, ohne ein Filesystem, und um das Wear Leveling
möglichst gut zu unterbinden werden die Blöcke gleichmässig auf die
Adressen verteilt. Soweit funktioniert auch alles wie es sollte.
Das Problem liegt bei einer Verzögerung, welche jeweils nach ca. 40'000
geschriebenen Blöcken auftritt. Die Verzögerung dauert dann meist über
100ms, weshalb es unmöglich ist, die nächsten Daten zu schreiben.
Während dieser Zeit ist die SD Karte im Busy Modus.
Ist es möglich, dass die Verzögerung auftritt aufgrund des Wear
Levelings? Und gäbe es Möglichkeiten, dieses zu unterbinden oder zu
verhindern? Ist es überhaupt realistisch, über längere Zeit mit dieser
Frequenz die SD Karte zu beschreiben, ohne unterbrochen zu werden?
Vielen Dank für Eure Hilfe
Grüsse
Moin,
du könntest eine andere SD-Karte probieren. Allerdings ist es wohl
trotzdem normal, ab und an solche Zeiten akzeptieren zu müssen.
Du brauchst auf einer SD-Karte kein eigenes Wear-Levelling durchführen,
der Controller tut dies selbst. Eventuell hast du zusätzlich in den
ersten 2M-8M ein anderes Verhalten der Karte, da dort üblicherweise bei
FAT-Systemen der FAT liegt (und hier u.U. optimierte Wear-Levelling
Strategien angewendet werden).
Kannst du irgendwie mehr Daten puffern? Die Wahrscheinlichkeit ist hoch,
dass der dem verzögerten folgende Datenzugriff wieder schneller geht -
also wenn du irgendwie einmal 512 Bytes zusätzlich puffern kannst,
kommst du wohl zurecht.
Grüße,
Matthias
Siehe Text vom Vorposter.
Du kannst alternativ versuchen in der Busy Phase den SPI clock (ich
nehme mal an das ist der Fall) zu erhöhen und damit die Phase zu
verkürzen.
Andere Karten habe ich bereits probiert, war auch mit einem Hersteller
in Kontakt, jedoch half dies wenig. Momentan verwende ich die S-300u von
SwissBit.
Das Wear Leveling führe ich nicht selbst durch und das Verhalten ist
leider auf der ganzen Karte genau gleich.
Was meinst Du genau mit den zusätzlichen Daten puffern? Die Blöcke
vergrössern? Oder mehr Blöcke auf einmal schreiben?
Die Daten werden im uC zwischengespeichert, mit einem Ringbuffer. Diesen
kann ich wegen dem relativ kleinen RAM nicht vergrössern.
Von 0.5 s Verzögerung im schlimmsten Fall ausgehend, wird man wohl einen
FIFO von knapp 10 kByte benötigen.
> Die Daten werden im uC zwischengespeichert, mit einem Ringbuffer. Diesen> kann ich wegen dem relativ kleinen RAM nicht vergrössern.
Tja, schlechte Karten.
Ansonsten eventuell etwas wie AT 45DB321D SO (32 Mbit SPI Data Flash,
2,50€ bei Reichelt)? Dort hast du garantierte Write-Zeiten und kannst
auch eine ganze Menge an 512 Byte Blöcken unterbringen (8192 um genau zu
sein). Zudem braucht es weniger Strom. Wenn du wirklich mehr Speicher
brauchst (wie lange soll geloggt werden?): Es gibt auch serielles SRAM:
Microchip 23A640. Das als Ramerweiterung für nen größeren
Zwischenspeicher/Ringpuffer nehmen. Alternativ eben nen größeren µC
einsetzen :)
@ Kendrick (Gast)
>Blöcke a 512Bytes, alle 85ms. In der Karte werden nur Rohdaten von>Sensoren gespeichert, ohne ein Filesystem,
Würde ich heute nicht mehr machen.
> und um das Wear Leveling>möglichst gut zu unterbinden werden die Blöcke gleichmässig auf die>Adressen verteilt.
Das kannst du so leicht nicht austricksen ;-)
>Das Problem liegt bei einer Verzögerung, welche jeweils nach ca. 40'000>geschriebenen Blöcken auftritt. Die Verzögerung dauert dann meist über>100ms, weshalb es unmöglich ist, die nächsten Daten zu schreiben.
Doch, nur halt später ;-)
>Während dieser Zeit ist die SD Karte im Busy Modus.
Sieht so aus.
>Ist es möglich, dass die Verzögerung auftritt aufgrund des Wear>Levelings?
Ja.
> Und gäbe es Möglichkeiten, dieses zu unterbinden oder zu>verhindern?
Glaub ich eher nicht, bzw. der Aufwand lohnt sich nicht.
> Ist es überhaupt realistisch, über längere Zeit mit dieser>Frequenz die SD Karte zu beschreiben, ohne unterbrochen zu werden?
Nur mit ausreichend großem FIFO.
512 Byte/85ms = 5,9 kB/s. Wenn man schlimmstenfalls mal 500ms als
Pufferzeit ansetzt, brauchst du halt ~ 3kB.
Nun vielen Dank für die vielen schnellen Antworten.
Ich sehe es gibt wohl nicht viele Alternativen als den uC zu ersetzten,
was ich eigentlich verhindern wollte.
Hast Du mal probiert, 16KB Blöcke auf einmal zu schreiben (Multi Block
Write)? Und nein, die muss man nicht auf einmal im RAM halten, wenn man
die Schreibfunktion etwas modifiziert.
Hintergrund ist, das die Sandisk SD 2GB hier dann scheinbar in einen
"schnelleren" Modus schalten. Die Blöcke müssen aber IIRC an den
physichen 16KB ausgerichtet sein.
Allerdings brauchen sie dann auch ~10 mA dauerhaft, was bei Versorgung
aus einer Batterie stören könnte.
