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.. ??
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).
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 ..
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.
Wenn du den externen Speicher von 0 an adressierbar machst fehlen die ersten 8k. Sprich die Adressen 0..0x21FF erscheinen nicht auf dem Bus.
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.
@ 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...
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.
>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.
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 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.
Was nur dann so einfach geht, wenn nicht noch andere Peripherie wie beispielsweise ein Ethernet-Interface irgendwo in 8000-FFFF angespeochen wird.
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
Du kannst die unteren 8k des Speichers aber manuell ansprechen! Steht auch im Datenblatt irgenwo.
1 | Using all 64KB Locations of |
2 | External Memory |
3 | Since the External Memory is mapped after the Internal Memory as shown in Figure 11, |
4 | only 64,928 bytes of External Memory is available by default (address space 0x0000 to |
5 | 0x025F is reserved for Internal Memory). However, it is possible to take advantage of |
6 | the entire External Memory by masking the higher address bits to zero. This can be |
7 | done by using the XMMn bits and control by software the most significant bits of the |
8 | address. By setting Port C to output 0x00, and releasing the most significant bits for normal |
9 | Port Pin operation, the Memory Interface will address 0x0000 - 0x1FFF. See code |
10 | example below. |
11 | Note: 1. See “About Code Examples” on page 7. |
12 | Care must be exercised using this option as most of the memory is masked away. |
13 | Assembly Code Example(1) |
14 | ; OFFSET is defined to 0x2000 to ensure |
15 | ; external memory access |
16 | ; Configure Port C (address high byte) to |
17 | ; output 0x00 when the pins are released |
18 | ; for normal Port Pin operation |
19 | ldi r16, 0xFF |
20 | out DDRC, r16 |
21 | ldi r16, 0x00 |
22 | out PORTC, r16 |
23 | ; release PC7:5 |
24 | ldi r16, (1<<XMM1)|(1<<XMM0) |
25 | out SFIOR, r16 |
26 | ; write 0xAA to address 0x0001 of external |
27 | ; memory |
28 | ldi r16, 0xaa |
29 | sts 0x0001+OFFSET, r16 |
30 | ; re-enable PC7:5 for external memory |
31 | ldi r16, (0<<XMM1)|(0<<XMM0) |
32 | out SFIOR, r16 |
33 | ; store 0x55 to address (OFFSET + 1) of |
34 | ; external memory |
35 | ldi r16, 0x55 |
36 | sts 0x0001+OFFSET, r16 |
37 | C Code Example(1) |
38 | #define OFFSET 0x2000 |
39 | void XRAM_example(void) |
40 | { |
41 | unsigned char *p = (unsigned char *) (OFFSET + 1); |
42 | DDRC = 0xFF; |
43 | PORTC = 0x00; |
44 | SFIOR = (1<<XMM1) | (1<<XMM0); |
45 | *p = 0xaa; |
46 | SFIOR = 0x00; |
47 | *p = 0x55; |
48 | } |
Aus dem Atmega 8515 DB Seite 33, wird es denk ich bei dir auch geben so eine Beschreibung..
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?
jo ich sag ja sorry .. es geht ja darum dass die HW evtl. auch mal geändert werden kann ... also hat mir schon geholfen ...
@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 .
Kannst du nur "zu Fuss" machen, wenn du diese 8,5KB für irgendwelche speziellen Zwecke verwenden willst.
hmm ok, dacht ich mir .. aber gut zu wissen -- man weiß ja nie was noch kommt!
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.
Bitte 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.