Hallo,
ich habe wieder mal ein Problem, bei dem ich nicht weiterkomme.
Ich habe eine Schaltung mit ATmega162, 74HCT573 und einem 32k Speicher AS7C256. Mit Hardware Interface funktioniert die Schaltung. Für Testzwecke versuche ich das nun mit einer ASM Software Lösung.
Was ist denn Data? Du musst an dieser Stelle ein register angeben, zum Beispiel
in r16,pina
Ich bin unsicher, ob die Groß/Kleinschreibung von PinA hier eine Rolle spielt. Als ich meine AVR noch in Assembler programmierte, hatte ich die Registernamen jedenfalls immer klein geschrieben.
Ich kenn den ATmega162 nicht aber die 80xx. So wie ich im Manual des 162 es verstehe kann man mit Steuerregistern das externe Interface für den XMEM aktivieren. Danach müßte das Interface die Steuersignale selbst generieren.
Insbesondere werden die Datenrichtungsregister überschrieben.
Würde für mich auch keinen Sinn machen wenn man bei XMEM die Steuersignale noch selbst erzeugen müßte.
es verstehe kann man mit Steuerregistern das externe Interface für den
XMEM aktivieren
Das ist völlig richtig und wie ich eingangs geschrieben habe funktioniert die Schaltung wenn ich XMEM nutze. Ich brauche die Softwarelösung aber für ein anderes Problem.
/OE des RAM kommt an /RD von der CPU.
Nur vor dem Lesen wird /RD=0 und danach /RD = 1.
Beim Adresse laden und beim Schreiben muß /RD = 1 bleiben.
Ich zitiere nochmals das Datenblat:
quote
A read cycle is accomplished by asserting chip enable (CE) and output enable (OE) LOW, with write enable (WE) high.
unquote
Für den Zugriff auf das RAM mit CE auf low mußt du ein Port als High Adress verwenden. /WE muss high sein . Dann die Lowadresse an den Port mit dem Latch
ALE auf Low und sofort wieder auf High. Wenn du schreiben willst Daten an den Datenport und danach /WE auf low und sofort wieder auf high.
Lesen: Adressen wie zuvor an die Ports. Datenport danach auf lesen. /OE auf low. Port lesen. /OE auf high setzen.
Ich habe den Code mal so abgeändert, wie ich den Vorschlag verstanden habe. Nur OE habe ich weggelassen, da es fest verdrahtet ist und im Datenblatt auch so nicht vorkommt. Leider hat das nichts geändert.
Ich muß noch hinzufügen, daß ich natürlich schon alles möglich eversucht habe. So habe ich sowohl das Latch als auch das RAM unabhängig voneinander getestet und es hat funktioniert. Das Problem kann also nur an der Kombination der beiden ICs liegen.
/OE aktiviert den Ausgang des RAM. Auf den Datenleitungen liegen somit immer Daten die dem Speicherinhalt der jeweiligen Adresse liegen. Das kann nicht funktionieren.
Nichts für ungut - manchmal mögen meine Assoziationen vielleicht etwas schräg sein (bringt das Alter so mit sich):
" ... einen Streich spielen. Er wird sogar die Lebkuchen aufs Spiel setzen und sich vielleicht den verderblichsten Unsinn wünschen, den allerunökonomischsten Blödsinn, einzig um in diese ganze positive Vernünftigkeit sein eigenes unheilbringendes phantastisches Element beizumischen. Gerade seine phantastischen Einfälle ... "
hat Heiner B. schon alles gesagt (das Verhalten ist im besten Falle
undefiniert).
Ich würde es doch vorsichtigerweise eher so ausdrücken: es ist nur nicht dokumentiert. Leider kann ich zum konkreten Delinquenten Atmega162 auch nichts sagen, aber ich habe vor Jahren andere AVRs mit XMEM-Interface beackert (konkret: 8515), bei denen das ebenfalls nicht dokumentiert war, sich aber immerhin doch ein funktionierender Workaround für den rein Software-basierten Zugriff realisieren ließ.
Allerdings war da keiner der XMEM-Pins dediziert, alle liessen sich auch über ganz normale GPIO-Zugriffe erreichen (jedenfalls, wenn das XMEM-Interface deaktiviert war). Ein /OE gab es dort allerdings meiner Erinnerung nach gar nicht.
Wenn man ein Oszilloskop hat, schaut man sich an, wie die funktionierende Schaltung abläuft.
Hat man keins, macht man es sicherheitshalber so wie alle Anderen, also:
RD und WR high, ALE Low
Adresse auf die Adressausgänge (hier PA und PC)
ALE hoch
ALE wieder runter, Adresse ist am RAM
Dann zum Schreiben:
Datenbyte auf PA ausgeben
WR runter
WR wieder rauf
oder zum Lesen:
PA auf Input umschalten
RD runter
PA einlesen
RD wieder rauf
schon funktionierts. Alle Abweichungen von dieser Reihenfolge
geschehen auf eigene Gefahr.
Vielleicht soll partout ein Controller-Pin eingespart werden; in diesem Fall könnte man acht Widerstände in den Datenbus zum RAM einschleifen, geschätzt 220 Ohm bis 1 k - aber oh je ...
Noch einfachere Lösung: Mikrocontroller mit eingebauten 32 KiB RAM
nutzen, z.B. STM32G070CB.
Oder lieber gleich was wirklich brauchbares: RP2354 mit satten 520kByte. Viel billiger als die ganze kleine STM32-Gülle und viel mehr Resourcen.
Selbst mit STM32M4 muss man sich schon ordentlich strecken, um an diese Performance mit diesen Resourcen heran zu kommen. STM hat mit diesen neuen RP endgültig ausgedient. Jedenfall für fast alles unterhalb H7/G7.
Gut so. Konkurrenz belebt das Geschäft. Für die Anwender wird es zunächst mal günstiger. Man muss bloß aufpassen, dass die Raspi-Truppe kein Quasi-Monopol etabliert bekommt. Dann würde es eklig werden.
Nun bleibt mal auf dem Teppich.
Mich ärgert viel mehr, das der TE seine Definitionen nicht mitpostet und auch keinen Schaltplan preisgibt. Da fühlste dich schon ein wenig wie beim 'Rate mal mit Dosenthal'.
Und dann kommt z.B.
Bruno M. schrieb im Beitrag #7716053:
Data ist R17!
mit Ausrufezeichen, als verstünde sich das von selber.
Mich ärgert viel mehr, das der TE seine Definitionen nicht mitpostet und
auch keinen Schaltplan preisgibt. Da fühlste dich schon ein wenig wie
beim 'Rate mal mit Dosenthal'.
Der TO hat deutlich geschrieben, daß er das SRAM am ATmega162 in der von Atmel vorgesehenen Methode dran hat und daß es damit funktioniert. Wer das nicht
versteht (und kein Datenblatt lesen kann), der sollte den Griffel
stillhalten. Im Datenblatt sind gleich auf der ersten Seite die Signale
AD0-7,A8-15, RD, WR und ALE angegeben, man muß nichts suchen. Jeder, der schon einmal ein SRAM im Multiplex angeschlossen hat, kennt das auch auswendig.
Liegt beim ATMega162 JTAG auch auf PortC dann ggf. das JTAG disable bit setzen das da nichts dazwischen funkt hatte das mal bei einem ATMega16
Normalerweise muss du beim Lesen nur die Adresse anlegen nach dem letzen Pegelwechsel an den Adressleitungen liegen die Daten nach 12, 15 oder 20nSek (je nach deinem SRAM-Typ) automatisch an, da kannst du dir einen weiteren Takt sparen. WE legst du vorher auf high und CE und OE vorher auf low.
