ATMega162 und externer SRAM

F

Florian Schenk

Guest
Hallo!

Ich hab bei einem Projekt mit dem Mega162 das Problem, dass beim
externe SRAM die oberen 8 Adressleitungen (AD8:15) scheinbar nicht
verwendet werden, obwohl die Register entsprechend gesetzt sind (hoffe
ich). Setze ich Adresse 0x500 auf einen bestimmten Wert widerholt sich
dieser alle 256 Bytes (nur 8 Adressleitungen). In meiner Schaltung
gehen AD0:7 aufs Latch und AD8:15 direkt zum SRAM. Die Ansteuerung der
unteren 255 Bytes funktioniert auch einwandfrei. Folgende Register
setzte ich bei der initialisierung in dieser Reihenfolge:

sbi(MCUCR,SRE);
sbi(MCUCR,SRW10);
sbi(EMCUCR,SRW11);
cbi(SFIOR,XMM2);
cbi(SFIOR,XMM1);
cbi(SFIOR,XMM0);

Hat jemand eine Idee warum das so nicht funktioniert?

Vielen Dank schonmal,
Florian
 
Florian Schenk wrote:

Hallo!

Ich hab bei einem Projekt mit dem Mega162 das Problem, dass beim
externe SRAM die oberen 8 Adressleitungen (AD8:15) scheinbar nicht
snip

Hast Du das JTAG-Interface per Fuse-Bit abgeschaltet? Per default ist es
enabled, und dann sind PC4-7 vom JTAG-Interface belegt.

Gruß,
Sebastian
 
Florian Schenk wrote:

snip

Hast Du das JTAG-Interface per Fuse-Bit abgeschaltet? Per default ist es
enabled, und dann sind PC4-7 vom JTAG-Interface belegt.

Ja, JTAG ist abgeschaltet. Ist meine Initialisierung so eigentlich
richtig?
Nach dem, was ich dem Datenblatt entnehme, ja; aber ich habe das ext.
RAM-Interface selbst noch nicht benutzt. Guck doch mal bei verschiedenen
Projekten in die Sources, da sollte sich doch was finden lassen. Hast Du
mal nachgesehen, ob sich auf den Ports tatsächlich nix tut? Nicht, daß Du
irgendwo in der Schaltung einen Fehler hast und der AVR korrekt arbeitet?

Gruß,
Sebastian
 
Florian Schenk wrote:

sbi(MCUCR,SRE);
sbi(MCUCR,SRW10);
sbi(EMCUCR,SRW11);
cbi(SFIOR,XMM2);
cbi(SFIOR,XMM1);
cbi(SFIOR,XMM0);
Was macht Dein Compiler daraus? Die Assembler-Befehle "sbi" und "cbi"
können die entsprechenden Register nicht adressieren.

Jan-Hinnerk
 
Jan-Hinnerk Reichert <hinni@despammed.com> schrieb:

Florian Schenk wrote:

sbi(MCUCR,SRE);
sbi(MCUCR,SRW10);
sbi(EMCUCR,SRW11);
cbi(SFIOR,XMM2);
cbi(SFIOR,XMM1);
cbi(SFIOR,XMM0);

Was macht Dein Compiler daraus? Die Assembler-Befehle "sbi" und "cbi"
können die entsprechenden Register nicht adressieren.
Wenn ich die Register aber danach auslese passen die Werte. Ich schau
mir mal den Assembler-Code an und melde mich dann nochmal.

Gruss,
Florian
 
Jan-Hinnerk Reichert <hinni@despammed.com> wrote:

sbi(MCUCR,SRE);
sbi(MCUCR,SRW10);
sbi(EMCUCR,SRW11);
cbi(SFIOR,XMM2);
cbi(SFIOR,XMM1);
cbi(SFIOR,XMM0);

Was macht Dein Compiler daraus? Die Assembler-Befehle "sbi" und "cbi"
können die entsprechenden Register nicht adressieren.
Weshalb sbi() und cbi() ja mittlerweile auch als deprecated gelten.
Kann man genauso gut gleich richtiges C schreiben:

MCUCR |= (1 << SRE);

usw. (Genau dies macht übrigens der sbi() Makro, nichts anderes.)
Vielleicht wäre ja

MCUCR = (1 << SRE) | (1 << SRW10);

ohnehin besser? ;-) Die Bitschieberei kann man bei avr-libc im Makro
_BV() verstecken, das sieht IMHO etwas übersichtlicher aus:

MCUCR = _BV(SRE) | _BV(SRW10);

Der gcc generiert die entsprechenden Befehle grundsätzlich memory-
mapped. Erst der Optimierer stellt dann fest, ob die entsprechenden
Adressen (und Bitwerte) konstant sind und in den Bereich der SBI/CBI
instructions fallen, und optimiert diese entsprechend. Wohlgemerkt,
das Verhalten des obigen C-Codes mit der Bitschieberei und des sbi()
Makros sind dabei völlig identisch. D. h. beide können gleichermaßen
auch Adressen außerhalb der Bereiche für SBI/CBI bearbeiten sowie eine
Variable Bit-Nummer, und beide generieren bei abgeschaltetem Optimizer
gleichermaßen uneffektiven Code.
--
J"org Wunsch Unix support engineer
joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/
 

Welcome to EDABoard.com

Sponsor

Back
Top