Hallo Ich habe da mal eine Frage bezüglich der 62xxx Ram's (Genau 628512) Ich möchte ohne µC Daten speichern und wieder abspielen. nur der ablauf der WE & OE ist mir etwas unklaar Das Datenblatt sagt CS WE OE H X X Deselected High-Z Standby L H H Output Disabled High-Z Active L H L Read Data Out Active L L X Write Data In Active Also WE auf L Schreiben WE H OE L Lesen. Nun die unklaarheit ich lege Daten und Adresse an und muss dann einmal WE L und wieder H setzen ? damits abgespeichert ist? oder WE L Lassen daten anlegen und die Adresse weiterzählen? Beispiel ich habe meinen Zähler 4040 dieser zählt die Adressen. Nur wo schließe ich WE an ? an den Takt? Liebe grüße
Steve N schrieb: > oder WE L Lassen daten anlegen und die Adresse weiterzählen? Keine gute Idee. Die Adressleitungen werden nicht präzise und exakt zum gleichen Zeitpunkt ihren Zustand ändern, sondern unterschiedlich lange dafür brauchen. Damit wird also während des "Weiterzählens" nicht nur die ursprüngliche und die Folgeadresse anliegen, sondern auch noch irgendwas anderes. Das wird zwar nur kurzzeitig der Fall sein, aber das wird ausreichen, um auch Speicherbereiche zu überschreiben, die Du nicht überschreiben willst. Also: /WE erst dann aktivieren, wenn Adressen & Daten stabil anstehen. Dann /WE wieder deaktivieren, und erst danach Adressen und Daten verändern. > Beispiel ich habe meinen Zähler 4040 dieser zählt die Adressen. Nur wo > schließe ich WE an ? an den Takt? Kann man so machen.
Der 4040 ist übrigens ein Ripple-Counter, d. h. während der Einstellzeit liegen seine Ausgänge auf undefinierten Pegeln. Der Einsatz von Monoflops, die die Reihenfolge der Signale exakt einzuhalten helfen, ist angebracht. Habe in meiner Jugend einen Temperaturlogger nur mit einem parallelen AD-Wandler, CMOS Logik Bausteinen und einem Zeropower RAM aufgebaut. Die über mehrere Tage gesammelten Temperaturwerte wurden dann via LPT-Port zum DOS-PC übertragen. Heute macht man sowas mit einem Raspberry Model B.
Raspberry gut und schön. Nur möchte ich einfach mal ohne Prozessoren & co was bauen um das besser zu verstehen :) Ripple-Counter Na toll da fängt es doch schon an. Ich habe versucht über den Letzen Bit vom Counter einen Flipflop zu schalten und mich gewundert warum das zu fehlern führt. Wie kann es sein das ich Problemlos zwei 4040 hintereinander schalten kann? Genau wie du möchte ich einen Temp & Spannungslogger bauen. Die Idee einen 555 als Taktgeber, Dann den den Zähler für die Ram Adressen, Temp und Spannung jeweils einen ADC und ins Ram.
Für meinen Flashplayer habe ich damals 8 bit Synchronzähler genommen: http://www.schoeldgen.de/images/flashplayer.jpg Ich befürchte nur, das es den 74AS867 nicht mehr ohne weiteres gibt. Allerdings sind 4-bit Zähler gang und gäbe, du brauchst bloss doppelt so viele. Wenn du noch einen alten Z80 rumliegen hast, könntest du den als Adresszähler nehmen, indem du an seine Datenleitungen hart ein NOP codierst. Er wird an den Adressleitungen brav hochzählen.
Matthias Sch. schrieb: > Ich befürchte nur, das es den 74AS867 nicht mehr ohne weiteres gibt. > Allerdings sind 4-bit Zähler gang und gäbe, du brauchst bloss doppelt so > viele. Den '590 gibts auch noch. > Wenn du noch einen alten Z80 rumliegen hast, könntest du den als > Adresszähler nehmen, indem du an seine Datenleitungen hart ein NOP > codierst. Er wird an den Adressleitungen brav hochzählen. Nette Idee. Für passende WE/OE Signale sorgt er auch noch.
Steve N schrieb: > Wie kann es sein das ich Problemlos zwei 4040 hintereinander schalten > kann? Es ist kein Problem, beliebig viele 4040er hintereinander zu schalten, macht der intern ja auch nicht anders. Es ist nur ein Problem, mit all den schönen Ausgängen etwas anzufangen ohne lange genug zu warten bis sie bis zum letzten Ausgang durchgerippelt haben. Wenn du also 4040er als Adresszähler verwenden willst, dann warte nach dem Takt so lange bis der stabile Zustand erreicht ist und aktiviere erst dann WE.
Steve N schrieb: > ich lege Daten und Adresse an und muss dann einmal > WE L und wieder H setzen ? damits abgespeichert ist? Ja. > Beispiel ich habe meinen Zähler 4040 dieser zählt die Adressen. Nur wo > schließe ich WE an ? an den Takt? An einen Impuls der inmitten des Takts kommt, damit Adressen (und Daten) vorher stabil sind und nachher stabil bleiben. Was ist an set-up und hold times im Datenblatt so schwer zu verstehen? Ja, du musst das passende Signal erst mal mjt Aufwand erzeugen.
...ich hänge mich mal hier rein, da ich so ein ähnliches Problem habe: Ich habe ein externes Schreibsignal, nennen wir es mal IOWR (I/O Write). (Jaja, immer noch 8086...) Momentan setzte ich ich den MW-Pin am SRAM händisch per AVR: H-L-H und das verbraucht bei 20Mhz knapp 200ns (4x50ns, eher mehr). Laut Datenblatt brauche ich aber nur >55ns (twp). Kennt jemand eine Schaltung (oder einen Namen dafür, Tante Google kenne ich), die mir auf eine H-L Flanke ein kurzes H-L-H -Signal (55...100ns) generiert? Theoretisch könnte der TO auch diese Schaltung nutzen um aus dem Taktsignal das WE-Signal zu erzeugen. (Solange eine halbe Periode des Taktes größer als 55ns ist...ich denke mal 100ns = Periode 200ns =5 Mhz) Mirko
MirkoB schrieb: > Kennt jemand eine Schaltung (oder einen Namen dafür, Tante Google kenne > ich), die mir auf eine H-L Flanke ein kurzes H-L-H -Signal (55...100ns) > generiert? Das wäre ein Monoflop. So etwas kann mit einem 74xx123 aufgebaut werden, als zeitbestimmender Kondensator sind nur wenige pF erforderlich. Allerdings: Wozu? Du steuerst ein SRAM mit einem AVR anscheinend von Hand an -- AVRs aber haben auch ein Speicherinterface und können das selber machen, und das geht dann komplett ohne Monoflops und ist Größenordnungen schneller als der handgedengelte Speicherzugriff, weil auf der Softwareseite das genauso wie das interne RAM angesprochen werden kann.
A. K. schrieb: > Für passende WE/OE Signale sorgt er auch noch. Hehehe, leider lässt er ja sein eigenes WR inaktiv,beim NOP ist ja nix zu tun - aber RD liefert mit ein bisschen verodern dann das geeignete WE und ein CS.
MaWin schrieb: >> Beispiel ich habe meinen Zähler 4040 dieser zählt die Adressen. Nur wo >> schließe ich WE an ? an den Takt? > > An einen Impuls der inmitten des Takts kommt, damit Adressen (und Daten) > vorher stabil sind und nachher stabil bleiben. > Was ist an set-up und hold times im Datenblatt so schwer zu verstehen? > Ja, du musst das passende Signal erst mal mjt Aufwand erzeugen. Geht auch mit zwei 4040: Diese kaskadieren, den /WE aus Q0 erzeugen, /CS auf low hängen, die Adressen sind dann Q1... Damit kommen erst die Adressen, /WE wird gleich low und die Daten werden normalerweise mit der steigenden Flanke dann übernommen, danach rippeln die anderen Adressen. Sollte mit den Th auch passen. Muss man nur am 4040 die doppelte Frequenz machen. rgds
Steve N schrieb: > Genau wie du möchte ich einen Temp & Spannungslogger bauen. Die RAM-Adressierung ist aber nur ein ganz kleiner Teil der gesamten Ablaufsteuerung. Du willst ja die Aufzeichnung zu einer bestimmten Zeit beginnen, beenden und irgendwo hin in eine bestimmten Format über ein bestimmtes Protokoll ausgeben. Ohne MC wird das ein ganz schönes IC-Grab und völlig unflexibel bist Du obendrein. old man schrieb: > Heute macht man sowas mit einem Raspberry Model B. Wäre mir 1000-fach oversized, aber eine MC-Lösung ist schon der sinnvolle Weg.
Rufus Τ. Firefly schrieb: > Das wäre ein Monoflop. So etwas kann mit einem 74xx123 aufgebaut werden, > als zeitbestimmender Kondensator sind nur wenige pF erforderlich. Vielen Dank! Monoflop und 74xx123 war das Suchwort. Im Datenblatt (NXP) steht ja alles dazu drin. Rufus Τ. Firefly schrieb: > Allerdings: Wozu? Du steuerst ein SRAM mit einem AVR anscheinend von > Hand an -- AVRs aber haben auch ein Speicherinterface und können das Das das wozu: 8086 auf AVR emuliert mit externem ISA-Bus. Das Projekt ist zu groß um es in diesem Beitrag komplett zu beschreiben, aber vielleicht wirds mal einen Artikel im Wiki geben. Aktueller Stand ist der, dass ein paar x86 Befehle bereits funktionieren. (Hauptsächlich NOP und JMP zum testen... :) ) Register, Pointer ect. sind breits implementiert und die Berechnung der (realen) Speicherzelle aus Offset und Segment scheint auch zu gehen. Der Bus ist bei mir gemultiplext. 24 Adressleitungen (4 Reserve für 286) + 16 Datenleitungen Alles klassisch mit 2x 74HCT245 für die Daten , 3x 74HCT573 für die Adressen und 1x 74HCT573 für die Bussteuersignale. (MR MWR IOR / IOWR + andere - Soll im Vollausbau einen kompletten 16 Bit ISA-Bus ergeben) Belegt momentan am AVR 2 Ports für den Bus + Pins für die Ansteuerung. (=20..22 I/Os habe es gerade nicht hier) Bisher habe ich die Signale für den SRAM händisch am AVR erzeugt, was aber eigentlich Quatsch ist, da ich ja bereits mit MWR bzw. MR einen Schreib oder Lesewunsch geäußert habe. Mit meiner händischen Ansteuerung erreiche ich ca. 300...600 kB/s je nach Schreib/Lesestrategie. Grund ist der, dass mir die I/O Pins am AVR ausgehen und ich allerdings noch ein paar für die serielle Schnittstelle /SD-Card und Interruptsteuerung benötige.... Mirko
Matthias Sch. schrieb: > Hehehe, leider lässt er ja sein eigenes WR inaktiv,beim NOP ist ja nix > zu tun - aber RD liefert mit ein bisschen verodern dann das geeignete WE > und ein CS. Eben. Wenn man den so aufgebauten "Zähler" anhalten will, dann kann man dafür möglicherweise den HALT Opcode an Stelle des NOPs verwenden. Der HALT Befehl bleibt nämlich nicht einfach stehen, sondern führt eine stete Folge von M1 Zugriffen auf ebendiesen HALT Opcode durch. Also quasi ein NOP ohne PC-Inkrementierung. Ich weiss nur grad nicht, ob man da wieder rauskommt indem man wieder einen NOP draus macht, oder ob man dafür doch die Interrupt-Leitung braucht.
A. K. schrieb im Beitrag #3164715: > Das sieht dann vom Timing her genauso aus wie beim > NOP, nur tritt er auf der Stelle. Gute Idee, ich weiss nicht genau, ob der Zilog Z80 'fully static' ist (die TMPZs von Toshiba waren das), dann könnte man ihm auch den Takt abklemmen. HLT wäre 0x76, NOP ist 0x00. Einen Reset Pin hat er auch - alles was der Siedler braucht, und eine Single-Chip Lösung.
Matthias Sch. schrieb: > Gute Idee, ich weiss nicht genau, ob der Zilog Z80 'fully static' ist Ist er. "Although static by design, testing guarantees ...".
MirkoB schrieb: > Momentan setzte ich ich den MW-Pin am SRAM händisch per AVR: > H-L-H und das verbraucht bei 20Mhz knapp 200ns (4x50ns, eher mehr). Laut > Datenblatt brauche ich aber nur >55ns (twp). Ein OUT Befehl benötigt nur 1 Takt. Wenn man also die Daten im Register schon parat hat, dann kommt man auf 50ns runter. Mit CBI/SBI Befehlen kommt man auf 100ns.
A. K. schrieb: > Ein OUT Befehl benötigt nur 1 Takt. Wenn man also die Daten im Register > schon parat hat, dann kommt man auf 50ns runter. Mit CBI/SBI Befehlen > kommt man auf 100ns. Ich zitiere mal aus dem Quellcode: (Funktion RAM mit NOP-90h füllen) ---- LDI temp4,$90 OUT PortA,temp4 ;Ausgabe D08-D16 auf PortA OUT PortC,temp4 ;Ausgabe D00-D07 auf PortC CBI DDE ;Daten liegen auf Datenbus an NOP NOP CBI MWC ;2 Takte NOP ;Zeit für PortBx -> PinBx (CBI 2 Takte) NOP ;Schreibimpuls liegt NOP ;auf low für 100ns SBI MWC SBI DDE ;Datenlatch Tristate SBI ALE ;Adresslatch Tristate ---- Ich sehe hier mit den OUT Befehlen keine Optimierungsmöglichkeit. Ich muss ja die zu schreibenden Daten auch erst in das Register bekommen, was auch mind. 1 Takt dauert... Nach kurzen Rechnen sind es 2+3+2 = 7 Takte = 350 ns An der Stelle komme ich erstmal nicht weiter. Ich möchte also alle Bussignale wie oben auf einen 74x573 geben und den einmalig triggern. Aus Bussignalen generiere ich dann die restlichen Signale. (Datenrichtung 74x245, Ausgang Adressbuss, etc.). Mir fehlt eben nur der Gedankenanstoß um aus dem Schreibsignal (xWR) einen kurzen Sdchreibimpuls für WR zu generieren. Ich weiß, dass es CLPDs gibt, aber ich will die evtl. Nachbauschwelle nicht zu hoch legen. :) Mirko PS: Das ist ein Wochenende-Schlechtwetter-Feierabendprojekt...es kann sich also noch viele Monde hinziehen. :)
MirkoB schrieb: > Ich zitiere mal aus dem Quellcode: (Funktion RAM mit NOP-90h füllen) Die Daten müssen nicht schon ewig vorher anliegen. 25ns vor WR 0=>1 reicht aus. Die NOPs vor WE 1=>0 sind somit überflüssig. WE 1=>0 zu 0=>1 muss bim 55ns Typ mindestens 40ns betragen. Das ist ein Takt. Bei CBI/WBI direkt hinter einander sind es bereits 100ns. Auch hier sind die NOPs überflüssig. Eine Funktion, die den ganzen Speicher mit 0x90 füllt, kann also im Kern so aussehen: Vorbedingungen: - 0x90 auf DatenPorts legen - rB und rC passend vorbereiten out addrPortL, rA ;1 Takt, unteres Adressbyte inc rA ;1 Takt out ctrlPort, rB ;1 Takt, WE 1=>0 out ctrlPort, rC ;1 Takt, WE 0=>1 out addrPortL, rA ;1 Takt inc rA ;1 Takt out ctrlPort, rB ;1 Takt, WE 1=>0 out ctrlPort, rC ;1 Takt, WE 0=>1 ... n-mal unrolling ... > Ich sehe hier mit den OUT Befehlen keine Optimierungsmöglichkeit. Ich > muss ja die zu schreibenden Daten auch erst in das Register bekommen, > was auch mind. 1 Takt dauert... Nach kurzen Rechnen sind es 2+3+2 = 7 > Takte = 350 ns Ich komme auf 4,x Takte = etwas über 100ns pro Schreibvorgang. Lesen ist etwas komplizierter, aber OUTs überholen sich nicht.
Ich gebe zu, dass mein momentaner Stand seeeehr viel Optimierungspotential hat. Grundsätzlich ging es mir bei dem obrigen Stand auch nur um die ersten Tests für die Umsetzbarkeit des Projektes. Die 90h-Funktion ist ein Copy&Paste aus der normalen Schreibfunktion, nur festkodiert ohne Optimierung. NochmalNachgewühlt --- WriteRAM: ldi temp1,$FF ;DDRA -> Alle auf Ausgang out DDRA,temp1 ldi temp1,$FF ;DDRC -> Alle auf Ausgang out DDRC,temp1 SBI MWC ;Memory Write auf Highpegel SBI ALE ;Adresslatch Tristate SBI ALL ;Adresslatch A00-A15 auf SBI ALH ;Adresslatch A16-A19 auf SBI MWC LDS temp1, Adr0 ;Schreibadresse -> Arbeitsregister LDS temp2, Adr1 LDS temp3, Adr2 OUT PortC,temp3 ;Ausgabe A16-19 auf PortC CBI ALH ;Adresslatch verriegeln OUT PortA,temp2 ;Ausgabe A08-A16 auf PortA OUT PortC,temp1 ;Ausgabe A00-A07 auf PortC CBI ALL ;Adresslatch verriegeln CBI ALE ;Adressen liegen auf Adressbus an SBI DDR ;Datenlatch CPU -> Speicher LDS temp1, DataL ;Daten -> Arbeitsregister LDS temp2, DataH OUT PortA,temp2 ;Ausgabe D08-D16 auf PortA OUT PortC,temp1 ;Ausgabe D00-D07 auf PortC CBI DDE ;Daten liegen auf Datenbus an CBI MWC ;Schreibimpuls auf NOP SBI MWC ;fallende Flanke SBI DDE ;Datenlatch Tristate SBI ALE ;Adresslatch Tristate ret --- Ein NOP zwischen CBI MWC und SBI MWC war notwendig, da die Zeit (>45ns lt Datenblatt) ohne das NOP zu kurz war. In meinem neuen Layout liegen sämtliche Steuersignale jetzt auf einem Latch. Dieser wird ganz oben ebenfalls über LDI temp4,BusCtrl geladen und ebenso rausgeschrieben. Im Prinzip soll dann per SBI BLE (BusLatchEnable) dieser die restlichen Signale (ALE, DT/R, DEN, INTA sowie MR, MWC, IOR, IOWC) ausgeben. Problematisch bei dem Layout ist, dass es nicht möglich ist das WRC zeitverzögert zu erzeigen, da der "Bus Controller"-Latch an Port A hängt, dort aber die Daten zum schreiben anliegen. Das MWC muss also zeitverzögert als Impuls eigenständig erzeugt werden. Alle Bussignale direkt am ATMega zu erzeugen ist auch eine Lösung, aber mir gehen beim 1284 langsam die Pins aus... und die "großen" laufen nur mit 16 Mhz. Wie gesagt, dass ist ein reines Hobbyprojekt und wie man im Forum lesen kann, gärt das auch schon länger als ein Jahr. (Und ich freue mich schon wie eine Schneeprinzessin, dass interne Register/Segmentnachbildung sowie die 6-Byte Pipline des 8086 funktioniert... :) Achja...und ins BIOS springt er auch schon) I/O Schreibzugriffe auf Massenspeicher sollen intern auf eine SD-Card (per SPI) umgeleitet werden. Die Textausgabe soll ebenfalls als VT100 Terminal über die serielle Schnittstelle realisiert werden. (Momentan läuft hierrüber die Debug-Ausgabe) Mir bleiben also an PortB 4 Pins und an PortD 6 Pins übrig. Ein paar für Tastatur sowie Interrupt-Eingang werden auch noch benötigt... Also noch viel Arbeit. Mirko
MirkoB schrieb: > Ein NOP zwischen CBI MWC und SBI MWC war notwendig, da die Zeit (>45ns > lt Datenblatt) ohne das NOP zu kurz war. Das finde ich interessant, denn zwischen den Aktionen durch CBI und SBI liegen doch bereits 2 Takte, also 100ns bei 20MHz.
A. K. schrieb: > Das finde ich interessant, denn zwischen den Aktionen durch CBI und SBI > liegen doch bereits 2 Takte, also 100ns bei 20MHz. Ich habe im Debugger folgendes im Einzelschrit ausgeführt. Pfeil stand auf dem ersten Befehl, Cycle Counter reset CC Befehl PORTB PINB 0 CBI MWC 1 1 2 NOP 0 1 3 SBI MWC 0 0 5 NOP 1 0 6 NOP 1 1 0 CBI MWC 1 1 2 SBI MWC 0 1 4 NOP 1 0 5 NOP 1 1 Also dürften am Pin selbst ohne NOP nur 50ns der Impuls anliegen. Offenbar ist das bei meiner Lochraster-Fädeldraht-Variante eher suboptimal. Mirko
MirkoB schrieb: > 0 CBI MWC 1 1 > 2 NOP 0 1 > 3 SBI MWC 0 0 > 5 NOP 1 0 > Also dürften am Pin selbst ohne NOP nur 50ns der Impuls anliegen. Bei mir ist 5-2 immer noch 3, also mit NOP 150ns und ohne 100ns. Du musst die Taktzyklen zählen, nicht die Befehle.
A. K. schrieb: > Bei mir ist 5-2 immer noch 3, also mit NOP 150ns und ohne 100ns. Du > musst die Taktzyklen zählen, nicht die Befehle. Du hast Recht. Ich habe mir mal schnell was zurecht gesteckt und mit dem Oszi nachgesehen: CBI und SBI hintereinander erzeugen einen 100ns Impuls bei 20Mhz. Mit NOP 150ns. Trotz alle dem gehen mir die I/O Pins am AVR aus...vielleicht kann ich aber was über einen 74x959 am Hardware SPI tricksen. 8 Bit sind 16 Takte. Ist vielleicht doch eine Überlegung wert... Mirko
Thread beobachten
Seitenaufteilung abschalten
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.