Hallo, ich habe mal eine Frage zu SD-Ram. Ich habe einen SD-Ram gefunden, der u.a. folgende Daten hat: 133MHz, 3.3V, 8Mx16 So wie ich das vorher gedacht habe, ist ein SD-Ram pingelig, wie das mit den Zeiten aussieht. Bei 133MHz hätte die Taktfrequenz doch eine Periodendauer von 7,5 ns. Das würde es ja recht uninteressant für µCs machen, die 8-32MHz internen Takt haben. Nun hab ich mir das Datenblatt mal angeguckt und gesehen, dass tcc (Clock circle time) von 5 bis 1000 (nehme mal an ns) geht. Das hieße doch aber, dass eine Taktfrequenz von 1MHz bis 200MHz möglich wäre, oder? Man könnte ihn also auch mit einem 32MHz getakteten µC ansteuern? Ich habe mir schon ein paar Erklärungen zu SD-Ram durchgelesen, aber habe immernoch nicht ganz verstanden, warum diese Taktfrequenz so wichtig ist. Der Takt läuft doch über jeden internen Baustein, der einen Takt braucht, also frag ich mich, wie der Ram "merkt" dass der Takt zu langsam ist. Zu schnell ist mir ja klar, wenn die Transistoren nicht schnell genug durchschalten können. Wäre um eine recht simple Erklärung evtl. mit Analogie (gibt hier glaube welche, die das sehr gerne machen) sehr dankbar.
evtl. funktionieren welche mit internem refresh. ansonsten ist SD-ram auch wegen der breiten daten- und adressbusse schon uninteressant.
dynamische RAM's müssen in gewissen Zeitabständen "refresht" werden, da der Zustand jedes Bits in einem Kondensator gespeichert ist. Ein Refresh ist ein internes Auslesen und Schreiben damit die Ladung im Kondensator erhalten bleibt. Ohne oder bei zu langsame Zuriff/Refreshzugriff ist die Zeitspanne zu groß und die in den Kondensatoren gespeicherte Ladung geht verloren (Leckströme) -> Daten weg! Sascha
achsooo.. Aber heißt dass dann, das dieser Baustein zum erhalten der Daten auch mit einem Megaherz auskommt? Sonst kann ich mir die 5-1000ns Clock circle time nicht erklären.
Ben _ (burning_silicon) schrieb: > ansonsten ist SD-ram auch wegen der breiten daten- und adressbusse schon > uninteressant Das hängt ganz vom Verwendungszweck ab. SDRAMs sind eben schnell, haben (für µC-Verhältnisse) viel Speicherkapazität und sind billig bis kostenlos zu bekommen. Wegen der breiten Adress- und Datenbusse verbraucht man natürlich viele Portpins, kann dafür aber bei mäßigen Übertragungs-Takten ordentliche Datenmengen "schaufeln". Und ich denke mal, dass der Hersteller halt garantiert, dass der SDRAM bis herab zu 1MHz funktioniert. Darunter funktioniert er vermutlich auch noch problemlos (sofern man die Refresh-Zeiten einhält), aber das hat der Hersteller halt nicht mehr getestet.
Ja, ich werd das Ding einfach mal bestellen (kostet ja keine 3€) und testen. Wenn ich also eine gewisse Zeit nichts mit dem Ram machen will, reicht der Takt aus, um die Daten zu behalten. Ich hatte bloß gedacht, dass diese 133MHz zwingend notwendig sind. Naja, jedenfalls vielen Dank für die Erklärung. Habe es nun endlich (vom Prinzip her) gerafft.
> Wenn ich also eine gewisse Zeit nichts mit dem Ram machen will, reicht > der Takt aus, um die Daten zu behalten. Sowiit ich weis nicht bei jedem dynamischen RAM, sondnern nur bei self-refreshing Typen. Das sollte im Datenblatt stehen. Das Problem mit zu geringen Taktraten kann sein, dass du den RAM nicht schnell genug refreshen kannst.
Hier ist mal das Datenblatt: https://www.it-wns.de/data/datenblatt_0000163_1.pdf Darin steht, dass es einen "Auto & self refresh" hat, "64ms refresh period (4K cycle)" Auf Seite 11 sind verschiedene Zeiten angegeben. Das was mir allerdings noch ein bisschen sorgen macht, ist, dass die "Output data hold time" mit 2ns angegeben ist. Heißt das, dass beim Lesen vom Ram die High-Pegel am Datenausgang nur 2ns High sind und dann wieder auf Low gehen? Das wäre ja ziemlich schlecht.
ich schrieb: > Heißt das, dass beim Lesen vom Ram die High-Pegel > am Datenausgang nur 2ns High sind und dann wieder auf Low gehen? Im Datenblatt sollte ein Timingdiagramm zu finden sein, in dem Du die angegebene Zeit wiederfinden solltest. Wie man so ein Diagramm liest, musst Du spätestens jetzt lernen, wenn Du Dich ernsthaft mit der SDRAM-Ansteuerung beschäftigen willst.
SD-RAM ist ziemlich anspruchsvoll anzusteuern. Benedikt, der leider anscheinend hier nicht mehr aktiv ist, hat es mal geschafft, einen SDRAM an einen AVR zu hängen und damit eine Art "Grafikkarte" zu realisieren. Der Thread dazu ist lang und hier im Forum zu finden. Allerdings hat er selber, als wirklicher Kenner der Materie, diese Lösung im Laufe der Weiterentwicklung verworfen, da sie halt doch sehr kritisch ist. SD-RAM anzusteuern ist alles andere als simpel. Es empfiehlt sich, die Datenblätter sorgfältig zu lesen, tief durchzuatmen und dann zu überlegen, ob man sich nicht doch lieber herkömmlichen DRAM antut. Der ist schon aufwendig genug zu bedienen.
Rufus Τ. Firefly schrieb: > Im Datenblatt sollte ein Timingdiagramm zu finden sein, in dem Du die > angegebene Zeit wiederfinden solltest. Hab ich auch gedacht, war aber leider nicht dabei. Schön wäre es a la I²C Diagramm in Datenblättern für ICs mit dieser Ansteuerung. Jan schrieb: > Ich würd das so verstehen, dass weniger als 2ns nicht drinne sind. Das stimmt, ist ja auch bei Minimum angegeben-.- Ich sollte mich mal ruhig hinsetzen und das nicht wärend der Arbeit überfliegen. Sebastian schrieb: > Es empfiehlt sich, die > Datenblätter sorgfältig zu lesen, tief durchzuatmen und dann zu > überlegen, ob man sich nicht doch lieber herkömmlichen DRAM antut. Das mache ich. Allerdings bestell ich es erstmal mit, mache mir ein kleines Breakoutboard und teste mal. Schlimmer als "geht nicht" kanns ja nicht werden.
was soll bei der ganzen Sache überhaupt rauskommen, nicht das dann dein µC nur noch mit dem ansprechen des RAMs beschäftigt ist. Überlege dir vorher mal grob wieviele Befehle du im µC brauchst um einen Zugriff zu realisieren und ob dann die geforderte Taktrate noch übrigbleibt. Nur mal so: 2 Byte Row-Adresse ausgeben; RAS; 2 Byte Col-Adresse ausgeben; CAS; 1 o. 2 Byte Daten einlesen; nebenher Takt ausgeben Sascha
tuts nicht auch eine sd karte? dürfte etwa die gleiche zugriffsgeschwindigkeit bieten wie der ram chip. was das ganze schon ein bisschen wiedersinnig erscheinen lässt. mit einem fpga könnte man einen dram ansteueren, die haben auch genug pins. oder ein cpld für 1-2 euro als zwischenglied zwischen ram und avr einsetzten
Ich hatte vor, eine Art einfachen Logic-Analyzer zu machen, bzw 8 bit Digital + 1 8bit parallelen ADC. Dann kann ich per Counter die Adresse hochzählen, die Eingänge können gleich parallel (über Levelshift) angeschlossen werden und das theoretisch bis zu 100MHz. Ein µC wäre dann nötig, um zu Triggern und später die Daten zu lesen. Deshalb ist auch eine SD-Karte ungünstig, weil man dann erst die Daten erfassen müsste und seriell an die Karte zu schicken. Das ganze dient auch eher zum lernen, damit umzugehen. Als Beispiel einen 100MHz Quartz, mit (per µC) einstellbaren Teiler dahinter um dann beim erkannten Bitmuster den Quarz durchzuschalten um dann anzufangen zu Zählen. Das soetwas am besten mit nem FPGA geht, kann ich mir denken, nur hab ich erstmal vor, dden SD-Ram einigermaßen zu verstehen. Und weil er halt so billig ist, dachte ich mir, probieren schadet nicht. Dazu nebenbei noch eine Frage. Wo liegt (an Beispielanwendungen) denn der Unterschied, wann man einen dsPIC/PIC32 nehmen sollte, oder einen FPGA, bzw wann einen ARM? Ich kann das nicht ganz auflösen. FPGA mit 100MHz als LA ist ja logischer als mit einem dsPIC, wohingegen ein PIC32 bei 80MHz 1,56MIPS/MHz hat.
Im verlinkten Datenblatt sind doch die Timingdiagramme drin, kommen nach den Befehlstabellen. Alles da, eigentlich. Sind schließlich nicht umsonst 66 Seiten. Grob gesagt, ein FPGA ist vor allem aufgrund seiner Parallelität so schnell. Im Gegensatz zum Mikrocontroller wird kein sequentielles Programm abgearbeitet, sondern aus der Hardwarebeschreibung eine Struktur aus logischen Verknüpfungen erstellt. Diese sind - abhängig vom externen Takt bei einem synchronen Design - praktisch gleichzeitig wirksam. Dafür ist der Aufwand für den Entwurf einer Logik im FPGA doch etwas höher, als ein Mikrocontrollerprogramm zu schreiben. Für Anwendungen wie einen Logikanalysator ist ein FPGA prädestiniert, da gibt es auch Projekte. Der Algorithmus ist überschaubar, und Geschwindigkeit ist alles. Bei den Mikros liegt der Unterschied zwischen großem PIC und ARM (7, vermute ich) zunächst einmal darin, daß der ARM durch seine echte 32-Bit Architektur rechenstärker ist. Ein Logikanalysator hat davon aber keinen großen Vorteil. Große ARM-Mikrocontroller haben jedoch ein SDRAM-Speicherinterface eingebaut. Allerdings nur wirklich große, hauptsächlich die linuxtauglichen (z.B. LPC24xx und größer) Trotz allem: Ein Logikanalysator mit SDRAM ist ehrgeizig. Natürlich gibt es so etwas wie eine "Burst Write" Funktion (siehe Datenblatt). Aber bis man so etwas richtig benutzen kann, ist eine Menge Einarbeitung fällig. Mal anders gefragt: Wie groß muß denn die Speichertiefe sein? Ja, SRAM ist teuer. Aber eine Speicherbank aus schnellen Cache-SRAMS bedient sich ungleich leichter (12 ns Zugriffszeit sind durchaus möglich), und eventuell läßt sich soviel an Logik sparen, daß statt einem teuren FPGA ein billiger CPLD genügt.
Sebastian schrieb: > Im verlinkten Datenblatt sind doch die Timingdiagramme drin, kommen nach > den Befehlstabellen. Alles da, eigentlich. Sind schließlich nicht > umsonst 66 Seiten. Welches Datenblatt meinst du?? Das was ich hier ich schrieb: > Hier ist mal das Datenblatt: > https://www.it-wns.de/data/datenblatt_0000163_1.pdf > > Darin steht, dass es einen "Auto & self refresh" hat, "64ms refresh > period (4K cycle)" gepostet habe, hat bei mir 14 Seiten. Und auf der letzten Seite steht unten auch "14 of 14". Also wenns abgeschnitten wäre, müsste da ja "of 66" stehen. Welches hast du denn? Sebastian schrieb: > Wie groß muß denn die Speichertiefe sein? Naja am besten so tief wie möglich. Ich hab ansich einen gekaufen LogicAnalyzer aber ich würde gern mal gucken, ob man dass auch "einfach" hinbekommt. Also per simpler PC-Software über USB an einen PIC. Dann über 3 Quarze (80MHz für 80&40&20&10 MHz, 60MHz für 60&30 MHz und einen mit 50MHz) die Samplerate einstellen (also von 10-80MHz alles bis auf 70MHz, könnte man aber über 4. Quarz erzeugen). Ein oder vlt 2 Counter (Row und Column) zählen in dem Takt die Adresse hoch und die Logikeingänge gehen über Levelshift direkt an den Ram. Also braucht der µC quasi nur ein paar Statusbits setzen und sich nicht um Daten oder Adressen kümmern. Dann wird der Speicher vollgehauen und wenn er voll ist (oder über ein Abruch-Taster oder bei einem Speziellen Bitmuster), wird alles gestoppt. Anschließend liest der PIC das Ram aus (der PIC erzeugt dann quasi den Takt für die Counter, hier wär die Frage, ob es mit ~2MHz geht) und schickt die per USB an den PC. Soweit jedenfalls erstmal mein Plan. Es ist ansich ein simpler Aufbau und ansich recht günstig. PIC 4€, Levelshifter 4€, RAM 3€, Counter vlt. 5€, Quarze und Teiler ca. 3€. Zusammen dann kleiner 20€. Sowas wie I²C Decodierung ist erstmal nciht geplant und wenn, dann wäre es nur programmieraufwand an der PC-Software. Zur Tiefe. Bei 8Mx16 bit, wären es rechnerisch so: @80MHz -> 0,1048576 Sekunden @60MHz -> 0,1398101 Sekunden @50MHZ -> 0,1677722 Sekunden @40MHz -> 0,2097152 Sekunden @30MHZ -> 0,2796203 Sekunden @20MHz -> 0,4194304 Sekunden @10MHZ -> 0,8388608 Sekunden Aufnahmedauer. Je größer der Ram, desto länger kann man aufnehmen. Ich muss nurnoch gucken, welche Counter schnell genug sind, aber da lässt sich bestimmt was finden. Danach hab ich aber erstmal noch nich geguckt. Und diese Quarz-Teiler-Kombi ist auch noch nicht soo das wahre. Da könnte ich mir auch sowas wie ein DS1085L (http://www.maxim-ic.com/datasheet/index.mvp/id/3495) vorstellen. Der geht allerdings nur bis ca. 50MHz. Ich würde notfalls auch erstmal einen mit 50MHz samplerate machen, dann könnte ich den Baustein nehmen und für allgemeine Sachen sollte es ja auch erstmal reichen. Ich weiß, grade wenn ich schon einen LA habe, ist es recht unnütz und man kanns besser machen, aber mir gehts mehr darum, dass es günstig und simpel ist. Und für 20€ bekomme ich grad mal den FPGA, der in meinem LA drinne ist.
Schnelle Zähler gibt es zwar auch als Logikbausteine, aber ein CPLD ist da die einfachste Lösung - kann auch den Takt teilen bzw. umschalten. Sorry für den Fehler mit 66 Seiten. Da meinte ich das Nanya-Datenblatt, siehe Anhang. Ist im Prinzip ein vergleichbares Bauteil, bloß von anderem Hersteller und umfangreicher dokumentiert. Trotzdem vergeht mir beim Lesen solcher Dokumente regelmäßig aufs Neue die Lust auf SDRAM.
Counter alleine nützen dir nichts ... Dieses Rams hat keine einfachen Adressen, Daten und RD und WR Signale, sondern bekommt Befehle (Kombination aus HW-Signalen und einem OP-Code). Schau dir die Diagramme und die Tabellen im Datenblatt an. Während du deine Daten ins Ram schreibst werden Refresh Zyklen fällig also brauchst du Fifo um diese Zeit zu puffern. Nimm lieber ein SRAM, ist einfacher. Auch wird dein Pic bei 100Mhz keine Triggersignale generieren können. CPLD oder Fpga sind also Pflicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.