Forum: Mikrocontroller und Digitale Elektronik DRAM Problem

a) Du bist auf dem besten Weg den DRAM oder den AVR zu grillen.
Du macht einen Read-modify write, und legst gleichzeitig die Daten vom
AVR auf den Port
b) Ein DRAM hat mehr als 256Bytes, du musst also sowohl bei CAS als
auch bei RAS eine Adresse laden
c) das ist ein DRAM und kein SRAM, der braucht nen Refresh.

cbi     Portd, RAM_RAS              ;RAS low
    cbi     Portd, RAM_CAS              ;CAS low -> Daten vom DRAM
weren ausgegeben, da OE\ auf Low

    out     Porta, RAM_Data             ;RAM Daten anlegen -> Du gibst
auch Daten aus
    nop

    cbi     Portd, RAM_WE               ;WE low
    nop
    sbi     Portd, RAM_WE               ;und wieder high


Du musst WE vor CAS auf Low bringen, und erst nach CAS wieder auf
high.

SIMM Sockel: Reichelt oder alte Mainboards.

Bau mal beim auf Low setzen von RAS und CAS dazwischen noch ein nop
ein.
Da wo du ein nop hast, setz noch eins. Eventuell ein Timing Problem.

>In deinem 2MB DRAM am AVR siehts so aus:
>da ist auch WE mittendrin.

Ja, aber:
Ich verwende OE und halte das DRAM Ausgang so High-Z

Verwende am besten den neueren Code von mir, der alte hatte teilweise
ein paar Fehler.
Der Code ist dann auch in Assembler und speziell an SIMM Module
angepasst.

Reichelt: SSD 30G
Oder gib einfach mal Simm in die Suche ein...

DRAM hält schon einiges aus, so schnell geht der nicht kaputt.

Ob ich Parity auf High lege, oder so wie du auf Low ist an sich egal.
Ich habe es nur deshalb auf High gelegt, damit es deaktiviert wird.

Mal ne Frage, wozu das Ganze? Mit Softwarerefresh, kille ich doch
jegliche Performance und ohne geht gar nix. Außerdem gibt's doch
heutzutage andere viel einfacher zu benutzende Speicher. Mit einem
512KB SRAM und Bankswitching hat man doch Speicher satt.

>Mal ne Frage, wozu das Ganze?
Um richtig viel Speicher zu bekommen, wie z.B. bei einem mp3 Player der
die komplette Datei in den RAM läd, und dann die Festplatte in den
Standby schickt um Strom zu sparen.
Bei 32MByte wird es bei SRAM teuer, 32MB DRAM Module aus PCs liegen bei
mir dagegen genügend rum...

>Mit Softwarerefresh, kille ich doch jegliche Performance
Nicht unbedingt: Wenn man es per Interrupt macht, und den INterrupt
durch einen anderen Interrupt unterbrechbar macht, gehen nur wenige %
Leistung dafür drauf. Mit ein paar Tricks geht der Refresh sogar auch
per Timer mit Port Toggle, also im Hintergrund.

Hast du evtl unbenutze Pins vom Ram offen gelassen ?
Vielleicht kommt da irgendwas ungewollt ins schwingen oder "lädt"
sich auf...

30pin SIMMs sind immer 5V-DRAMS, die Sorge ist also unbegründet. Kann es
sein, daß Dein Refresh-Puls nicht oft und lange genug kommt?

>>Dauert wohl etwas länger als 1/14745600 Sekunde bis das DRAM
>>den Port vom uC gezogen hat....

...besonders, wenn´s kalt ist... Wenn Du mit solch knappen Timings
aufwartest, mußt Du Dich nicht wundern, wenn Dein DRAM so lalülala
reagiert ;-)

Ich doch nicht, aber Dein DRAM :-)))))

Hallo,

vielen Dank fuer den guten Code. Hat bei mir fast auf anhieb
funktioniert: Es gab ein kleines Problem beim Lesen (nops sind immer
eine gute Idee, wenn man keinen LA hat). Aber es gab ein anderes
kleines Problem:

RAM_getbyte:
[...]
ldi     Temp1, (1<<RAM_CAS)|(1<<RAM_RAS)
out     Portd, Temp1                ; Alles wieder HIGH setzen

Ich glaub, es sollte besser heissen:
ldi     Temp1, (1<<RAM_CAS)|(1<<RAM_WE)|(1<<RAM_RAS)
wie auch in RAM_putbyte, denn das fallende WE koennte als
READ-WRITE-cycle gedeutet werden. Gerade wenn die Signale nicht so
sauber sind (fuer den uC schon HIGH, fuer den RAM aber nicht ..) werden
beim Lesen die (falschen) Daten zurueckgeschrieben und so koennen beim
Lesen die Daten verfaelscht werden.

Schoene Gruesse