SST25VF032B flash an xmega32a4u

[Karsten (Gast)]

Hallo Gemeine,

ich habe eine Applikation (autarker Datenlogger), bei dem ich die 
Sensordaten über einen längeren Zeitraum aufzeichnen möchte.
Als Speicher habe ich mir einen SST25VF032B 32 Mbit Flash ausgesucht. 
Der bietet viel Platz um Daten über einen längeren Zeitraum zu sammeln.

Nun mein Verständnisproblem:

sehe ich dass richtig, dass zum Schreiben eines Bytes (oder mehrer 
Bytes) erst ein 4 KByte Sektor gelöscht werden muss. D.h. die 4KByte 
Daten müssen zunächst vom Flash im uC zwischengespeichert werden, 
anschliessen den 4KB-Block löschen, die Daten modifizieren und die 4 KB 
in den Flash zurückschreiben. Alles soweit klar, aber die 4 KB im xmega 
brauchen das komplette SRAM völlig auf. Gibt es eine andere Möglichkeit 
Byteweise das Flash zu beschreiben ohne jedesmal einen Block löschen zu 
müssen?

Gruß

Karsten

[M.T. (Gast)]

Hallo Karsten

Hier steht alles drin:
http://arduino-projects4u.com/software/SST25VF032B_005.ino

Viele Grüsse

[Karsten (Gast)]

Hat sich erledigt.

Da Problem wird hier diskutiert:
Beitrag "Re: Datenlogger-Bau, wo Daten speichern"

Karsten

[Karsten (Gast)]

Hi M.T.

vielen Dank. Mein Problem wird im Grunde hier beschrieben
Beitrag "Re: Datenlogger-Bau, wo Daten speichern".

Wie der Speicher zu verwenden ist , ist mir im Prinzip klar (es gibt 
auch diverse Treiber im Netz dazu).

ABER: Vor dem Schreiben müssen der oder die zu beschreibende(n) 
Zelle(n)0xff enthalten (=gelöscht). D.H. es muss mind. ein 4 KByte 
Sektor gelöscht werden. Befinden sich bereits Daten in diesem Block, 
müssen diese natürlich vor dem Löschen im uC gepuffert werden. Bei 4KB 
RAM im xmega32A4U wird das ein Problem bei einer Flash page size von 4 
KB!
Ein wirkliches Beispiel für AVRs mit wenig RAM habe ich aber nicht 
gefunden.
Dein Programm beschreibt aber nur die ersten 32 Bytes von 4096 Bytes 
eines Sektors. Das ist doch eher Verschwendung von Speicherplatz.
So wie ich das Datenblatt verstehe:
1) 4096 Bytes im uC puffern, damit die vorhandenen Daten durch das 
Löschen nicht verloren gehen.
2) Den 4 KB Sektor löschen
3) die gepufferten Daten bearbeiten (neue Daten ergänzen, alte 
bearbeiten)
4) Gepufferten 4 KB in das Flash zurückschreiben.

Vielleicht habe ich im Datenblatt auch was überlesen, das es einfacher 
geht?

So wie ich die Sache derzeit sehe, gibt es folgende Alternativen:
1) uC mit mehr RAM
2) Flash mit einer geringeren Sektorgrösse
3) SD-Karte

uC steht fest.
Das 32 Mbit Flash ist wohl für meinen uC nicht zu gebrauchen.
Was die Speichermedien anbelangt werde ich mir die Vorschläge im 
genannten Thread anschauen.


Trotzdem vielen Dank für Deine Antwort :)

Wie bereits geschrieben, gibt es einen anderen Thread, der sich mit 
meiner Fragestellung beschäftigt.

VG

Karsten

[M.T. (Gast)]

Hallo Karsten

Das mit den Flash Speichern ist halt so eine Sache. Wir haben uns 
während der Entwicklung eines Datenloggers für die Verwendung von 
SD-Karten entschieden.
Dies hat einige ganz relevante Vorteile:
- Extrem grosser Speicherplatz
- Ablage der Daten als CSV in einzelnen Dateien
- Sehr einfacher Transfer zum PC
- Benötigt wenige, günstige Bauteile

Viele Grüsse

[Lattice User (Gast)]

Karsten schrieb:
> 3) die gepufferten Daten bearbeiten (neue Daten ergänzen, alte
> bearbeiten)

Du kannst Bytes die 0xFF enthalten jederzeit ohne zu Löschen 
überschreiben,
d.h. wenn du dich auf das Ergänzen beschränkst gibt es keine Probleme.

Es gibt auch SPI Flashes, die einen internen Buffer haben, z.B. 
http://www.adestotech.com/dataflash

[Christian R. (supachris)]

Eben, für einen Datenlogger musst du ja eigentlich nichts überschreiben. 
Dann gehts auch ohne Puffer. Schreiben geht in Bytes oder Pages...

[eagle user (Gast)]

Du musst auch sonst nichts überschreiben wenn du immer abwechselnd zwei 
Sektoren benutzt (oder mehrere als Ringpuffer). Das hat auch den großen 
Vorteil, dass ein Stromausfall beim Kopieren nicht zum Datenverlust 
führt (4K dauern ja doch ein wenig).

Du kannst auch beides kombinieren, wenn z.B. alle Daten z.B. in 1K 
passen, kopierst du 4 Mal in den gleichen Sektor und nimmst dann erst 
den nächsten...