AT45DB (DataFlash): Adressierung

[Andreas K. (all-finder)]

Hallo beisammen,

folgende Frage bzgl. der Adressierung des ATMEL AT45DB081D (ausgegangen 
von einer Pagegröße von 256byte). Ich habe 20 bit Werte,

9bit für den Block | 3bit für die Page des Blocks | 8bit für ein Byte

lt. Datenblatt sollen die 3 Adressbytes nach dem opcode übertragen 
werden. Wie werden diese zusammengesetzt? Habe ja 24bit für 20bit 
Adressen zu Verfügung stehen. Sollen diese vorne oder hinten angehangen 
werden?

Pinzipell möchte ich Hex-Daten im Speicher ablegen und da diese von 
anderen Schnittstellen kommen sind mir 256byte-Blöcke sympatischer als 
264byte Blöcke. Oder gibts hierzu andere Meinungen?

Danke, MfG

[Knut B. (Firma: TravelRec.) (travelrec)]

Da steht alles drin.

[genau so (Gast)]

Ich verwende 264byte Bloecke und habe pro 256Bye noch 8 Byte fuer CRC 
und dergleichen.

[Andreas K. (all-finder)]

danke. (wer lesen kann... ist klar im vorteil) warum auch immer die 
abbildungen im anhang sein müssen.. :(

okay, is ne idee.. wie hoch ist die wahrscheinlichkeit für einen 
übertragungsfehler zw. speicher und controller? (abstand nicht mehr als 
4 mm, keine störquellen in direkter übergebung, bei 8MHz)

[genau so (Gast)]

Es geht weniger um Uebertragungsfehler als um Speicherfehler. Zugegeben, 
die Atmel Datenflash sind NOR-Flash und daher viel zuverlaessiger als 
NAND-Flash, aber eben nicht 100%. Diese 8 Byte verwendet man am Besten 
als speicher fuer Hammingcode, damit kann man je nach Code-Laenge 1 bit 
Fehler korrigieren kann. Ein CRC ist eigentlich 2. Wahl, da man damit 
allenfalls einen Fehler erkennen, aber nicht korrigieren kann.

[Andreas K. (all-finder)]

Etwas offtopic, möchte aber keinen neuen Thread eröffnen:
- ich kann während z.B. Buffer 1 in den Speicher schreibt nicht 
gleichzeitig in Buffer 2 schreiben?!
- und schlimmer, während ein Speicherbereich gelöscht wird, ist der 
Speicher ebenfalls "busy"?

:(

also wäre es sinnvoll, vor der Schreibinteraktion den Speicherbereich zu 
löschen...

[ahem (Gast)]

Waehrend der Buffer1 in Flash kopiert wird kann man nauterlich in den 
Buffer2 schreiben. Das dauert so um die paar ms.

[Andreas K. (all-finder)]

Dann verstehe ich das DB nicht, dort steht, dass (z.B. unter 7.8, 
letzter Satz), dass das Statusregister angibt, dass der "Teil" busy ist. 
Nur kann ich beim Statusregister nicht Bereiche abfragen, sondern nur 
den Gesamtstatus des Speichers...

[Andreas K. (all-finder)]

evtl. hier noch ein Auszug...

[ahem (Gast)]

Both the erase and programming are self timed.... ja. aber waehrend 
dieser Zeit kann man in den anderen Bbuffer schreiben. Im Prinzip kann 
man waehrend der Programmierzeit den anderen Buffer gesammt fuellen und 
so dauernd programmieren. Damit erreicht man die maximale Schreibrate 
von 1 Seite/ Programmierzeit.

[ahem (Gast)]

Sorry das ist der falsche mode. Nicht main memory page through buffer, 
sondern ... buffer write + buffer to main memory with built in erase.

[Andreas K. (all-finder)]

ahem wrote:
> Sorry das ist der falsche mode. Nicht main memory page through buffer,
> sondern ... buffer write + buffer to main memory with built in erase.

Ist das nicht das selbe? Während des Vorgangs "buffer to main memory 
with built in erase." ist der Speicher wieder busy. Bei jeder Funktion 
(außer beim Schreiben in einen Buffer) steht eine Wartezeit...

oder habe ich nur die Busyeigenschaft vom Datenregister falsch 
aufgefasst?

[ahem (Gast)]

Ist das nicht das selbe?

Nein, ist es nicht. Denn der andere Buffer ist benutzbar (schreibbar). 
Ohne Wartezeit. Das Busy bezieht sich auf den Vorgang, der dauert.

[ahem (Gast)]

Ich betreib meine Datenflash immer so. Jeweils 4ms Wartezeit waeren 
nicht tragbar.