Heyho. Bekomme Mein DRAM nicht ans laufen. Quellcode oben. Habe zwar den Refresh noch nicht implementiert, aber das Byte wird direkt nach dem Schreiben wieder aus dem RAM gelesen. Denke dieser kurze Zeitraum sollte ohne Refresh klappen. Wenn ich ein Zeichen zum AVR schicke, bekomme ich irgndein vermurkstes Zeichen zurück. Meist ist es hex FF oder hex 247. Ich kann jedoch nach langer Suche immernoch keinen Fehler finden, vielleicht hat ja einer von euch noch eine Idee. Danke schonmal im Vorraus
Angeschlossen hbe ich ein SIMM RAM von alten Computern, und die RS232 Verbindung klappt ohne Probleme. Sei nur so dazugesagt.
Oh, die 247 sind wohl nur durch Wackelkontakt zustande gekommen, jetz krieg ich immer FF hex zurück :/
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.
a) Wuas? Read-modify-write? Und wo leg ich Daten auf den AVR Port? Der Port liegt doch High-Z (DDR=0, PORT=0) b) Ichlade bei CAS und bei RAS eine Adresse.. Und zwar jeweils die Gleiche, kann man später ja noch ändern.. c) Selbst wenn ich einen zyklischen Refresh von 1mS einbauen würde, dann würde er mit sehr geringer Wahrscheinlichkeit genau zwischen Write und Read. Da ist doch kaum Zeit zwischen Schreiben und Lesen. die paar µS lassen den DRAM schon nicht seine Daten verlieren..
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.
Oha. In deinem 2MB DRAM am AVR siehts so aus: http://www.mikrocontroller.net/attachment.php/121457/audior.asm da ist auch WE mittendrin. Was hats eigentlich damit auf sich, dass du Pin 28 und 29 Auf High gelegt hast. Sind doch Parity Eingänge. Ich probier mal..
Mein Ausgabeteil sieht jetzt so aus:
1 | RAM_putbyte:
|
2 | |
3 | ser temp ;Porta als Ausgang |
4 | out DDRA, temp |
5 | |
6 | cbi Portd, RAM_WE ;WE low |
7 | nop
|
8 | |
9 | out Portc, RAM_Adress ;RAM Adrese (8-Bit rausgeben) |
10 | nop
|
11 | |
12 | cbi Portd, RAM_RAS ;RAS low |
13 | nop
|
14 | cbi Portd, RAM_CAS ;CAS low |
15 | nop
|
16 | |
17 | out Porta, RAM_Data ;RAM Daten anlegen |
18 | nop
|
19 | |
20 | |
21 | sbi Portd, RAM_CAS ;schließlich CAS |
22 | nop
|
23 | sbi Portd, RAM_RAS ;und RAS wieder high |
24 | nop
|
25 | |
26 | sbi Portd, RAM_WE ;und wieder high |
27 | |
28 | ret
|
leider ohne Besserung. Habe deine Anmerkungen dort eingebaut, ist das DRAM vielleicht schon kaputt? PS: Wie heißen denn die Dinger bei Reichelt? Hab mich totgesucht.
>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.
Ok. Bin grad Zuhause, und hab mir deinen Code mal angeguckt. Anschließend meine Routine etwas umgestrickt und Siehe Da. Hehe Ich krieg aufm Terminal das Zeichen zurück was ich sende. Vielen Dank funktionierender Code im Anhang
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.
>>Mal ne Frage, wozu das Ganze?
Hmm gute frage. Ich geh mal eben mein DRAM im PC austauschen... Habe
dann allerdings nen Problem mit meinem Kredit bei der Bank.
Hey, Habe jetzt Probleme mit meinem Code. Leider sind die so unreproduzierbar, dass ich grad am verzweifeln bin. Gestern abend die ganze zeit mit dem terminal chars geschickt, und auch die richtigen zurückbekommen, aufeinmal ging es nich mehr gestern. Direkt erstmal genervt ins Bett gegangen. Stehe heute morgen auf, probier rum, klappt ja wieder (Kratz?!). Mache ein bisschen am quelltext rum (Timer aktiviert,d er einen pin togglen lässt), schon schickt das RAM mir nur noch 0xFF zurück?! Ich tu die sicherungskopie vom vorherigen Code wieder rein - immernoch ! (Genau wie gestern). Total komisch. UART funktioniert wunderbar, Controller läuft einwandfrei, hab schon den Controller getauscht - nix zu machen. Jemand einen Tipp? Könnte das eventuell am RAM liegen? ist 30pin SIMM etwa nur 3,3V RAM? hust ;) Danke schonmal
Hast du evtl unbenutze Pins vom Ram offen gelassen ? Vielleicht kommt da irgendwas ungewollt ins schwingen oder "lädt" sich auf...
lol, oh nein. Das mit dem "Refresh brauch ich ja nich, weil sofortiges Lesen nach Schreiben" nehm ich zurück... Testweise auf 2400 Baud umgestellt und bei der Senderoutine wartet er ja auf UDRE... Tja dummdumm. Währenddessen leert sich mein DRAM mal eben wieder. Sorry vielmals, der Code oben klappt natürlich.
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?
Mist, jetz weiß ich auch, wofür manche Leute nops vor zB einem in xxx,yyy machen. Dauert wohl etwas länger als 1/14745600 Sekunde bis das DRAM den Port vom uC gezogen hat. besser gehts, wenn man 2 nops vor dem in xxx,yyy macht.
>>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 ;-)
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.