aus Interesse beschäftige ich mich mit einem "A3V64S40GTP"-SDRAM-Chip, den ich auf einer Platine eines alten Tintenstrahldruckers entdeckt habe. ich habe gelesen, dass für den Betrieb von SDRAM aufgrund der hohen Frequenzen und Timings in der Regel ein Mikrocontroller wie der Atmega328P nicht ausreicht, was natürlich logisch ist. Ich möchte den Chip daher langsamer takten. Im Datenblatt (https://zentel-europe.com/datasheets/A3V64S40GTP_v1.3_Zentel.pdf) habe ich dazu keine Informationen gefunden. Ich vermute, dass die Refresh-Zyklen eine Mindestgeschwindigkeit vorgeben. Das Datenblatt erwähnt, dass der Chip einen "self-refresh"-Modus unterstützt. Das bedeutet, dass der Chip in der Lage ist, den Speicherzustand eigenständig aufrechtzuerhalten, ohne auf eine externe Taktquelle angewiesen zu sein. Nach meinem Verständnis müssen alle 64 Millisekunden 4096 Refresh-Zyklen durchgeführt werden, entweder vom Chip selbst oder extern initiiert. In diesem Zeitrahmen sollte ausreichend Gelegenheit bestehen, um Daten zu lesen oder zu schreiben. Ist es also möglich, den Chip dauerhaft im self-refresh-Modus zu betreiben und ihn nur kurz zu aktivieren, um eine Aktion durchzuführen, bevor ich ihn wieder in den self-refresh-Modus versetze? Könnte dieser Chip auf diese Weise auch mit einem Mikrocontroller wie dem Atmega328P (per GPIO) betrieben werden?
Ist es also möglich, den
Chip dauerhaft im self-refresh-Modus zu betreiben und ihn nur kurz zu
aktivieren, um eine Aktion durchzuführen, bevor ich ihn wieder in den
self-refresh-Modus versetze? Könnte dieser Chip auf diese Weise auch mit
einem Mikrocontroller wie dem Atmega328P (per GPIO) betrieben werden?
Zaehl doch erstmal die Anzahl der "Pins" die du ansteuern muesstest. :)
12 Adressleitungen, 16 Datenleitungen, eine Handvoll Steuerleitungen. Die Datenleitungen könnte man, der Sinnhaftigkeit des Unterfangens angemessen, mit einem Schieberegister erledigen ...
dass für den Betrieb von SDRAM aufgrund der hohen Frequenzen und Timings
in der Regel ein Mikrocontroller wie der Atmega328P nicht ausreicht
Es ist eher so: aufgrund des fehlenden Businterfaces am Prozessor samt der im Prozessor integrierten Statemachine reicht die Rechenleistung des Prozessors nicht annähernd aus, um die Geschwindigkeitsvorteile so eines Chips auszunutzen.
Könnte dieser Chip auf diese Weise auch mit einem Mikrocontroller wie
dem Atmega328P (per GPIO) betrieben werden?
Man könnte ihn vemutlich auch mit DIP-Schaltern und Tastern ansteuern. Arg viel langsamer als der Ansatz mit Latches oder Schieberegistern zur Porterweiterung ist das dann auch nicht mehr.
Die Antwort auf deine Frage ist also "ja, aber diese Anwendung ist wegen der erreichbaren Geschwindigkeiten völlig sinnlos".
Das hatte ich schon erwartet. Dieses Projekt soll aber nicht dazu dienen, Höchstleistungen zu erbringen, sondern ist einfach als Versuch gedacht. Letztendlich kann ich dabei nur dazulernen. Es ging mir eher darum, ob ich irgendwelche Timing-Probleme übersehen habe, die mir nachher einen Strich durch die Rechnung machen. An eine Ansteuerung mit Schieberegistern hatte ich auch schon gedacht. Diese könnte man ja praktisch auch für die Adressleitungen nehmen.
Dann nimm wenigstens einen ATmega162 oder ATmega2560, die haben ein Memory-Interface (8Bit, 64kB). Ohne Banking wird das also nichts.
Mit dem ALE-Signal könnte man das RAS/CAS umschalten.
Dieses Projekt soll aber nicht dazu
dienen, Höchstleistungen zu erbringen, sondern ist einfach als Versuch
gedacht. Letztendlich kann ich dabei nur dazulernen.
Aha. Und was denn? Wie man einen RAM ansteuert, in den man weder Daten reinspeichern noch mit den rausgelesenen Daten was anfangen kann? Hab doch erstmal eine Anwendung die die 4Mx16 RAM annähernd braucht, aber sonst mit einem 8-Bit µC mit 32KB Flash auskommt.
Mir fällt keine ein.
Klar, an einem Z80 (der nochmal langsamer ist) haben wir auch DRAM betrieben. Aber eben 64KB, meist sogar weniger (weil teuer und 64KB der gesamte Adressraum war) und nicht 8MB. Und der Z80 hatte schon einen Refresh-Mechanismus implementiert. BTW, ein µC der ein Interface für den Anschluß von DRAM hat, hat das auch.
Aha. Und was denn? Wie man einen RAM ansteuert, in den man weder Daten
reinspeichern noch mit den rausgelesenen Daten was anfangen kann? Hab
doch erstmal eine Anwendung die die 4Mx16 RAM annähernd braucht,
aber sonst mit einem 8-Bit µC mit 32KB Flash auskommt.
Mir fällt keine ein.
Warum sollte ich keine Daten lesen und schreiben können? Das ist doch das Ziel dieses Versuchs und meine konkrete Fragestellung gewesen. Die Geschwindigkeit spielt für mich keine Rolle, ebenso ist die Anwendung zunächst nebensächlich. Es geht mir nicht um ein produktionstaugliches, nützliches Gerät, sondern um das Sammeln von Erfahrungen mithilfe der Hardware, die mir zur Verfügung steht. Deshalb möchte ich auch bewusst keinen Mikrocontroller mit SDRAM-Interface nutzen, selbst, wenn ich ihn bereits besäße. Ich habe diesen Speicher bereits und werde mich nicht darüber beschweren, dass er zu groß sei. Ich muss ihn ja nicht vollständig nutzen.
Kann ich das nicht auch so, ohne spezielle Hardware? Beim self-refresh
spielt die Speicherbank – soweit ich gelesen habe – keine Rolle.
Du kannst es versuchen, dann wirst Du sehen, wie weit Du kommst und ob Du Dich mit Deinen Fähigkeiten und dem dafür gewählten µC völlig verschätzt hast oder nicht.
Kann ich das nicht auch so, ohne spezielle Hardware? Beim self-refresh
spielt die Speicherbank – soweit ich gelesen habe – keine Rolle.
Du kannst es versuchen, dann wirst Du sehen, wie weit Du kommst und ob
Du Dich mit Deinen Fähigkeiten und dem dafür gewählten µC völlig
verschätzt hast oder nicht.
Das ist nicht sonderlich hilfreich und zudem arrogant.
Aber eben 64KB, meist sogar weniger (weil teuer und 64KB der
gesamte Adressraum war) und nicht 8MB.
Fenstertechnik bei Win 3.11? Himem.sys erlaubt Zugriff auf Extended Memory.
So ein Programm bräuchtest Du, um den Adressraum bis 1088 KByte anzusprechen. (von 1024 bis 1088 ist High Memory Area im Extended Memory.)
Quelle: 9783423503013 "MS DOS von A bis Z", Seite 157
ciao
gustav
Warum sollte ich keine Daten lesen und schreiben können? Das ist doch
das Ziel dieses Versuchs und meine konkrete Fragestellung gewesen.
Ganz einfach: das SDRAM befindet sich nicht im Adressraum des Microcontrollers. Das bedeutet, dass weder auf Variable zugegriffen noch Programmcode dort ausgeführt werden kann. Alles muss zunächst ins kostbare interne RAM umkopiert und bei Änderungen wieder zurückgeschrieben werden. Durch sehr umfangreiche und unschöne Funktionen und Makrogräber ließe sich das zwar etwas kapseln, wäre aber trotzdem nahezu nutzlos.
Das ist mir klar. Programmcode kann der Atmega328P aber ohnehin nicht aus dem RAM ausführen. Letztendlich geht es mir eher um die Frage, ob meine Überlegungen zum Timing funktionieren. Offenbar scheint das ja der Fall zu sein. Ob das Ganze sinnvoll/praktisch ist, interessiert mich nicht besonders.
Fenstertechnik bei Win 3.11? Himem.sys erlaubt Zugriff auf Extended
Memory.
Es ging um Z80, nicht um 80286. /Der/ kann sogar 24 MB ansteuern; "himem.sys" ist nur im "real mode" nötig, Windows 3.11 aber nutzte den "protected mode" und konnte daher den Speicher auch ohne solche Krücken nutzen.
Windows 3.11 aber nutzte den
"protected mode" und konnte daher den Speicher auch ohne solche Krücken
nutzen.
Bist Du Dir da sicher?
Klar, Win ME konnte den Real Mode nicht mehr.(Nur die amerikanische Version konnte das noch).
Windows 3.11 war doch die als klassisch bekannt gewordene grafische Betriebssystemerweiterung für DOS.
Also ich musste bei Win 3.11 erst DOS vorinstallieren und dann
in config.sys und autoexec.bat die "Verrenkungen" zur Speicheransprache einstellen, sonst lief Win 3.11 nicht.
Sogar Windows 95 hatte noch DOS drauf, obwohl es das garnicht mehr benötigte.
Aber es ging ja um die Adressierungsfrage hier.
Das wurde im Post von @Andreas S. oben schon gesagt.
Alles muss zunächst ins
kostbare interne RAM umkopiert und bei Änderungen wieder
zurückgeschrieben werden. Durch sehr umfangreiche und unschöne
Funktionen und Makrogräber ließe sich das zwar etwas kapseln, wäre aber
trotzdem nahezu nutzlos.
Aha. Und was denn? Wie man einen RAM ansteuert, in den man weder Daten
reinspeichern noch mit den rausgelesenen Daten was anfangen kann? Hab
doch erstmal eine Anwendung die die 4Mx16 RAM annähernd braucht,
aber sonst mit einem 8-Bit µC mit 32KB Flash auskommt.
Mir fällt keine ein.
Warum sollte ich keine Daten lesen und schreiben können? Das ist doch
das Ziel dieses Versuchs und meine konkrete Fragestellung gewesen.
Darum geht es nicht. Die Daten die du speicherst müssen ja irgendwoher kommen. Und mit den Daten die du liest mußt du irgendwas anfangen. Ein RAM ist ja kein Selbstzweck. Ein DRAM an einen µC zu knüppern und nachher mit Nullen (oder meinetwegen generierten PRNG Sequenzen) zu füllen ist nur eine andere Art von Masturbation.
Geschwindigkeit spielt für mich keine Rolle, ebenso ist die Anwendung
zunächst nebensächlich.
Ja, klingt ganz danach.
Aber wenn es dir um das Experiment geht, warum machst du es dann nicht einfach? Überleg dir lieber, wie du die Funktion deines RAM testest. Moderne DRAM halten die Daten auch ohne Refresh ein paar Sekunden. Das ist für den µC eine halbe Ewigkeit.
Aber wenn es dir um das Experiment geht, warum machst du es dann nicht
einfach? Überleg dir lieber, wie du die Funktion deines RAM testest.
Moderne DRAM halten die Daten auch ohne Refresh ein paar Sekunden. Das
ist für den µC eine halbe Ewigkeit.
Das ist der Plan. Allerdings brauche ich davor noch das erforderliche Equipment (z.B Breakout-Board). Bevor ich das bestelle, möchte ich schon wissen, ob meine Idee überhaupt funktionieren könnte. Insofern ist meine Frage beantwortet. Vielen Dank.
Geschwindigkeit spielt für mich keine Rolle, ebenso ist die Anwendung
zunächst nebensächlich.
Ja, klingt ganz danach.
Aber wenn es dir um das Experiment geht, warum machst du es dann nicht
einfach? Überleg dir lieber, wie du die Funktion deines RAM testest.
Moderne DRAM halten die Daten auch ohne Refresh ein paar Sekunden. Das
ist für den µC eine halbe Ewigkeit.
Er koennte auch vorher berechnen, wie lang so ein Test dauern wuerde.
Ein RAM-Test war damals meine erste Uebung auf einem 90S8515 auf einem
STK200. (Natuerlich mit gestecktem RAM :)
So mancher Meggabitttschip ist uebrigens in einem Digitalecho gelandet.
Aber wenn es dir um das Experiment geht, warum machst du es dann nicht
einfach? Überleg dir lieber, wie du die Funktion deines RAM testest.
Moderne DRAM halten die Daten auch ohne Refresh ein paar Sekunden. Das
ist für den µC eine halbe Ewigkeit.
Weil das alles Elektronik-Eunuchen sind. Drüber reden, fragen, diskutieren. Aber gemacht wird es nie.
Wer erstmal drüber redet was er machen will macht es nie. Man sieht die Macher daran dass die einfach anfangen und sich dann bei konkreten Fragen hier melden.
So mancher Meggabitttschip ist uebrigens in einem Digitalecho gelandet.
Jepp. Das wäre eine konkrete Anwendung gewesen, die ich hätte gelten lassen. Auch wenn es fraglich ist, ob der Mega328 das geschafft hätte und die analoge Ein- und Ausgabe wohl nur mit geriatrischer Elektronik (ADC/DAC mit Parallelschnittstelle) zu machen wäre. Bei einem 4Mx16 RAM könnte man ja sogar CD-Qualität erreichen ;)
Wer erstmal drüber redet was er machen will macht es nie. Man sieht die
Macher daran dass die einfach anfangen und sich dann bei konkreten
Fragen hier melden.
Genau.
Mindestens 1/2 Stunde brauch ich für mein Eprom zu programmieren.
Adresse anwählen
Daten eingeben
Strobe 50 ms (per vorher eingerichtetem Monoflop.)
Adresse inkrementieren
und nächste Daten holen...
Und dann ist das Programm für Startadresse Adressse 0001 und nicht 0000 gedacht und läuft nicht.
Eprom in UV-Löschgerät
Alles von vorne! Aber diesmal richtig.
So mancher Meggabitttschip ist uebrigens in einem Digitalecho gelandet.
Jepp. Das wäre eine konkrete Anwendung gewesen, die ich hätte gelten
lassen. Auch wenn es fraglich ist, ob der Mega328 das geschafft hätte
und die analoge Ein- und Ausgabe wohl nur mit geriatrischer Elektronik
(ADC/DAC mit Parallelschnittstelle) zu machen wäre. Bei einem 4Mx16 RAM
könnte man ja sogar CD-Qualität erreichen ;)
Das sollte schon gehen. Mann hat ja ca. 25 µs Zeit.
Andere Meggabitttschips dienten im PIP eines Fernsehers.
Da ging es schon hurtiger zu.
Mein erster EigenbauEPROMmer fuer die guten™ 2708 hatte immerhin
einen richtigen Adresszaehler, 9 Sensortasten fuer die Daten/Clear,
und einen echten Mikrotaster fuer "Brennen/Adressinkrement".
Mit dem habe ich genau 4 EPROMs gebrannt. Dann wurde er nicht mehr
gebraucht. :)
Programmiert wurde uebrigens 1024mal die selbe Adresse am Stueck.
Mit 1 ms Pulsen...
Es erforderte zwingend einen 386, darunter lief gar nichts.
(Nur die amerikanische Version konnte das noch).
Nein, ganz sicher nicht (s.o.)
Windows 3.11 war doch die als klassisch bekannt gewordene grafische
Betriebssystemerweiterung für DOS.
Ja.
Also ich musste bei Win 3.11 erst DOS vorinstallieren und dann
in config.sys und autoexec.bat die "Verrenkungen" zur Speicheransprache
einstellen, sonst lief Win 3.11 nicht.
Schon richtig, aber bereits Windows 3.0 konnte den "protected mode" des 286 und auch den des 386 nutzen, und in lezterem Falle sogar ein DOS-Programm "im Hintergrund" im präemptiven Multitasking zur Windows-Oberfläche laufen lassen.
Den Protected Mode kannten sogar schon ältere Windows-Versionen vor 3.0.
Das himem.sys-Geblubber war nur für den DOS-Unterbau nötig, bis der "protected mode" aktiv wurde. Danach konnte Windows erheblich mehr (litt aber natürlich massiv unter der Segmentitis, die auch auf dem 386 weiterbestand, denn was da lief, war weiterhin 16-Bit-Code.
Das hatte ich schon erwartet. Dieses Projekt soll aber nicht dazu
dienen, Höchstleistungen zu erbringen, sondern ist einfach als Versuch
gedacht. Letztendlich kann ich dabei nur dazulernen. Es ging mir eher
darum, ob ich irgendwelche Timing-Probleme übersehen habe, die mir
nachher einen Strich durch die Rechnung machen. An eine Ansteuerung mit
Schieberegistern hatte ich auch schon gedacht. Diese könnte man ja
praktisch auch für die Adressleitungen nehmen.
Würde ich nicht machen. Nimm einen AVR mit ausreichend Pins, wenn's sein muss einen Arduino MEGA2560. Denn so ein S(!)DRAM braucht auch eine Mindsttaktfrequenz. Wie weit man da runter kommt weiß ich nicht, wenn du Glück hast 100kHz.
Die etwas weniger wahninnige Art wäre ein old school DRAM, der braucht weniger Pins und auch keinen Takt. Hat schon mal einer gemacht.
Durch sehr umfangreiche und unschöne
Funktionen und Makrogräber ließe sich das zwar etwas kapseln, wäre aber
trotzdem nahezu nutzlos.
Unsinn! So ein riesiger RAM kann man als schnellen Massenspeicher nutzen! Natürlich nicht um direkt mit den Daten zu arbeiten, wohl aber um sie paketweise zu bearbeiten. Oder einen Mega-FIFO draus machen. "Nahezu nutzlos" ist die andere Seite der Übertreibung!
So wie es aussieht, darf man bei SDRAM den Takt auch anhalten (CKE =
low). Im Datenblatt
CKE = LOW ist NICHT das Gleiche wie den Takt selber anhalten (CLK)!
Den der Takt treibt ja sämtliche State Machines, Zähler etc. im SDRAM!
Bei echtem, old school SDRAM kann man Glück haben, daß der auch sehr langsamen Takt deutlich unter 1 MHz verträgt, weil dort keine PLLs oder ähnliches drin steckt, was dauerhaften, konstanten, eher hochfrequenten Takt braucht. Also ein einfaches, synchrones Schaltwerk.
Zum CKE-Pin steht im Datenblatt folgendes:
"CKE is synchronous except after the device enters self refresh mode, where
CKE becomes asynchronous until after exiting the same mode. The input buffers, including CLK, are disabled during self refresh mode, providing low standby power"
Ich lese daraus, dass das Clock-Signal währenddessen tatsächlich irrelevant ist. Im englischen Wikipedia-Artikel zu SDRAM steht Ähnliches:
"Finally, if CKE is lowered at the same time as an auto-refresh command is sent to the SDRAM, the SDRAM enters self-refresh mode. This is like power down, but the SDRAM uses an on-chip timer to generate internal refresh cycles as necessary. The clock may be stopped during this time." (https://en.wikipedia.org/wiki/Synchronous_dynamic_random-access_memory#Low_power_modes)
Vielleicht erzeugt der Chip das Taktsignal selbst, wenn dieser Modus aktiv ist? Anders könnte ich mir das nicht erklären. Meine ganzes Vorhaben baute ja darauf auf, den Chip die gesamte Zeit im self-refresh Modus zu belassen und ihn nur kurz zu aktivieren, dann die Daten lesen/schreiben und sofort wieder den self-refresh Modus zu aktivieren, sodass ich mich gar nicht um den Refresh kümmern muss. So hätte ich immer ein kurzes Zeitfenster, in dem ich auch mit einem sehr langsamen Takt arbeiten kann.
Der verlinkte Beitrag ist sehr interessant. Obwohl es sich um eine andere Technologie handelt, sind gewisse Erkenntnisse bestimmt übertragbar, wenn ich mich an die Umsetzung mache. Ich werde darauf definitiv zurückgreifen.
Solange man kein Doom darauf spielen kann, ist das irrelevant.
Da seh' ich eigentlich nichts, was dem im Weg stehen wuerde. Zumindest mittels Bildausgabe via aa/cacalib oder sowas.
Ist halt dein Pech, wenn du zu frueh an Altersschwaeche stirbst, um da ein Level fertig spielen zu koennen...
Hey, ich finde das ein recht interessantes Projekt!
Ja, das Vorhaben mag zunächst nicht sehr sinnvoll erscheinen, aber interessant wäre es schon mal mit einen 8 Bit AVR mit 32 KB Flash so einen MBit Chip anzusprechen. Also, ich bin auf Deiner Seite, schon alleine deswegen, weil Du daran Interesse und Spaß hast!
Bravo, nur so wächst man! Viel Erfolg und bitte halte uns hier auf dem Laufenden
P.S. Und BITTE#2: Lass Dich von den "Schlaumeiern" und "Miese-Petern" nicht entmutigen! Ziehe es durch!
Vor Jahren hab ich mal mit Kameras am ATMega32 experimentiert, mehrere Bilder sollten im RAM abgelegt werden und verarbeitet werden.
Hab dem Mega32 n ollen EDO-RAM-Riegel verpasst und gut war, 1MB.
Vor Jahren hab ich mal mit Kameras am ATMega32 experimentiert, mehrere
Bilder sollten im RAM abgelegt werden und verarbeitet werden.
Hab dem Mega32 n ollen EDO-RAM-Riegel verpasst und gut war, 1MB.
Also warum nicht, bleib dran und mach einfach :)
Weil es für 1 MB viel passenderen SRAM gibt.
Abgesehen davon dass es noch viel viel passender wäre, serielle Flash oder direkt SD-Karten zu verwenden, wenn man die explizite Forderung nach RAM fallen lassen würde.
Also quasi jede andere Speichermöglichkeit wäre sinnvoller gewesen, abgesehen von Tesa-ROM.
Hab dem Mega32 n ollen EDO-RAM-Riegel verpasst und gut war, 1MB.
Das ist ja auch viel trivialer anzusteuern als SDRAM. Das "S" steht hier für "synchronous", d.h. alle Datentransfers finden synchron zu einem Referenztakt statt. Die alten DRAMs, die man so in "unserer Jugendzeit" vorfand, die wurden asynchron, d.h. ohne Referenztakt angesteuert, und so etwas wie EDO oder FPM waren nur leichte Variationen davon.
SDRAM aber ist 'ne komplett andere Kiste.
Wenn man einfach und schnell viel Speicher an einen µC anschließen möchte, ist PSRAM etwas, was man sich ansehen sollte. Das wird i.d.R. über eine QSPI-Schnittstelle angesteuert, wenig Verdrahtungsaufwand, und in noch handhabbaren Gehäusen untergebracht (z.B. SO-8).
So etwas findet sich z.B. auf den besseren ESP32-Modulen.
Das ist ja alles Richtig und es sind gute Hinweise. Aber wollte der TO nicht mal aus „Spaß an der Freud‘“ einen DRAM, den er wo anders auslötete, mit einem AVR, der kein explizites externes Speicherinterface anbietet ansprechen? Rein, um mal zu sehen ob das geht?
Ihr liefert hier Lösungen für ein Problem, das ja gar nicht existiert. Einerseits lobenswert, andererseits aber auch an der ursprünglichen Fragestellung- der Intention vorbei.
Ich entwickle derzeit zum Beispiel eine Spielkonsole auf Basis eines Arm Cortex M4 + EVE (ft810) als Displaylösung. Ganz bewusst will ich mit dem internen SRAM (192 kiB) auskommen, weil ich bezüglich der Softwarearchitektur mich hier herausfordern will. Dennoch bekomme ich IMMER als ersten Rat: Nimm doch ne RasPi mit Retro-Pi! Warum versteht niemand meine Herausforderung? den Hintergrund, WARUM man sich auf diese Weise selbst herausfordert?
