C Atmega2560 - External Memory (SRAM)

avr_newbie

Mitglied
13. Apr. 2013
127
0
16
Bayern
Sprachen
  1. ANSI C
Hallo,

nach längerer Recherche im Internet bin ich auf ner Interssanten Seite gekommen:

http://www.scienceprog.com/adding-external-memory-to-atmega128/

Nun möchte ich gern meine Atmega2560 mit externem SRAM ausrüsten ;)

Was ich zu einem nicht 100% versteh, die Linker Anweisung:

-Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x8030ff

wieso verwent der im Beispiel hier die 0x801100 , also wieso 80 ? (.... 1100 ist klar -> da interes SRAM und Register bis dahin belegt sind)

und noch was: bei oben stehendem link wird oft der Begriff "heap" verwendet - was ist damit genau gemeint?
und: im obigem Link steht: "After initialization we can start writing program. We are going to allocate 255 bits in heap memory allocated in external ram by writing simple code..." Bei der Variable die im externen Speicher landet, wurde "malloc" verwendet, muss man das so machen?

Und hier mein Beispiel schnell zusammengekriggselt ;)

http://www.fotos-hochladen.net/uploads/unbenannt4tdrm9pn7s.jpg

Kann mir jemand sagen, ob der Schaltplan (skizze) so stimmt?
Der ausgwählte SRAM ist 128k x8 - an den Atmega2560 kann man max. aber 64k anschließen. Da ich bei Reichelt aber keinen 64k gefunden hab dachte ich mir, ich kann ja trotzdem den 128k x 8 nehmen?

Der 128k hat aber 17 Adressleitungen - was muss ich dann mit A16 machen? Gegen GND schalten?

Wenn sich das jemand drüber schauen könnte, wär ich sehr dankbar ( bevor ich mir den SRAM zulege) :wavey:
 
Nunja, malloc ist eigentlich ganz einfach.

Mit der Anweisung

Code:
uint8_t *mem;

legst Du nur einen Pointer auf einen Speicherbereich an. Danach wird mit

Code:
mem = malloc(BUFFER_SIZE);

der Speicher auch tatsächlich allokiert. Der Zeiger mem zeigt dabei auf den ersten Byte im Array.

Mit malloc allokierst Du tatsächlich den Speicher, mit free() gibst Du es dann wieder frei.

Das ist ganz nützlich, wenn Du mit Arrays in unterschiedlichen Größe arbeitest, das hilft Dir dabei den Speicherverbrauch im Rahmen zu halten, bzw. nur so viel Speicher zu verwenden, wie viel auch tatsächlich gebraucht wird. Erfordert aber auch Sorgfalt beim Programmieren.

Du musst es so nicht machen, ein einfaches

Code:
#define BUFFER_SIZE 255
uint8_t mem[BUFFER_SIZE];

tut es auch, also kommt das Gleiche dabei raus, nur es ist eben statisch auf diese Größe eingestellt.
 
Zu C kann ich Dir nichts sagen - brauch ich aber nicht, Hemi ist ja hier einer der Spezialisten dafür...

Aber zu Deinem Schaltplan: Ich hab mir jetzt die Datenblätter noch nicht genau angesehen, aber zumindest der übrige Adress-Pin sollte einen festen Pegel zugewiesen bekommen... oder an einen Prozessorpin gelegt werden, dann hast Du quasi 2 Pages.
Und als negative Versorgungsspannung des Speichers hast Du sicher nicht 5V vorgesehen, oder?

P.S.: Das Datenblatt dieses konkreten Artikels bei Reichelt ist ja echt ein Witz. Allerdings läßt sich bei der SMD-Version ein Datenblatt finden, welches auch passen könnte(!).
Wenn einer der beiden CS-Pegel kippt, geht der Speicher in einen StandBy-Mode (non selectable). Dabei scheinen die Ausgänge Tristate zu sein. Außerdem bleibt der Speicherinhalt auch bei 2V noch erhalten.
(zumindest interpretier ich das so).
 
Und als negative Versorgungsspannung des Speichers hast Du sicher nicht 5V vorgesehen, oder?

nein, das ist natürlich blödsinn... da sollte natürlich GND hin.



oder an einen Prozessorpin gelegt werden, dann hast Du quasi 2 Pages.
2 Pages bedeuted ? :confused: - Speicherbereich umschalten? damit ich 2x 64k verwenden könnte? - oder was meinst du?




äh, ja ich hab auch bei Reichelt die SMD Version angeschaut, von daher....,
allerdings sind da 3 Datenblätter zum runterladen ... und jedes mal ein anderes :D

Pinbelegung scheint gleich zu sein (schnell mal grob drüber geschaut) - da liefert wohl Reichelt grad, wie sie lustig sind....

http://www.reichelt.de/index.html?;ACTION=7;LA=3;OPEN=0;INDEX=0;FILENAME=A300%2F628128-70M%23MOV.pdf

http://www.reichelt.de/index.html?;ACTION=7;LA=3;OPEN=0;INDEX=0;FILENAME=A300%2F628128-70%23SAM.pdf

http://www.reichelt.de/index.html?;ACTION=7;LA=3;OPEN=0;INDEX=0;FILENAME=A300%2FM5M51008DFP.pdf


was mich noch wissen muss - das geht schon, dass ich einfach ein größeren Flash an den Atmega hin häng?
 
Ja genau... pages, Speicherbänke...
Du mußt halt den nicht verwendeten Adresseingang irgendwo festlegen. Dieser SRAM hat 17 Adresspins - kann also 2^17=131072 Bytes adressieren. 128 kB. Wenn der oberste Pin immer 0 ist, kannst Du nur die untere Hälfte erreichen, ist er immer 1, dann nur die obere.

Strenggenommen ist natürlich egal, welchen Pin Du so festlegst... letztendlich interessiert es Dich ja nicht, wo genau physisch Dein Byte im SRAM landet. Wichtig ist für Dich ja nur, daß die Adresse aus Deinem Programm dann beim Speichern und laden identisch bleibt. Mit der Verdrahtung legst Du quasi eine Permutation fest - und änderst sie im laufenden Betrieb nicht.

P.S.: SRAM - nicht FLASH!
 
Hallo,

habe mir jetzt einen 127k sram geholt, und nen 74hct573, Verdrahtung siehe link oben... (außer dass ich VSS natürlich auf GND gelegt hab, A16 des SRAM hab ich auf 5V gelegt)

Leider klappt das ganze nicht. Mein Display zeigt nur schrott an, seit dem ich den SRAM dran hängen hab.

Verwende Atemga2560 / 16Mhz / AVR Studio 6

init XMEM:

Code:
XMCRA =0;
XMCRA  |= (1<<SRE);
XMCRB = 0;

Linker option eingestellt (unter AVR/GNU linker => Miscellaneous):

-Wl,--section-start,.data=0x802200,--defsym=__heap_end=0x807fff


kann mir jemand sagen, was ich falsch mach, such jetzt schon mehrere tage - Beispiele sind ja mit externem RAM sehr rar.

bzw. Wenn ich den SRAM dran hab, sollen die .data variables / .bss variables ja in den externen SRAM.... durch oben beschriebene Linnker-option klappt das automatisch so? (muss also keine explizieten Befehle für Variablendeklarationen machen, dass die Variablen auch in ext. SRAM gelangen?)

Oder muss ich noch mehr beachten - weitere Linker options?
Stimmt meine Skizze/Schaltplan überhaupt ?(siehe link oben)

Für Hilfe wäre ich sehr dankbar.
 
Hi,

angesehen hab ich mir den Schaltplan noch nicht.

Stimmt meine Skizze/Schaltplan überhaupt ?(siehe link oben)

Ich hab ihn aber mal in ein verwertbares Format gebracht damit er hier im Forum steht. Bilderdienste "vergessen" gerne mal nach ein paar Monaten was man ihnen anvertraut hat :p

avr_newbie_-_XRAM.png

Ich hab es jetzt doch mal überflogen ...

1. Wie soll das SRAM seine Betriebsspannung bekommen wenn du seinen VSS-Pin nicht auf GND legst?
-> also Pin 16 auf GND. Diese SRAM-Serien (genau wie EPROMs) haben diagonal angeordnete Versorgungspins.

2. A16 (Pin2) arbeitet als Antenne und zieht sich Umgebungsschmutz rein. Also wechselt das SRAM evtl dauernd zwischen der unteren und oberen Adresshälfte. Das ist auch Mist. Also A16 entweder auf Vcc oder auf GND oder auf nen IO-Pin um damit über Blockumschaltung sozusagen quasi 2 SRAMs mit der halben Größe zu erhalten.

3. SRAMs mögen gerne Strom und zwar nicht zu wenig. Also UNBEDINGT nen Elko (22-47µF) und an beiden Enden des SRAMs nen 100nF Keramik. Also einen direkt am GND-Pin (16) mit Verbindung zu Vcc und einen direkt am Vcc-Pin (32) mit Verbindung zu GND. Am besten ist es wenn du die beiden Versorgungsleitungen direkt unter dem Baustein in Längsrichtung parallel verlegst um die Verbindungen sp kurz wie möglich zu halten. Manche SRAMs werden bei Dauerfreigabe über CE sogar handwarm. Dann kann man sich den Stromverbrauch schonmal vorstellen.

Sonst sieht es soweit erstmal OK aus.

Gruß
Dino
 
Punkt 1 und 2 von dir ist klar ... hab ich aber im vorherigem posting schon geschrieben !

EDIT:

Linker option geändert: (unter AVR/GNU linker => Miscellaneous):

-Wl,--section-start,.data=0x802200,--defsym=__heap_end=0x80ffff

XRAM initialisierung geändert:

Code:
void xram (void) __attribute__ ((naked)) __attribute__ ((section (".init3")));
void xram(void)
{
	XMCRA =0;
	XMCRA  |= (1<<SRE) |(1<<SRW11)|(1<<SRW10)  ;
	XMCRB = 0;
}


wichtig ist die initialisierung im init3
So weit ich das verstanden hab, bewirkt die init3 section, dass zuerst der SRAM initalisiert werden muss, bevor die Variablen angelegt werden.

Und wichtig: niemals diese funktion aufrufen! (z.B. im Main - war auch einer meiner Fehler?!)

aufjeden Fall scheint es jetzt zu klappen (Display zeigt kein schrott mehr an) - bin mir aber noch nicht 100% sicher ob auch alles richtig läuft (muss ich noch irgendwie testen)

;)

Ich denke nicht dass ich einen Aufbaufehler / Verdrahtungsfehler hab - hab alles tausend mal kontrolliert.

Was mir noch Sorgen macht, dass ich einen 74HCT573 verwende (hatte ich halt da) - im Datenblatt des Atmega2560 steht was, dass man einen 74AHC Typ verwenden soll, bei >8MHZ // Ich hab nen 16MHZ Quarz dran - also könnte das evtl. nocn ein Problem sein

Hab eher Probleme noch mit diesen ganzen Linkeroptionen / Initalisierungsproblem bzw. Verständnisproblem

Was mir immer noch keiner erklärt hat / bzw. nichts dazu gefunden hab, wenn ich den ext. SRAM dran hab, muss ich nichts weiter beachten, um Varaiblen und der gleichen zu deklarieren? diese landen automatisch im ext. SRAM?



Hi,

angesehen hab ich mir den Schaltplan noch nicht.



Ich hab ihn aber mal in ein verwertbares Format gebracht damit er hier im Forum steht. Bilderdienste "vergessen" gerne mal nach ein paar Monaten was man ihnen anvertraut hat :p

Anhang anzeigen 5802

Ich hab es jetzt doch mal überflogen ...

1. Wie soll das SRAM seine Betriebsspannung bekommen wenn du seinen VSS-Pin nicht auf GND legst?
-> also Pin 16 auf GND. Diese SRAM-Serien (genau wie EPROMs) haben diagonal angeordnete Versorgungspins.

2. A16 (Pin2) arbeitet als Antenne und zieht sich Umgebungsschmutz rein. Also wechselt das SRAM evtl dauernd zwischen der unteren und oberen Adresshälfte. Das ist auch Mist. Also A16 entweder auf Vcc oder auf GND oder auf nen IO-Pin um damit über Blockumschaltung sozusagen quasi 2 SRAMs mit der halben Größe zu erhalten.

3. SRAMs mögen gerne Strom und zwar nicht zu wenig. Also UNBEDINGT nen Elko (22-47µF) und an beiden Enden des SRAMs nen 100nF Keramik. Also einen direkt am GND-Pin (16) mit Verbindung zu Vcc und einen direkt am Vcc-Pin (32) mit Verbindung zu GND. Am besten ist es wenn du die beiden Versorgungsleitungen direkt unter dem Baustein in Längsrichtung parallel verlegst um die Verbindungen sp kurz wie möglich zu halten. Manche SRAMs werden bei Dauerfreigabe über CE sogar handwarm. Dann kann man sich den Stromverbrauch schonmal vorstellen.

Sonst sieht es soweit erstmal OK aus.

Gruß
Dino
 
Hi,

Linker option geändert: (unter AVR/GNU linker => Miscellaneous):

-Wl,--section-start,.data=0x802200,--defsym=__heap_end=0x80ffff

XRAM initialisierung geändert:

Code:
void xram (void) __attribute__ ((naked)) __attribute__ ((section (".init3")));
void xram(void)
{
	XMCRA =0;
	XMCRA  |= (1<<SRE) |(1<<SRW11)|(1<<SRW10)  ;
	XMCRB = 0;
}


wichtig ist die initialisierung im init3
So weit ich das verstanden hab, bewirkt die init3 section, dass zuerst der SRAM initalisiert werden muss, bevor die Variablen angelegt werden.

Und wichtig: niemals diese funktion aufrufen! (z.B. im Main - war auch einer meiner Fehler?!)

auf jeden Fall scheint es jetzt zu klappen (Display zeigt kein schrott mehr an) - bin mir aber noch nicht 100% sicher ob auch alles richtig läuft (muss ich noch irgendwie testen)

;)
also mit diesem ganzen C-Kram steh ich sowieso auf Kriegsfuß ;)

Ich schreibs einfach nochmal rein: Ob du nun A16 auf 0 oder auf 1 setzt ist für die Adressierung des Atmels absolut unwichtig. Er sieht lediglich einen Speicherbereich von 65536 Bytes. Du hast im SRAM aber 2 für den Atmel gleich aussehende Bereiche der selben Größe drin die du mit A16 umschaltest. Ob du nun also ein SRAM mit 64k oder mit 128k oder 256k am Atmel anschließt sollte für die Initialisierung im Programm identisch sein. Du schaltest mit den höheren Adresspins ab A16... nur die 64k-Bänke um. Was reinspucken könnte ist das interne SRAM und die Register weil die wohl im unteren Speicherbereich parallel zum XRAM liegen. Wenn ich es richtig verstanden habe, dann kannst du diese Adressen bei der Adressierung des XRAM nicht verwenden. Da der Mega2560 8k SRAM plus 32 Byteregister hat sind also die Adressen 0dez bis (8192+32=8224) 8223dez für dich Tabu. Erst ab Adresse 8224 kannst du das XRAM verwenden. Also Adressen 8224 bis 65535 wenn du einen 64kByte-Block mit A0..A15 verwendest. Wenn du nur einen 32kByte-Block des SRAMs verwendest (A0..A14 angeschlossen) dann kannst du ihn entweder von 32768 bis 65535 voll adressieren oder über den Adressüberlauf von 8224 bis (32767+8224=) 40991 verwenden. Wenn du im ersten Fall unter 32768 gehst, läufst du im oberen Bereich (ab 65535) wieder in den 32k-Block hinein. Im zweiten Fall würdest du über 40991 wieder unten in den 32k-Block hineinlaufen.

Schreibt dir doch mal nen RAM-Test in dem du die Speicherzellen mit Werten beschreibst und testest ob die auch drinstehen. Also einmal 0x00 reinschreiben und testen und dann 0xFF reinschreiben und testen. Dann weißt du ob es wirklich läuft. Ergebnis und Durchlauf des Tests kannst du ja auch dem LCD anzeigen. Also quasi so wie beim PC-Start der große RAM-Test vom BIOS.

Ich denke nicht dass ich einen Aufbaufehler / Verdrahtungsfehler hab - hab alles tausend mal kontrolliert.

Was mir noch Sorgen macht, dass ich einen 74HCT573 verwende (hatte ich halt da) - im Datenblatt des Atmega2560 steht was, dass man einen 74AHC Typ verwenden soll, bei >8MHZ // Ich hab nen 16MHZ Quarz dran - also könnte das evtl. nocn ein Problem sein
Wichtig scheint mir laut Datenblatt die Zugriffszeit des SRAMs zu sein. Wenn es für die Taktrate zu langsam ist, dann muß man Waitstates einfügen. Hab ich aber mal was im Datenblatt drüber gesehen. Selber hab ich aber noch kein XRAM verwendet.
 
Hi,

das mit der (falschen) Versorgungsspannung und dem nicht festgelegten Adresspin wurde bereits gesagt und zur Kenntnis genommen (nur eben noch nicht in den Plan aufgenommen).
Die Spannungsversorgung an beiden Seiten zu stützen, ist ein (für mich) neuer Hinweis.
Gegenüber den HC-ICs, deren Eingangspegel und Spannungsversorgung auf CMOS basieren (HighSpeed CMOS), sind die HCT-ICs auf TTL-Pegel (und Spannungsversorgung) festgelegt.
Für die konkreten Timing-Fragen ist natürlich immer das Datenblatt ausschlaggebend - eventuell nötige Wartezyklen des Controllers kannst Du in den Wait State Select Bits (SRWxx) im External Memory Control Register A (XMCRA) einstellen.

Wie das mit C jetzt ist, kann ich Dir auch nicht sagen, vielleicht meldet sich Hemi(?) dazu nochmal - eigentlich sollte das der Sprache aber egal sein. Mit SRE legst Du ja direkt fest, ob der Controller seinen eigenen SRAM, oder den externen ansprechen soll.
Außerdem ist (wie Dino schon hinwies) zu beachten, daß die Rechenregister und der I/O-Space "unten" in den SRAM "remapped" sind (eingeblendet - ein Zugriff auf diese Adressen landet also weder im internen, noch im externen SRAM, klar?
Wenn eine Hochsprache Dir jetzt die Zuweisung der Speicherbereiche (Adressen) für Variablen abnimmt, muß diese Hochsprache aber eigentlich auch nur den zur Verfügung stehenden Speicher kennen (also die Größe).

Hemi?

Nachtrag: wie man in Figure 8-2 sieht, beginnt der externe Adressraum nach dem internen - bei Deinem Controller also ab Adresse 0x2200. Insbesondere kann also extern nur auf den Bereich 0x2200 bis 0xFFFF, also auf 56kByte zugegriffen werden.
 
Hallo,

Die Spannungsversorgung an beiden Seiten zu stützen, ist ein (für mich) neuer Hinweis.
Also wenn man ne Platine mit ner Massefläche für GND hat, dann wird da auch ein 100nF reichen. Wenn man aber auf Lochraster bastelt, dann sind die Leitungen schonmal etwas länger und die Anbindung etwas schlechter. Da ein Abblock-C zuviel noch nicht geschadet hat und so ein SRAM nun etwas mehr Strom zieht sollte man nicht an der falschen Stelle sparen um nachher einen Fehler zu suchen.

Auf Lochraster versuche ich die Versorgungen redundant zu legen um die Leitungsinduktivitäten zu verringern und die Strompulse besser aufzufangen. Dabei kommen dann auch mal "komische" Konstrukte bei den Abblockkondensatoren raus.

Bei den Atmels hat man für sowas mehrere Versorgungspin-Paare. Da diese SRAMs aber nur zwei diagonal angeordnete Pins haben würde ich persönlich an beiden Seiten abblocken. Ist eine persönliche Vorliebe. Es hängt aber auch viel vom Platinendesign ab ob man sich den zweiten 100nF leisten sollte oder ob es einer tut.

Gruß
Dino
 
Nachtrag: wie man in Figure 8-2 sieht, beginnt der externe Adressraum nach dem internen - bei Deinem Controller also ab Adresse 0x2200. Insbesondere kann also extern nur auf den Bereich 0x2200 bis 0xFFFF, also auf 56kByte zugegriffen werden.

Deshalb hab ich auch diese linker option....
-Wl,--section-start,.data=0x802200,--defsym=__heap_end=0x80ffff

Das 80 davor bedeuted nur, dass es eine Linkeroption ist - wenn ich das richtig verstanden habe :confused:



Außerdem ist (wie Dino schon hinwies) zu beachten, daß die Rechenregister und der I/O-Space "unten" in den SRAM "remapped" sind (eingeblendet - ein Zugriff auf diese Adressen landet also weder im internen, noch im externen SRAM, klar?
äh.... du wolltest mir quasi jetzt damit sagen, dass bis Adresse 0x2200 für mich Tabu ist // so wie dino003 schon erwähnt hat....



Wenn eine Hochsprache Dir jetzt die Zuweisung der Speicherbereiche (Adressen) für Variablen abnimmt, muß diese Hochsprache aber eigentlich auch nur den zur Verfügung stehenden Speicher kennen (also die Größe).

Das ist ja das, was ich die ganze zeit wissen möchte ^^ - ob das mit der Linkeroption abgetan ist, und ob die Hochsprache (also bei mir C) die Zuweisung der Speicherbereiche (Adressen) für Variablen abnimmt



Die Spannungsversorgung an beiden Seiten zu stützen, ist für mich ebenfalls neu. Habe ich bis jetzt auch noch nie gehört/gesehn.
 
Hi,

Die Spannungsversorgung an beiden Seiten zu stützen, ist für mich ebenfalls neu. Habe ich bis jetzt auch noch nie gehört/gesehn.
wie schonmal gesagt ... auf Platinen mit Massefläche wird man nur einen Kondensator finden. Diese doppelte Abblockung mache ich persönlich um bei meinen Lochrasterkonstruktionen eine bessere Abblockung der Stromspitzen zu bekommen (oder einfach weil da meißt noch Platz ist oder es ein besserer Gefühl gibt :rolleyes:). Ich mache sowas aber auch nur bei ICs mit hohem Strombedarf und weit verteilten Versorgungsanschlüssen. Da ich genug von den kleinen Dingern habe schmeiß ich die an alle möglichen Stellen auf der Platine. Muß jeder selber wissen. Ein 100nF ist bei so einem SRAM aber absolut Pflicht.

Gruß
Dino
 
Da die Kerkos weder vom Platz, noch finanziell wirklich was kosten, schmeiß ich auch manchmal nach belieben irgendwo noch welche hin. Daß ein Abblockkerko möglichts nah an der zu stützenden Stelle den meisten Sinn macht ist auch klar.
äh.... du wolltest mir quasi jetzt damit sagen, dass bis Adresse 0x2200 für mich Tabu ist // so wie dino003 schon erwähnt hat...
kommt halt darauf an, wie C das umsetzt, insofern wirds für Dich wohl tabu sein. Ich wollte eher den Hintergrund zum Verständnis beleuchten. Ich, und insbesondere Dino (und natürlich auch andere hier) kommen eher von Assembler her, und da gibts quasi keine Tabus - man muß aber eben wissen, was man macht.
Ich bin zB der festen Überzeugung, daß wir so zB auch den Stack in den externen Speicher packen könnten usw.
Aber in der Praxis hatte auch ich noch kein externes SRAM nötig.
Also solltest Du's entweder selbst weiterprobieren, oder warten, daß sich hier doch noch mal ein C-Profi meldet.
(Dirk scheint sich da ja auch auszukennen, aber die machen ja Urlaub, und er hat mit dem Forum und dem Shop auch so viel um die Ohren...)
 
(Dirk scheint sich da ja auch auszukennen, aber die machen ja Urlaub ...)

Nein und Ja ;-)

Hallo zusammen,
in Verbindung mit GCC und AVR habe ich selber noch kein XRAM eingesetzt oder einsetzen müssen (hier nur einmal aber in Verbindung mit Assembler, für Arbeitsspeicher und MP3-Daten-FIFO).
Ich habe mich also selber noch nicht damit befasst und habe leider auch im Moment nicht so die Zeit :) ... trotzdem kurze Infos, vielleicht hilft etwas davon ja weiter.

Bei der Linker-Option die 0x80xxxx (also ein Offset von 0x800000), damit der Linker weiß, dass es sich um SRAM (XRAM) handelt (wegen Harvard Architektur = mehrere Adressbereiche für Code, SRAM, Eeprom... GCC verwendet aber nur einen).

Siehe hierzu folgende Links:

http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#harvard_arch
http://www.nongnu.org/avr-libc/user-manual/malloc.html#malloc_extram

Dirk :ciao:
 
Für alle, die auch mal XRAM verwenden möchten.

Wichtig ist auch die Linkeroption. siehe Kommentar im Source-Code

Hier mein Source Code (gleich nach den includes eingefügt) für Atmega2560
Code:
/* ##############################################################################################################################
WICHTIG 
# comment: MY NAME xD																																			
#																																	
# INFOS ZU INIT Sections und anderen wichtigen Dingen wie - Atrribute von GCC / Registerverwendung																	
# http://www.rn-wissen.de/index.php/Avr-gcc/Interna																													
#																																				
#																										
# init3 -> frei für Benutzer																																		
#																													
# warum die Nachfolgende Anweisung???																																				
#																																	
# --> Wenn ich später den externen Speicher, nicht per >>> Zeigeroperationen <<<< ansprechen möchte um so Daten abzulegen zu können			
# (infos aus http://www.mikrocontroller.net/topic/47896#new)																									
#																																				
# warum gerade die dritte Section ?																		
# -->																										
# das frühzeitige Aktivieren des XRAM-Interfaces in .init3 ist notwendig, damit dort normaler Variablenspeicher untergebracht werden kann.			
# In .init4 erfolgt dann die Initialisierung der Variablen (Kopieren der ROM-Daten für .data, Ausnullen von .bss), wenn man also					
# Variablen in den externen RAM legen möchte, muss man selbigen vorher aktiviert haben.														
#																								
#																												
# Linker option																			
# Möglichkeit 1 / first option:  -Wl,--section-start,.data=0x802200,--defsym=__heap_end=0x80ffff  //memory is used for variables (.data/.bss) and heap (malloc()).	
# Möglichkeit 2 / second option: -Wl,--defsym=__heap_start=0x802200,--defsym=__heap_end=0x80ffff   //external memory is used only for heaps		
#										
#-----------------------------------------------------------------------					
# ====> this option is currently used :: Möglichkeit 1 / first option  -					
#-----------------------------------------------------------------------	
# infos see																								
# http://www.scienceprog.com/adding-external-memory-to-atmega128/												
#																											
# Heap" nennt man den Speicherbereich, aus dem dynamische Speicheranforderungen mit malloc bedient werden.			
# //http://www.mikrocontroller.net/articles/Heap-Fragmentierung				
#																													
#																										
##############################################################################################################################
*/

void xram (void) __attribute__ ((naked)) __attribute__ ((section (".init3"))); 
void xram(void)
{
	XMCRA =0;
	XMCRA  |= (1<<SRE) |(1<<SRW11)|(1<<SRW10)  ;
	XMCRB = 0;
}


//##############################################################################################################################

Unter anderem hat mir diese Seite viel geholfen:
http://www.scienceprog.com/adding-external-memory-to-atmega128/


Und im Anhang, wie ich ihn angeschlossen habe.

Soviel als Danke für eure Hilfe.

Danke auch für die Hilfe und Unterstützung vorallem an Dirk - der mir auch in anderen Sachen echt viele Fragen beantwortet hat :)
 

Anhänge

  • xram.jpg
    xram.jpg
    243,2 KB · Aufrufe: 21

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)