Test für externes SRAM

[Ansgar (Gast)]

Hallo,

vielleicht könnt Ihr mir weiter helfen.

Ich habe ein kleines Testprogramm im Internet von Peter Fleury gefunden
und auf meine Bedürfnisse umgeschrieben, um mein externes SRAM (64KB) an
einem ATmega128 testen zu können. Diese Testprogramm läßt einen Summer
zyklisch piepen. Der Summer hängt an PORTG PIN 3.

Im makefile:
EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

Das Testprogramm sollte ein bestimmten Wert in der Adresse 0x4000 im
SRAM ablegen und nach einer gewissen Zeit wieder heraus lesen. Mit dem
Oszilloskop kann ich den Schreibzugriff erkennen (WR), nicht aber den
Lesezugriff (RD). Was mach ich falsch?

Meine Vermutung:
mit      PORTG = ~(*p);     überweise ich nur den Pointer-Wert, nicht
aber die Inhalt des Speichers von der Adresse 0x4000.

Meine Bitte:
Erklärt mir bitte, wie ich vom Speicher lesen kann. Ich habe schon libc
durch geforstet aber nichts passendes gefunden.

Danke

[OldBug (Gast)]

Möglicherweise fehlt nur das "volatile" für "p".

Wenn Du allerdings nur den Wert von der Speicherstelle 0x(80)4000 an
PORTG übergeben willst, dann geht das einfach so:

  PORTG = *p;

...mit

  PORTG = ~(*p);

wird zusätzlich Bitweise invertiert.

[Jörg Wunsch (Gast)]

> EXTMEMOPTS = -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff

Das willst du so noch nicht.  Damit legst du die globalen/statische
Variablen und den Heap in den externen RAM, obwohl du dir ja noch gar
nicht sicher sein kannst, ob der auch funktioniert.  (Du hast zwar
noch keine globalen oder statischen Variablen und benutzt auch kein
malloc(), insofern ist das eigentlich egal, aber du hast ja
offensichtlich auch gar nicht verstanden, wofür die beiden Optionen
gut sind.)

> Was mach ich falsch?

Es sieht zwar alles recht konfus aus, aber bezüglich des eigentlichen
Lesens des RAMs machst du nichts falsch.

> Meine Vermutung:

...ist falsch.  Bevor du Zeiger benutzt, bitte lies das entsprechende
Kapitel über Felder und Zeiger im Kernighan/Ritchie durch und verstehe
es.  Das sind einfache C-Grundlagen, hat mit AVR nix zu tun.

Sonstige Auffälligkeiten:

Die delay-Funktion wird nicht so arbeiten, wie erwartet, da der
Compiler Teile der Schleife wegen Nichtbenutzung wegoptimiert.  Nimm
besser die Funktionen aus <avr/delay.h>.

while (a >= 1) ist immer erfolgreich, da a nie verändert wird.

sbi und cbi gibt's nicht mehr.  Bitte benutze die Standard-C-
Bitmanipulationsoperatoren dafür (ist hier ausreichend oft diskutiert
worden).

[Jörg Wunsch (Gast)]

Ich korrigiere mich übrigens, Patrick hat Recht: das volatile für p
fehlt auch noch.  Der Lesezugriff auf den Zeiger wird einfach
wegoptimiert.

[Ansgar (Gast)]

Danke an Euch beiden.

Mit volatile hat's funktioniert. Darauf muss man erst mal kommen.

@Jörg Wunsch
> sbi und cbi gibt's nicht mehr.  Bitte benutze die Standard-C-
> Bitmanipulationsoperatoren dafür (ist hier ausreichend oft
> diskutiert worden).

Schade eigentlich.
sbi und cbi sah für mich immer übersichtlicher aus.
Übringens mit dem neuen WinAVR_20050214 geht sbi und cbi nicht mehr,
was du wahrscheinlich damit gemeint hast. Mir WinAVR_20040720 war's
noch OK.

MfG aus Westfalen
Ansgar