Forum: Mikrocontroller und Digitale Elektronik Externes Speicherinterface Hintergrundwissen


von Thomas Wiemken (Gast)


Angehängte Dateien:

Lesenswert?

Hi Leute,
habe vorhin schom im GCC Forum gepostet, aber es scheint mir, dass hier
mehr los ist. Vielleicht kann mir hier jemand eine Antwort geben?

Ich verwende einen ATmega128, der mit dem externen Speicherinterface
zwei SRAM-Bausteine a 512kB anspricht. Dazu verwende ich drei weitere
Port Pins als Adressleitungen und zwei Port Pins um die SRAM-Bausteine
mittels Chip Enable zu de- / aktivieren.

Um den Speicher zu testen, habe ich ein kleines Testprogramm
geschrieben, das unten dargestellt ist. Das ganze klappt auch
wunderbar
und ist soweit alles in Ordnung, ich habe nun eine Frage zu der
Initialisierung des externen Speicherinterface.

Im speziellen habe habe ich ne Frage zu dieser Codezeile

<c>
void xram(void) _attribute_ ((naked)) _attribute_ ((section
(".init1")));
</c>

So wie ich es verstanden habe sorgt man somit dafür, dass das
Speicherinterface frühzeitig initialisiert wird. Somit wird dem
Compiler? oder Linker? mitgeteilt, das er den externen Speicher nutzen
kann.

Oder sehe ich das falsch?

Ich habe das ganze auch mal ohne diese vorzeitige Initialisierung
gemacht, sondern die Funktion void xram(void) ganz normal in der
main()aufgerufen. Das Ergebnis war, dass es auch so funktionierte.

Deshalb meine weitere Frage, wozu macht man es dann und was kann
passieren, wenn mann es nicht macht?

Mir geht es darum, den Hintergrund zu verstehen, da ich es für eine
Ausarbeitung gebrauche und den Quellcode begründen soll.

Vielleicht hat der werte Herr Jörg Wunsch Zeit und Möglichkeit mir
darauf zu antworten, da ich diesen Code bzw. diese Befehlszeile in
einen Beitrag von ihn gefunden habe.

Mein kleines nicht sehr anspruchvolles, aber funktionierendes
Testprogramm ist als Dateianhang beigefügt.

Gruß und Freude
Thomas

von Stefan S. (phunky)


Lesenswert?

Hallo,

>So wie ich es verstanden habe sorgt man somit dafür, dass das
>Speicherinterface frühzeitig initialisiert wird. Somit wird dem
>Compiler? oder Linker? mitgeteilt, das er den externen Speicher
nutzen
>kann.

Du teilst damit nicht dem Linker oder Compiler mit, dass ein externer
Speicher benutzt wird, sondern du sagst dem Prozessor an dieser Stelle
dass das externe Speicherinterface benutzt werden soll, du aktivierst
also die Schnittstelle zum Speicher.

Zur Begründung warum der Speicher "früh" (.init) aktiviert werden
soll:
-Wenn der Stack im externen Speicher liegt (was allerdings nicht
empfohlen wird) wird selbiger bereits angesprochen bevor du in main den
externen SRAM aktivieren kannst.
-Wenn du globale Variablen hast, welche im externen SRAM liegen (falls
man per Linkeranweisung selbige in den externen SRAM verlagert), werden
diese vor Eintritt in main in einer weiteren .init Section mit 0
initialisiert. Auch dafür muss der externe SRAM natürlich bereits aktiv
sein.

Solange du nur "per Hand" auf den externen SRAM zugreifst sollte es
genügen ihn erst in main zu aktivieren.

In der Doku der avrlibc sind einige gut verständliche Grafiken wie der
Speicher mit unterschiedlichen Linkereinstellungen eingeteilt wird.

Gruß
Stefan

von Thomas Wiemken (Gast)


Lesenswert?

Hallo Stefan,

wenn ich dich richtig verstehe, ist das was ich in meinen Testprogramm
mache das "per Hand" auf den externen Speicher zugreifen.

Ich brauche nichtmal per malloc() den Speicher reservieren, es klappt
auch so ohne Probleme.

Also ist die (.init) Anweisung nur dann zwingend, wenn ich globale
Variablen im externen Speicher initialisieren möchte oder sich der
Stack im externen Speicher befindet.

Ach ja:
Im Makefile habe ich folgende Anweisung, die so wie ich es verstanden
habe, für den Linker gedacht ist.

EXMEMOPTS =
-wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80ffff

damit befindet sich der Heap im externen Speicher.
Der Stack müsste sich immer noch im internen Speicher befinden.
So alles andere auch, ist jedenfalls so in der avrlib zu sehen.

Verwende ich die andere im Makefile gegebene Option
EXMEMOPTS = -wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

dann schmiert mir der Prozessor komplett ab.

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
Noch kein Account? Hier anmelden.