ATMega162 und externer SRAM

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From German to

Threaded View
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


Re: ATMega162 und externer SRAM

Quoted text here. Click to load it
<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

Re: ATMega162 und externer SRAM

Quoted text here. Click to load it

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

Re: ATMega162 und externer SRAM

Quoted text here. Click to load it

Was macht Dein Compiler daraus? Die Assembler-Befehle "sbi" und "cbi"
können die entsprechenden Register nicht adressieren.

 Jan-Hinnerk


Re: ATMega162 und externer SRAM

Quoted text here. Click to load it

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


Re: ATMega162 und externer SRAM

Quoted text here. Click to load it


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 /

Site Timeline