Hallo, ich schraube derzeit an einer Ram Anbindung an einen Mikrocontroller. Das ist ja so ein Klassiker. Der wahlfreie Zugriff hat da weniger Priorität. Spannender ist da mehr der Sequenzielle Zugriff. Da gibt es ja schon einige Projekte die verschiedene Ramarten anbinden. Manche lösen das indem sie die Adressierung über einen Logikbaustein machen. Wie auch immer, ich wollte die sequenzielle Adressierung ebenfalls einem Counter-IC überlassen. Bisher habe ich immer alles mit dem Mikrocontroller selbst gemacht, würde jetzt aber gerne derart primitive Aufgaben zur Resourcenschonung auslagern und um gleichzeitig Erfahrungen mit Anbauten zu sammeln. Zuerst hielt ich da etwas wie den 74hct4020 für eine gute Idee. Aber nun das Problem. Die Verzögerungszeiten, ich hab da jetzt mal das Datanblatt von NXP hergenommen, belaufen sich bei 4,5 Volt auf 35 ns vom Takt zu ersten Ausgang, und weiteren 19 ns von Ausgang n zu n+1 im Temperaturfenster -40 bis +85 Grad. Gut das sind jetzt die Maximalzeiten, aber typische Zeiten sind nur für 25 Grad angegeben und die sind auch nicht garantiert. Also ergibt sich daraus eine Verzögerung von 35 + 13*19= 282 ns bis der Counter nach dem Takt die Adresse fertig "berechnet" hat. Auch wenn die 12 Bit Version etwas schneller ist, weil man die letzten beiden Stufen nicht braucht, so scheint man damit keinen Blumentopf zu gewinnen. 5 Volt würden das auch nur ninimal beschlunigen. Bevor ihr fragt wozu ich das brauche und nach dem Schaltplan fragt. Zunächst einmal soll das eine generische Baugruppe werden und ich suche nach einem passenden Counter oder Ähnlichem um erst einmal einen Schaltplan zu erstellen. Im Moment bin ich noch bei der Adressgenerierung. Sie soll einfach nur hochzählen, ohne den Mikrocontroller. So gesehen ist es an dieser Stelle auch noch erst einmal egal ob dann SRAM, DRAM oder FLASH angesprochen werden soll. Bei den Dingern steht High-speed und 101 MHz bei der HC und 52 MHz bei der HCT Version im Datenblatt. Das will mir irgendwie nicht Einleuchten, denn bei den obigen 282 ns Gesamtverzögerung kommt man nicht einmal auf 4 MHz. Und das sind nur die Verzögerungen im Counter. Weitere Laufzeiten kämen ja noch hinzu. Um die behaupteten 52 MHz zu erreichen müßten die Laufzeiten unter 20 ns liegen. Der Mikrocontroller soll das Ganze nur Starten und stoppen und somit nur ein paar Steuerleitungen liefern und somit egal sein. Es ist zwar etwas aus der ATMega Familie gedacht, aber wie gesagt: Es soll eine generische Anbaugruppe werden, so dass es jeder verwenden kann. Und ich möchte praktische Erfahrungen sammeln mit dem Anbau von externen Logikbausteinen. An dieser Stelle Frage ich mich: Gucke ich einfach nur an den richtigen schnellen Countern geschickt vorbei oder bin ich hier schon vom Ansatz her auf dem Holzweg? Wenn ein ganzer ATMega oder ATTiny ohne Probleme mit 20 MHz hochzählen kann, kann es doch nicht sooo schwer sein etwas zu finden das genau so schnell hochzählen kann ohne einen eigenen Mikrocontroller oder gar eine konfigurierbare Logik dafür verbraten zu müssen. Hat da jemand eine Idee an welcher Stelle ich hier auf dem Schlauch stehe? viele Grüße Carsten Nachtrag: Auch wenn es im Verborgenen indirekt zu lesen ist. Ich würde die Adressen gerne passend zu den 20 MHz generieren, dazu sollte die Berechnungszeit also deutlich unter 50 ns liegen.
Du must nach syncronen Counter (74xx161) schauen nicht nach Rippelcounter wie der 4020 einer ist. Bei Rippelcounter sind die Flipflops alle hintereinande geschaltet und das dauert halt bis der Zaehlimpuls durch ist. Bei syncronen Counter ist das nach einer Verzoegerung da.
>Im Moment bin ich noch bei der >Adressgenerierung. Sie soll einfach nur hochzählen, ohne den >Mikrocontroller. Das geht aber nicht;) Du musst mindestens den Clock für den Zähler vom uC liefern.
@ Helmut Danke, ich glaube das war genau das fehlende Schlüsselwort @ Holger Dass ich einen Takt brauche war mir schon klar, schließich habe ich den Takt auch schon in der Verzögerungsberechnung als Bezugspunkt drin. Den hatte ich jetzt in diesem Fall als "Steuerleitung" aufgefaßt um über den Takt den Adressgenerator anzuhalten oder zu Starten. Vieleicht ist das aber auch eine ganz blöde Idee.^^ Das ganz ist jetzt ja noch am Angfang. Bis Weihnachten ist es hoffentlich fertig :P Viele Grüße an alle Carsten
Carsten R. schrieb: > Hallo, .... > So gesehen ist es an dieser Stelle auch noch erst > einmal egal ob dann SRAM, DRAM oder FLASH angesprochen werden soll. nö ;) SRAM kannst du mit einfachem Zähler addressieren... OK DRAM gibts zig verschiedenen Versionen der Ansteuerung und du brauchst die Auffrischung der Ram zellen. Parallel Flash wirst du mit einem Zähler lesen können aber nicht beschreiben. Und es gibt noch serielles SPI Flash. Für ein universelles Speicher Interface wird das schon eine FPGA werden müssen,ein einfacher Zähler reicht da nicht ;) Mir ist aber immer noch nicht klar was du wirklich willst. Einen Speicher nur universell zu adressieren ist ziemlich sinnlos. > Um die behaupteten 52 MHz zu erreichen müßten die > Laufzeiten unter 20 ns liegen. Start, Stop oder Taktung durch dein ATMEGA wird keine 52 Mhz können also mach dir erst mal um den externen Zähler nicht so viel Gedanken. Bring mal eine konkrete komplette Anwendung. Gruß Hans-Georg
Es soll erst einmal nur ein ein primitiver hochzählender Adressgenerator sein für den ich den Baustein suche und ist somit nur ein Teil des gesamten Interfaces. In dieser Funktion ist die Art des Speichers egal. Ob ich dann damit nur lesend ein ROM adressiere, flüchtiges RAM in regelmäßigen Pausen refreshe oder bekloppterweise diese Adresse per SPI an einen seriell angebundenen Speicher verschicke ist für die Adressgenerierung ohne Belang. Für die Eigenarten des Speichers ist dann ein anderer Teil zuständig. Die Steuerleitungen sollen ja vorerst noch vom µC kommen, deren Verhalten ich dann per Software anpassen kann. Später kann ich immer noch den ganzen Kram an ein CPLD deligieren. Aber das stelle ich mir ohne Erfahrung mit CPLDs nicht so ganz trivial vor. Ich möchte wie gesagt a) erste Erfahrungen mit "externer Logik" sammeln. Und dies war eine der ersten Ideen dazu die ich hatte. b) ein primitives auf streaming ausgelegtes Interface erstellen welches man dann leicht recyceln kann, sei es um schnell ein ROM ins RAM oder von RAM zu RAM zu kopieren oder einen Cache zu füllen (woher ich meine SRAMs geklaut habe^^) Ginge es nur um eine reine RAM Anwendung und ohne Lernaspekt wäre ich wahrscheinlich besser mit SDRAM beraten. Die haben ja die Logik für den BURST-Mode schon integriert. Dann bräuchte ich bis auf die Pegelwandler keine weitere Logik um den RAM aufbauen. Aber Lernen und Wiederverwenden stehen im Vordergrund. Und einen FPGA wollte ich nun nicht als ersten Schritt in die Welt der externen Logik nehmen, eher als dritten. Bis dahin wollte ich erst einmal mit Bausteinen beginnen, deren Verhalten ich nicht definieren muß. Somit wäre diese Fehlerquelle bei den ersten Schritten im Neuland ausgeschlossen. Mit ist klar das mein µC keine 52 MHz macht. Das war nur als Kontrast zu den von mir abgeschätzten 282 ns zu verstehen die nicht einmal 4 MHz zulassen würden. Als Ziel hatte ich ja angegeben eine passende Geschwindigkeit zum 20 MHz Takt des µC zu erreichen. Als erste Anwendung würde ich nur zum Experimentieren stumpf zwischen zwei RAM-Bausteinen oder einem FLASH den ich hier liegen habe auf den SRAM Streamen wollen, ohne die Daten durch die Register des µC zu schieben, eine Art Bypass also, von der Idee DMA inspiriert. Wenn es Funktioniert und ich eine Ahnung habe was ich da eigentlich mache würde ich gerne eines Tages ein Standbild vom RAM isochron auf einen Bildschirm "kopieren". Aber das liegt in der Zukunft. Dies sind noch die ersten Schritte. Gruß Carsten
>Ginge es nur um eine reine RAM Anwendung und ohne Lernaspekt wäre ich >wahrscheinlich besser mit SDRAM beraten. Schwachsinn. Du weisst doch nicht mal was das ist.
@ Holger was ist denn das für ein Ton. Zufälligerweise weiß ich sehr genau was SDRAM ist. Ein SDRAM kann angewiesen werden ein Datum zu Übertragen oder eine Sequenz. Die unterstützten Modi sind zwar prinzipiell bauartbedingt, aber weitestgehend einheitlich. Am gängigsten sind die Modi 1, 2, 4 oder 8 Worte in Folge zu übertragen. In aller Regel ist es auch möglich eine ganze Page zu übertragen. Und ein Page-Burst würde ziemlich genau das machen was ich machen will. Der Hauptunterschied in diesem Fall besteht darin daß der SDRAM die Folgeadressen beim Burst intern selbst erzeugt anstatt sie von externer Logik vorgezählt zu bekommen. Und ich würde diese Zählwerk gerne auch bei anderen Gelegenheiten wiederverwenden. Es gibt noch andere Unterschiede, aber hier ging es um die Gemeinsamkeit weswegen ich das erst erwähnt hatte. @Joe Danke. Die 74HC40103 hatte ich dank des vorherigen Hinweises nach synchronen Bausteinen zu suchen schon gefunden, zwei davon zusammengeschaltet würden für meine SRAMS und FLASH-Speicher passen, aber was 10-bittiges paßt sehr gut zu den Pagegrößen der meisten DRAMs die ich hier in meiner Kiste habe. Auch wenn ich zu 74xx491 auf die schnelle nichts finde werde ich die Augen danach offen halten. Gruß Carsten
Ach ja, jetzt weiß ich es wieder: Der 74HC40103 geht nicht. Das ist ein Down-Counter. Der hat nur einen Ausgangspin, welcher schaltet wenn der IC auf 0 runtergezhlt hat. Aber die Rubrik ist bei Farnell schonmal die richtige. :)
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.