ext. Memory-Interface: Verwirrung mit phys. Adr.

[haube (Gast)]

also es geht um ATMEGA2561 mit intern 8KByte SRAM, extern sind 32 KByte 
angeschlossen .. 64KByte kann er adressieren.

die 32KB sind so wie laut datenblatt, also 
XMem_Bit[0-14]<->Adr._Bit[0-14] angeschlossen !

wie ist das nun mit dem speicher den ich wirklich zur verfügung habe?

sind das 32KByte  un die erste 8KByte des externen speichers fallen weg 
oder kommen die internen 8KByte auch dazu =40KByte.. ??

[Johannes M. (johnny-m)]

Schau einfach mal ins Datenblatt. Da steht, wie der Speicher organisiert 
ist. Es gibt sogar ein schön anschauliches Diagramm im Abschnitt "AVR 
Memories" (in meiner Datenblattversion ist das Fig. 12, aber mein DS ist 
möglicherweise nicht ganz aktuell).

[haube (Gast)]

jo hab ich auch .. aber das diagramm verwirrt mich !

ist der untere bereich  in der linken spalte adressierbar oder nicht ?? 
irgendwie unvorteilhafte darstellung ..
is komisch   der text zum bild :

"9.1.5 Using all Locations of External Memory Smaller than 64 KB
Since the external memory is mapped after the internal memory as shown 
in Figure 9-1, the
external memory is not addressed when addressing the first 8,704 bytes 
of data space. It may
appear that the first 8,704 bytes of the external memory are 
inaccessible (external memory
addresses 0x0000 to 0x21FF). However, when connecting an external memory 
smaller than 64
KB, for example 32 KB, these locations are easily accessed simply by 
addressing from address
0x8000 to 0xA1FF. Since the External Memory Address bit A15 is not 
connected to the external
memory, addresses 0x8000 to 0xA1FF will appear as addresses 0x0000 to 
0x21FF for the
external memory. Addressing above address 0xA1FF is not recommended, 
since this will
address an external memory location that is already accessed by another 
(lower) address. To
the Application software, the external 32 KB memory will appear as one 
linear 32 KB address
space from 0x2200 to 0xA1FF. This is illustrated in Figure 9-6."

naja ..   es ging mir nur um darum um allen speicher zu nutzen ..  also 
möchte sehr gern 40KB haben ..

[Stefan E. (sternst)]

haube wrote:

> ist der untere bereich  in der linken spalte adressierbar oder nicht ??

Ja.

> irgendwie unvorteilhafte darstellung ..
> is komisch   der text zum bild :

Also ich finde sowohl das Bild als auch den Text klar und verständlich.

[Skua (Gast)]

Wenn du den externen Speicher von 0 an adressierbar machst fehlen die 
ersten 8k.
Sprich die Adressen 0..0x21FF erscheinen nicht auf dem Bus.

[(prx) A. K. (prx)]

Wenn der externe Speicher nicht durch entsprechende Dekodierung 
künstlich auf 0..7FFF begrenzt wird, dann stehen die externen 32KB voll 
zur Verfügung.

Der externe Speicher findet sich dann 2mal im Adressraum, an 2200..7FFF 
und an 8000..FFFF. Was im ersten Teil fehlt kann im zweiten Teil 
verwendet werden.

[haube (Gast)]

@ Stefan:

ja aber in der jetztigen verbindung speicher<>Controller ...  ist es 
nicht adressierbar ...

wenn ich das richtig sehe ..  der ext. ram müsste zu den Adressbits des 
uC  nach hinter verschoben sein ..


na OK .. dann hab ich mit der aktuellen hardware eben nur 32KByte ...
hätte ja sein können das der Atmega den internen SRAM irgendwie anders 
adressiert als den externen...

[Stefan E. (sternst)]

haube wrote:

> ja aber in der jetztigen verbindung speicher<>Controller ...  ist es
> nicht adressierbar ...

Doch. Adresse 0x8000 ist z.B. A15=1 Rest=0. Da A15 aber nicht 
angeschlossen ist, ist das für das ext. RAM einfach Adresse 0x0000. Die 
letzten 8k des 40k-Bereichs adressieren die ersten 8k des ext. 
Speichers.

[Skua (Gast)]

>die 32KB sind so wie laut datenblatt, also
>XMem_Bit[0-14]<->Adr._Bit[0-14] angeschlossen
Wenn bit 15 nicht ausgewertet wird stimmt das was A.K. sagt
dann geht dein Speicher bis A1FF.

[haube (Gast)]

uh ja ..   hab die hardwareverdrahtung nicht erstellt und euch auch 
nicht erzählt das A[15] am chipSelect (LowAktiv) hängt ...  sorry

dann gehts nicht .

aber danke für die erklärung .. jetzt versteh ichs was ihr meintet .

[haube (Gast)]

also CS des externen speichers mein ich

[Stefan E. (sternst)]

haube wrote:
> uh ja ..   hab die hardwareverdrahtung nicht erstellt und euch auch
> nicht erzählt das A[15] am chipSelect (LowAktiv) hängt ...  sorry

Dann trenne die Verbindung auf und lege CS auf GND.

[(prx) A. K. (prx)]

Was nur dann so einfach geht, wenn nicht noch andere Peripherie wie 
beispielsweise ein Ethernet-Interface irgendwo in 8000-FFFF angespeochen 
wird.

[haube (Gast)]

jo.. schon klar .. geht aber nicht so einfach .. es sind noch weitere 
devices in höheren adressen  2UARTS und NIC  --  das würde die ganze 
logik durcheinander bringen

[Läubi .. (laeubi)]

Du kannst die unteren 8k des Speichers aber manuell ansprechen!
Steht auch im Datenblatt irgenwo.

Using all 64KB Locations of
External Memory
Since the External Memory is mapped after the Internal Memory as shown in Figure 11,
only 64,928 bytes of External Memory is available by default (address space 0x0000 to
0x025F is reserved for Internal Memory). However, it is possible to take advantage of
the entire External Memory by masking the higher address bits to zero. This can be
done by using the XMMn bits and control by software the most significant bits of the
address. By setting Port C to output 0x00, and releasing the most significant bits for normal
Port Pin operation, the Memory Interface will address 0x0000 - 0x1FFF. See code
example below.
Note: 1. See “About Code Examples” on page 7.
Care must be exercised using this option as most of the memory is masked away.
Assembly Code Example(1)
; OFFSET is defined to 0x2000 to ensure
; external memory access
; Configure Port C (address high byte) to
; output 0x00 when the pins are released
; for normal Port Pin operation
ldi r16, 0xFF
out DDRC, r16
ldi r16, 0x00
out PORTC, r16
; release PC7:5
ldi r16, (1<<XMM1)|(1<<XMM0)
out SFIOR, r16
; write 0xAA to address 0x0001 of external
; memory
ldi r16, 0xaa
sts 0x0001+OFFSET, r16
; re-enable PC7:5 for external memory
ldi r16, (0<<XMM1)|(0<<XMM0)
out SFIOR, r16
; store 0x55 to address (OFFSET + 1) of
; external memory
ldi r16, 0x55
sts 0x0001+OFFSET, r16
C Code Example(1)
#define OFFSET 0x2000
void XRAM_example(void)
{
unsigned char *p = (unsigned char *) (OFFSET + 1);
DDRC = 0xFF;
PORTC = 0x00;
SFIOR = (1<<XMM1) | (1<<XMM0);
*p = 0xaa;
SFIOR = 0x00;
*p = 0x55;
}

Aus dem Atmega 8515 DB Seite 33, wird es denk ich bei dir auch geben so 
eine Beschreibung..

[Stefan E. (sternst)]

haube wrote:
> jo.. schon klar .. geht aber nicht so einfach .. es sind noch weitere
> devices in höheren adressen  2UARTS und NIC  --  das würde die ganze
> logik durcheinander bringen

Und du meinst nicht, dass diese Info nicht auch schon im ersten Post 
hinsichtlich der ursprünglichen Frage von Interesse gewesen wäre?

[haube (Gast)]

jo ich sag ja sorry ..   es geht ja darum dass die HW evtl. auch mal 
geändert werden kann ...   also hat mir schon geholfen ...

[haube (Gast)]

@Läubi:

dann müsst ich quasi  immer umschalten wenn ich alle 40 KB nutzen will 
?

ja möglich wär das wahrscheinlich ..

ich prorammiere in C.  so richtig hilft mir das glaub auch nicht weiter 
..

wie soll ich dem compiler beibringen immer in diesem speicherbereich 
irgenwas vorher zu tun bevor er lesen /schreiben kann .

[(prx) A. K. (prx)]

Kannst du nur "zu Fuss" machen, wenn du diese 8,5KB für irgendwelche 
speziellen Zwecke verwenden willst.

[haube (Gast)]

hmm ok, dacht ich mir .. aber gut zu wissen --  man weiß ja nie was noch 
kommt!

[Läubi .. (laeubi)]

Naja, wie gesagt das sit ne "Manuelle" Sache und im Datenblatt steht 
auch explizit das man beachten soll das ein großer Teil des 
Speicherbereiches dann ausgeblendet ist, vorsicht ist hier z.B: geboten 
wenn der Stack oder variablen dort liegen!
Unter ASM kein Problem da man eh weiß was getan werden soll. Unter C muß 
man halt aufpassen.
Aber wenn man "nur" einen Puffer braucht, um z.B. Meßwerte zu speichern 
kann das schon hinhauen.