Hi, für ein kleines Projekt möchte ich gerne einen parallelen SRAM an einen µC hängen. Ich verwende dabei einfach zwei Ports eines ATMega1284 als Adressbus, damit ich die Adresse einfach auf die Ports byteweise statt bitweise auf einzelne Pins schreiben kann. Vom Boardlayout her ist es aber etwas unpraktisch die leiterbahnen so zu ziehen, dass Beispielsweise PB0 auf A0, PB7 auf A7 und PD0 auf A8 und PD7 auf A15 führt.. besonders dann wenn ich bei einer einseitigen Platine Jumper vermeiden will. Meine Überlegung wäre, dass es ja eigentlich völlig egal ist, welche Adressierung der SRAM intern verwendet, solange das "Mapping" konsequent ist. Wenn ich jetzt willkürlich verdrahte, so wie es vom Board her einfach am praktischten wäre, dann würde ich im µC (verkürzt) beispielsweise die Adresse 0011000011 schreiben, aber beim SRAM käme dann wegen der verdrehten Leitungen 0101000110 an. wäre das schlimm? denn solange die Output-Leitungen korrekt verbunden sind, würde sich das ja ausgleichen. Den Fehler, den ich beim Schreiben mache, würde ich beim lesen ja auch machen. und zwei mal falsch ist (u.u.) einmal richtig ;-) Oder habe ich irgendeinen Faktor übersehen? Viele Grüße und danke schon mal. TOM
...inkrementiert der SRAM die Adressen beim ClockCycle selbständig oder muss man sie jedesmal neu anlegen? (blöd ohne Angaben zum Chip.. aber vollständige informationen ergäben ja kein µC.net thread...)
@Thomas Moll (schwuuuuup) >Meine Überlegung wäre, dass es ja eigentlich völlig egal ist, welche >Adressierung der SRAM intern verwendet, solange das "Mapping" konsequent >ist. Richtig. >wäre das schlimm? Nein. >Oder habe ich irgendeinen Faktor übersehen? Nein. Bei einfachem SRAM kann man Adressen und Datenleitungen vertauschen. Natürlich nicht Adressen MIT Datenleitungen ;-)
Hallo Tom, ja das ist korrekt - bei nem SRAM ist es völlig Banane wie du die Adress- und Datenbits zwischen dem Speicher und dem Microcontroller verbindest. Solange du die beiden Gruppen separat hältst, und solange kein zusätzlicher Controller oder Prozessor eventuell auch noch auf den Speicher zugreifen soll.
... und wenn Du einen Mega64/128 oder einen Nachfolger davon verwenden würdest, würde der AVR die SRAM-Ansteuerung ganz von alleine machen. Das wäre mindestens Faktor 3 schneller. Stichwort EBI. fchk
Hi, danke. Ihr seid die Besten ;-) Das mit dem automatischen Inkrementieren... dass es sowas gibt wusste ich gar nicht. Muss noch mal das Datenblatt lesen... aber nein, das kann bei mir gar nicht der fall sein, denn es wäre kontraproduktiv, spätestens jedes 5. Byte hat eine völlig andere Adresse. Und dass nichts anderes am Adressregister hängen darf ist mir klar. Danke also!
Hi Frank. EBI... klingt interessant... werde ich nachlesen! Danke
Thomas Moll schrieb: > Das mit dem automatischen Inkrementieren... dass es sowas gibt wusste > ich gar nicht. Gibt es auch nicht. Ist halt blöd, daß die Trolle immer unqualifiziert dazwischenquaken müssen. Im Zweifelsfall einfach alle nichtangemeldeten (aka Gast) Schreiber ignorieren und fertig. XL
Axel Schwenke schrieb: > Thomas Moll schrieb: >> Das mit dem automatischen Inkrementieren... dass es sowas gibt wusste >> ich gar nicht. > > Gibt es auch nicht. Ist halt blöd, daß die Trolle immer unqualifiziert > dazwischenquaken müssen. Im Zweifelsfall einfach alle nichtangemeldeten > (aka Gast) Schreiber ignorieren und fertig. > > > XL Na, ganz so voll würde ich den Mund nicht nehmen... -> VRAM natürlich nur beim lesen.
die Frage ist eher: gab's die auch statisch... Das ist schon ein weilchen her. k.A. ob man sowas noch auftreibt.
Axel Schwenke schrieb: > Gibt es auch nicht. Mit "gibt es nicht" sollte man nur dann um sich schmeißen, wenn man alle Exemplare einer bestimmten Kategorie (in diesem Fall SRAMs) kennt. Mit "gibt es" hingegen kann man schon dann prahlen, wenn man nur ein einziges Exemplar mit der gesuchten Eigenschaft kennt. Als dritte Alternative gibt es noch "kenn ich nicht". Es ist ohne jegliches Vorwissen anwendbar, dafür aber nicht sehr publikumswirksam :) Auch wenn ich nicht glaube, dass der TE so etwas tatsächlich einsetzt: Es gibt synchrone SRAMs mit Burst-Mode. Cypress hat eine ganze Palette davon, die laufend durch neue Produkte ergänzt wird. Beispiel: CY7C1338G Witzigerweise sind dort nur die beiden untersten Adressleitungen nummeriert (A0 und A1), während alle anderen einfach nur A heißen, um der Tatsache Ausdruck zu verleihen, dass letztere (und nur diese) untereinander beliebig austauschbar sind.
:
Bearbeitet durch Moderator
Martin schrieb: > Axel Schwenke schrieb: >> Thomas Moll schrieb: >>> Das mit dem automatischen Inkrementieren... dass es sowas gibt wusste >>> ich gar nicht. >> >> Gibt es auch nicht. > Na, ganz so voll würde ich den Mund nicht nehmen... > > -> VRAM Blöd nur, daß nach SRAM gefragt war. Yalu X. schrieb: > Auch wenn ich nicht glaube, dass der TE so etwas tatsächlich einsetzt: > Es gibt synchrone SRAMs mit Burst-Mode. Das stimmt zwar, ändert aber nichts daran, daß "Gast" oben nur blöd gequakt hat. Denn in der Tat gibt es keinen Hinweis darauf, daß der TE tatsächlich einen solchen Exoten einsetzen wöllte (ich würde die Wahrscheinlichkeit dafür bei exakt 0 ansetzen, immerhin hat das Vieh 32 Datenleitungen und ist für Taktraten jenseits 100MHz spezifiziert - was will man damit an einem AVR?). Ich ändere meine Aussage also von "gibts nicht" in "dein SRAM hat (mit an Sicherheit grenzender Wahrscheinlichkeit) sowas nicht" XL
Leider gibt es aber auch in der angemeldeten Fraktion Frösche ;-(
Nur der Vollständigkeit halber: Es gibt auch Dual-Port-SRAMS (also "normales" SRAM, aber mit zwei unabhängigen A+D-Bussen auf denselben Speicher). Die haben meistens auch noch Mailbox-Register im normalen Addressbereich, die für die andere Seite einen Interrupt erzeugen können. Da darf man dann auch nicht die Adressleitungen verwürfeln, selbst wenn man es für beide Seiten identisch verwürfelt ;) Aber zugegeben, auch die sind exotisch...
Thomas Moll schrieb: > Meine Überlegung wäre, dass es ja eigentlich völlig egal ist, welche > Adressierung der SRAM intern verwendet, solange das "Mapping" konsequent > ist. Korrekt, genauso ist das. Wobei allerdings der Begriff "konsequent" in deiner Aussage etwas deplaziert ist, der zutreffende Begriff wäre wohl "konsistent" gewesen. Und zwar geht es konkret um die Konsistenz zwischen Lesen und Schreiben. Solange beide Vorgänge genau das gleiche (auch "falsche") Adressmuster anlegen, um auf den gleichen Wert zuzugreifen, wird die Sache auch funktionieren. Schwierigkeiten sind erst zu erwarten, wenn der RAM selber bestimmte Annahmen über Zugriffsmuster macht (natürlich: DRAM) oder wenn es weitere Busteilnehmer gibt, die auf anderem Weg auf denselben RAM zugreifen, aber von den verwendeten unorthodoxen Adressmustern keine Ahnung haben (z.B. ein unabhängiger Controller für den Display-Refresh). Zumindest letzteres ist auch wieder ganz leicht lösbar: Man muß sie dann nur genauso "falsch" an den Bus tüdern...
Frank K. schrieb: > ... und wenn Du einen Mega64/128 oder einen Nachfolger davon verwenden > würdest, würde der AVR die SRAM-Ansteuerung ganz von alleine machen. Das > wäre mindestens Faktor 3 schneller. Stichwort EBI. > > fchk Hi... ich hoffe ich darf meinen eigenen Thread noch mal aufwärmen... denn ich bin - nachdem ich das Projekt einige Zeit liegen lassen musste - noch mal an dem Thema dran. Habe ich das richtig recherchiert? Der ATMega128 kann externen Speicher nativ unterstützen, der ATMega1284P jedoch nicht? Ich habe das Datenblatt des 1284P rauf und runter gelesen und nichts gefunden, während beim 128 schon auf der ersten Seite steht "Up to 64 Kbytes Optional External Memory Space" Das ist nicht schlimm, weil ich inzwischen eh zu einem ATmega2560 gewechselt bin (MEHR PINS! ;-) ), aber ich wollte es noch mal bestätigt haben, dass ich nicht zu blöd war, sondern nur unwissend bezüglich der Unterschiede zwiscehn 128 und 1284P Gruß TOM
Ach und für die, die beim Googlen über diesen Thread stolpern: Gemeint war sicher EMI: External Memory Interface (Nicht EBI, wie Frank K. geschrieben hatte)
Thomas Moll schrieb: > Habe ich das richtig recherchiert? Der ATMega128 kann externen Speicher > nativ unterstützen, der ATMega1284P jedoch nicht? Jepp. Genauso ist das. Nur relativ wenige Mitglieder der AVR(8)-Familie verfügen über eine externes Speicherinterface. Und das ist auch sehr logisch: Die zu Antüderung eines externen Speichers genutzten Pins fallen ja für die "normalen" Anwendungen komplett aus. Da bliebe bei den meisten schon bei 16k externem RAM nicht sehr viel an Pins über. Der 1284P hat dieses Problem (endlich, viel zu spät!) grundlegend gelöst, indem er 16k internen RAM offeriert, was ausreichend ist, um ein "dummes" QVGA-SW-Grafikdisplay ansteuern zu können, ohne auf externen Speicher ausweichen zu müssen. Schick wäre jetzt noch ein ein Teil zur Abrundung der Palette nach oben mit 64k intern, was den Anwendungsbereich auf 16 VGA-Farben mit QVGA-Auflösung oder alternativ SW in voller VGA-Auflösung erweitern würde. Damit wäre dann endlich nach vielen Jahren auch die echte Grenze erreicht, die durch die mögliche Rechenleistung der AVRs gezogen wird... Alles andere war nur eine künstliche Beschränkung. Keine Ahnung, was sich die Marketing-Fuzzis von Atmel dabei gedacht haben. Die bauen doch selbst überhaupt keine Display-Controller, es gab also keinen Grund, deren Absatz darüber anzukurbeln...
c-hater schrieb: > Thomas Moll schrieb: > >> Habe ich das richtig recherchiert? Der ATMega128 kann externen Speicher >> nativ unterstützen, der ATMega1284P jedoch nicht? > > Jepp. Genauso ist das. Nur relativ wenige Mitglieder der AVR(8)-Familie > verfügen über eine externes Speicherinterface. Und das ist auch sehr > logisch: Die zu Antüderung eines externen Speichers genutzten Pins > fallen ja für die "normalen" Anwendungen komplett aus. Da bliebe bei den > meisten schon bei 16k externem RAM nicht sehr viel an Pins über. > Kannst doch an jeden beliebigen kontroller ein RAM anschliessen. Die pins kannst du auch verwenden, schalte doch einfach das RAM aus.
Takao K. schrieb: > Kannst doch an jeden beliebigen kontroller ein RAM anschliessen. Natürlich. Er wird nur saulangsam sein. Und die Pins sind auf jeden Fall quasi wech', ganz egal ob der Controller ein dediziertes RAM-Interface anbietet oder ob man es auf dem Umweg über (vergleichweise langsame) Portzugriffe nachstellen muß. Alles, was man tun kann, ist hier ein Mehrfach-Mux. Das spart zwar 8 Pins, macht die Sache aber noch langsamer. > Die pins kannst du auch verwenden, schalte doch einfach das RAM aus. Es ist sogar noch einfacher: Man muß es nur einfach nicht einschalten. Diese "geniale" Idee hilft nur leider immer dann nicht weiter, wenn man tatsächlich die entsprechende Menge an RAM benötigt...
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.