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 :)
der alte Hanns schrieb: > [...] > Tja, schlechte Karten. Nicht wirklich. Alle Karten zeigen mehr oder weniger dieses Verhalten.
> Nicht wirklich. Alle Karten zeigen mehr oder weniger dieses Verhalten.
Meine Güte, das sollte ein doppeldeutiger Scherz sein.
Ist denn die Redewendung, dass jemand schlechte Karten hat, heutzutage nicht mehr üblich bzw. verständlich?
@ 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.
Und wenn Falk Brunner jetzt noch mit 3 multipliziert, dann stimmt's.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.