DRAM - Neue section im GCC?

[Christian W. (clupus)]

Hallo allerseits,

ich weiß, man kann sagen: Das kannst du auch anders haben, aber ich frag 
trotzdem:

Ich will einem AVR einen externen (D)RAM gönnen. Dazu wollte ich alten 
SIMM-Speicher verwenden. Nun soll in diesem Speicher einige Daten 
abgespeichert werden. Diese Daten werden auch zu bedeutenden Teilen aus 
sehr großen structs bestehen (ca. 1k große structs!). Da wird's auf den 
AVR's schon eng, wenn man die komplett über den internen SRAM übertragen 
will (von SD-Karte in DRAM).

Darum die Frage: Ist es möglich, dem avr-gcc einige neue Typen 
beizubringen, wie in der eeprom.h oder der pgmspace.h, so dass er statt 
auf den SRAM den externen DRAM verwendet?
Geht halt darum, dass die Daten, wenn sie aus der Karte kommen in 
einzelnen chars kommen und dann in einer union in die struct 
hineingedrückt werden müssen. Wenn ich das im SRAM mache, ist da kein 
Platz mehr für eine Fliege. (wenn ich nicht einen der ganz großen AVRs 
nehme, was aber nicht Sinn der Übung ist)

Die Frage ist: Wie bringe ich dem GCC bei, dass die Daten nicht ins 
SRAM sollen, sondern in einen eigenen Bereich. Da muss ich doch am 
besten eine neue section (.dram) aufmachen und die Variablen da rein 
legen, oder werden die Variablen dann auch im Speicher allokiert?

Verwaltet der GCC dann den Speicher auch? Sprich angenommen ich hätte 
einen Befehl eingegen wie folgt:

#define DRAM __attribute__((section(".dram")))
char test DRAM;

wird dann in der DRAM-section der Speicher allokiert und die Adresse 
(test sei mal die 2. char Variable) auch automatisch mit 1 (0 wäre erste 
Variable) festgelegt, so dass ich nur noch einige Zugriffsfunktionen 
schrieben müsste?

Oder klappt das so überhaupt nicht?

MfG
Christian

[Christian W. (clupus)]

Noch mal ne Frage:
Kann man eigentlich dann auch irgendwie structs/Unions in der 
.dram-section ablegen? Wenn ja, wie adressieren?
Sprich: Kann ich dem GCC beibringen, meine Benutzerdefinierten 
Zugriffsfunktionen statt der Standard-IO-ASM-Befehlen (ld, st, in, out, 
sbi, cbi,...) zu verwenden?

MfG
Christian

[Martin Thomas (Gast)]

Hoffe, ich habe die Fragen halbwegs richtig interpretiert, also "take it 
for what it's worth": Im Prinzip sollte die Vorgehensweise ueber eine 
eigene Section funktionieren. Man muss dem Linker noch mitteilen, bei 
welcher Addresse diese Section im Speicher liegen soll 
(Kommandozeilenparameter an den Linker oder modifiziertes 
Linker-Script). Die Addresse kann auch "virtuell" sein, man muss den 
Offset dann nur später beruecksichtigen. Aber: Es sind dann nicht 
wirklich "neue Typen", sondern man gibt mittels "Variable Attribute" nur 
vor, dass die Variable in einer eigenen Section verwaltet werden soll 
(ob das ein einfacher Typ oder ein Stuct ist, ist an dieser Stelle 
unerheblich). Man wird um eigene Lese- und Schriebfunktionen a la 
avr-libc/eeprom.h wohl kaum herumkommen. Einen "transparenten Zugriff" 
(also Standard-C-Syntax fuer lesen/schrieben) kann man wohl nur 
implementieren, wenn man im Compiler- bzw. Binutils selbst Hand anlegt. 
Die Addressierungsmoeglichkeiten sind jedoch ebenfalls endlich. Es 
duerfte wahrscheinlich einfacher sein, die Verwaltung des externen 
Speichers komplett selbst in einer "Zugriffslibrary" zu implementieren 
(so aehnlich als wuerde man eine Speicherkarte, externes EEPROM oder 
Flash-Speicherbaustein nutzen). Oder gleich einen anderen Controller mit 
ausreichend groessem "Addressraum" und je nach benoetigtem Speicher 
zumdem mit externem Memory-Bus nehmen.

[Christian W. (clupus)]

Hallo Martin,

also die Richtung ist schon mal gut.
also zum Thema externes RAM und so: geht leider nicht. Ziel ist die 
implementierung eines Dateisystems allerdings nicht mit minimalitischem 
Funktionsumfang, wie es mit mx 64kByte möglich wäre, sondern gleich im 
MB-Bereich. Ziel ist eine Implementierung eines Dateisystems.

Ok, also transparent wird's wohl nix ;-). Wenn ich jetzt in eine extra 
Section gehe, muss ich dann dieses Offset einrechnen in der Adresse, 
oder kann ich es machen? Ich meine, mir wäre es natürlich praktischer, 
ich müsste das Offset nicht einrechnen. Geht das, oder kommt mir der GCC 
dann durcheinander?

Eigene Zugruffsfunktionen sind klar, insbesondere da ein spezielles 
Protokoll notwendig ist. Kann ich denn auch mit den Funktionen von der 
eeprom.h auch auf structs im EEPROM zugreifen? Ich dachte immer, dass 
das nur für bytes, words (2 Bytes) und Blöcke (char Arrays) möglich sei. 
Geht das denn auch mit structs?

Der Nachteil von diesen Funktionen ist aber, soweit ich weiß, dass man 
die gesamte struct in den SRAM laden müsste, oder? Wenn ja, komm ich ja 
vom Regen in die Traufe. Dann könnte ich den Spaß mit dem DRAM nämlich 
lassen und irgendwie sonst einen zusätzlichen RAM z.B. am Mega8515 
ranhängen. Oder optimiert der GCC die nicht benötigten Teile automatisch 
weg (wenn ich auf den Superblock zugreife, brauche ich am Anfang sowieso 
nur wenige Teile der struct.)

Oder gibt es eine Möglichkeit, dass man die Adresse eines bestimmten 
Teils einer struct herausbekommt? Ich meine nach dem Motto: Ich 
definiere die struct. Dann habe ich einen linearen Speicher und der wird 
dann von meinem Programm aus so aufgerufen, dass er zunächst die 
Start-Adresse der struct ermittelt und dann mithilfe eines Offsets die 
genaue Position in der struct ermittelt. Die Frage ist nun, wie ich 
dieses Offset möglichst einfach aber auch sparsam bestimmen kann 
(Preprozessor?). (Bei einem struct mit ca. 30 Einträgen ist es nämlich 
nicht feierlich, das von Hand auszurechnen!)


MfG
Christian

[Andreas S. (andreas) (Admin)]

Christian Wolf wrote:
> also zum Thema externes RAM und so: geht leider nicht. Ziel ist die
> implementierung eines Dateisystems allerdings nicht mit minimalitischem
> Funktionsumfang, wie es mit mx 64kByte möglich wäre, sondern gleich im
> MB-Bereich.

Und welchen Sinn soll das auf einem Mikrocontroller wie dem AVR ergeben?