Hallo, ich bastele mir gerade eine Platine mit einem Atmega64 zusammen, der zusätzlichen SRAM benötigt. Der 64 hat ein XMEM interface, was das eigentlich vereinfachen sollte. Dennoch bin ich verwirrt: Ja, es gibt diese tolle Schaltungsbeschreibung im Datenblatt, wo auch drinsteht, welches Latch man nehmen sollte, etc. Dennoch: Kann ich jetzt 64K oder 8x64K anschließen. Was für einen SRAM soll ich nehmen? Ich bestelle gerne bei Reichelt, habe dort keinen mit 8x64K gefunden, kann ich auch einen größeren nehmen? Hab mittlereile auch rausgefunden, dass ich bei meiner Taktfrequenz (14,7..MHz), den 74HTC573 nehmen muß, aber wie siehts mit dem SRAM aus? Wie gesagt ich bin verwirrt.... Hat jemand sowas schonmal ohne viel gebastel gemacht? Wie gesagt ich möchte einfach nur das XMEM Interface benutzen. Könnt Ihr mir eine Schaltung zeigen? Danke im Voraus Schorsch
Schorsch schrieb: > Kann ich jetzt 64K oder 8x64K anschließen. 64kByte oder 8x64kBit. Auf dem Baustein sollte irgendwas mit 512xxx draufstehen, wenn es die ältere Markierungsweise ist. Neuere High-Speed-SRAMs von Cypress oder ähnlichen Anbietern werden anders markiert. Schorsch schrieb: > dass ich bei meiner Taktfrequenz > (14,7..MHz), den 74HTC573 nehmen muß Nö, den HC oder HCT. Schorsch schrieb: > aber wie siehts mit dem SRAM aus? Unter 40ns Zugriffszeit wäre schon ein guter Richtwert. Schorsch schrieb: > Hat jemand sowas schonmal ohne viel gebastel gemacht? Tausende Leute vor Dir. Schorsch schrieb: > Könnt Ihr mir eine > Schaltung zeigen? Die aus dem Datenblatt funktioniert hervorragend. Ansonsten gibt es auch noch AppNotes dazu im Netz.
Hallo, danke... Knut Ballhause schrieb: > Schorsch schrieb: >> Kann ich jetzt 64K oder 8x64K anschließen. > > 64kByte oder 8x64kBit. Auf dem Baustein sollte irgendwas mit 512xxx > draufstehen, wenn es die ältere Markierungsweise ist. Neuere > High-Speed-SRAMs von Cypress oder ähnlichen Anbietern werden anders > markiert. > aso... > Schorsch schrieb: >> dass ich bei meiner Taktfrequenz >> (14,7..MHz), den 74HTC573 nehmen muß > > Nö, den HC oder HCT. typo :-p > > Schorsch schrieb: >> aber wie siehts mit dem SRAM aus? > > Unter 40ns Zugriffszeit wäre schon ein guter Richtwert. Hab bei Reichelt nur diesen hier gefunden: 6264-70 M - Cycle time ist hier 70ns... ich kenn mich mit Anologelektronik aus, mal vielleicht irgendwo n Multiplexer, ich hab keine Ahnung, was das bedeutet... ich vermute, der ist dann wohl zu langsam? > > Schorsch schrieb: >> Hat jemand sowas schonmal ohne viel gebastel gemacht? > > Tausende Leute vor Dir. das glaube ich, dennoch wird dann hier und da mehr und weniger drangestickt, wie man doch mit 3 zusätzlichen Bits mehr addressieren kann... > > Schorsch schrieb: >> Könnt Ihr mir eine >> Schaltung zeigen? > > Die aus dem Datenblatt funktioniert hervorragend. Ansonsten gibt es auch > noch AppNotes dazu im Netz. Hab ich leider nicht gefunden - Ich stoße immer wieder beim Googlen auf diesen Artikel Schorsch
Hallo, ich finde wirklich keinen passenden SRAM mit 40ns, einzig bei rs-online habe ich einen ic für 76EUR gefunden - soviel wollte ich nicht ausgeben. Daher nochmal die Frage, wenn das schon soviele Menschen vor mir gemacht haben, welchen SRAM Chip haben sie verwendet und wo haben sie ihn bestellt? Schorsch
Schorsch schrieb: > welchen SRAM Chip haben sie verwendet Müsste ich zu Hause mal nachsehen, ist schon Jahre her, dass ich mir eine 64-KiB-Erweiterung für eine ATmega128-Experimentierplatine gebaut habe. > und wo haben sie ihn > bestellt? Ausgebaut aus alten Festplatten. ;-) Gab's dann dafür nur im TSSOP-Gehäuse, das mich durch das 0,5-mm-Raster ein wenig an die Grenzen meiner damaligen Platinenbestückungsfertigkeiten gebracht hat. Du kannst ja für Externspeicher auch zusätzliche wait states mit einplanen, wenn der, den du findest, nicht schnell genug ist. Man sollte dann halt möglichst nicht den Stack in den Externspeicher legen, sondern ans obere Ende des internen SRAM. Denk dran, dass (ohne Tricks und Kniffe) ein Teil des externen 64-KiB-Bereichs nicht zugänglich ist, da er duruch den internen Speicher überschattet wird.
Hallo, Jörg Wunsch schrieb: > Denk dran, dass (ohne Tricks und Kniffe) ein Teil des externen > 64-KiB-Bereichs nicht zugänglich ist, da er duruch den internen > Speicher überschattet wird. Du meinst, weil die ersten 4K schon vom internen Speicher benutzt werden? Die Anwendung wird ein Datenlogger sein, der momentan mit 1kHz Daten über die ADCs aufzeichnet. Im Augenblick schiebe ich alles on-the-fly per USB raus. ich stoße jetzt aber so langsam an die Grenzen, wenn ich nochmehr aufzeichnen will. Daher will ich jetzt erst Puffern, dann am Ende rausschreiben. Ich hab mich mit der Programmierung noch nicht beschäftigt; kann ich dann in meinen C-Code variablen direkt in den internen oder den externen Speicher legen? Habe überlegt einen größeren (oder kleineren) SRAM zu nehmen. Gibt es da etwas zu beachten? Es gibt z.B. 64kx16, ich schätze ich könnte die übrigen 8 beinchen einfach auf GND ziehen? oder wenn ich 256Kx8 nehme und die Adressbeinchen auf GND ziehe? Geht sowas, ich hab keine Ahnung? Georg
Externes memory, das ist lange her! Ich hab mal eins der Testprogramme ausgebuddelt. Das CPLD erweitert den Adressbereich um den gesamten Speicher adressieren zu können, kann man aber "ignorieren". Da sollte eigentlich alles drin beschrieben sein...
Schorsch schrieb: >> Denk dran, dass (ohne Tricks und Kniffe) ein Teil des externen >> 64-KiB-Bereichs nicht zugänglich ist, da er duruch den internen >> Speicher überschattet wird. > > Du meinst, weil die ersten 4K schon vom internen Speicher benutzt > werden? Ja, genau genommen sind es 0x1100 Bytes, die intern adressiert werden (wegen der IO-Register, die unterhalb der 4 KiB internen SRAMs liegen). > Daher will ich jetzt erst Puffern, dann am > Ende rausschreiben. Naja, einer Situation, bei der der Zufluss permanent größer ist als der Abfluss, wird man aber auch mit mehr Puffer nicht Herr. ;-) > Ich hab mich mit der Programmierung noch nicht beschäftigt; kann ich > dann in meinen C-Code variablen direkt in den internen oder den externen > Speicher legen? RTFHandbook ;-) http://www.nongnu.org/avr-libc/user-manual/malloc.html > Habe überlegt einen größeren (oder kleineren) SRAM zu nehmen. Gibt es da > etwas zu beachten? Es gibt z.B. 64kx16, ich schätze ich könnte die > übrigen 8 beinchen einfach auf GND ziehen? oder wenn ich 256Kx8 nehme > und die Adressbeinchen auf GND ziehe? Geht sowas, ich hab keine Ahnung? Ja, geht. Prinzipiell könnte man auch die verbleibenden auf einen IO-Port legen, dann hat man memory banking. Ist aber schwierig im Kontext mit Variablen, die durch den Compiler darin verwaltet werden sollen, denn der rechnet nicht damit, dass er vor dem Zugriff noch an einem IO-Port herumfummeln muss. Wenn man nur eigene Puffer da unterbringen will, kann man das aber machen. x16 würde ich aber nicht nehmen, ist schade ums Geld. 32 Ki x 8 geht natürlich, würde man dann vorzugsweise ab 0x8000 adressieren. (Der Bereich von 0x1100 bis 0x7FFF spiegelt in so einer Konfiguration den Bereich 0x9100 bis 0xFFFF, aber den kann man einfach ignorieren.)
Hallo, vielen Dank für den Code und die Links... ...das mit dem Zufluss und dem Abfuss .. und der Rohrgröße... nun ich sample 1 sekunde lang mit 1kHz dann mache ich ca 10 Sekunden lang nichts. Der UART ist im Vergleich zu allen anderen Dingen, die man während der Samplezeit mahen kann, so langsam, dass er das alles begrenzt. Je mehr strings ich rausschreibe, umso langsamer wird dass, irgendwann schaffe ich das nicht mehr alle variablen innerhalb von 1ms rauszuschreiben. Dann puffe ich lieber, und schicke ein großes Paket in den 10 Sekunden danach nochwas.... Muß ich das im externen Speicher unbedingt auf dem Heap machen? Ich hatte die naive Vorstellung im global Scope einfach eine großes array anzulegen, und dann immerwieder reinzuschreiben so á la uint8_t value[10][1024]; direkt auf dem Stack... Schorsch
Schorsch schrieb: > Muß ich das im externen Speicher unbedingt auf dem Heap machen? Nein, natürlich nicht. Es ging mir da mehr darum, wie die Speicheraufteilung überhaupt ist. Das hier vielleicht noch dazu: http://www.nongnu.org/avr-libc/user-manual/mem_sections.html > Ich > hatte die naive Vorstellung im global Scope einfach eine großes array > anzulegen, und dann immerwieder reinzuschreiben > > so á la > > uint8_t value[10][1024]; > > direkt auf dem Stack... Nicht auf dem Stack. Externer Speicher ist immer langsamer als interner, dann machst du dir zwangsweise den ganzen Stack langsam. global scope ist aber auch nicht auf dem Stack. Pack' das in eine eigene memory section rein, die du dann mit dem Linker auf 0x801100 bindest.
Schorsch schrieb: > ...das mit dem Zufluss und dem Abfuss .. und der Rohrgröße... nun ich > sample 1 sekunde lang mit 1kHz dann mache ich ca 10 Sekunden lang > nichts. Der UART ist im Vergleich zu allen anderen Dingen, die man > während der Samplezeit mahen kann, so langsam, dass er das alles > begrenzt. Je mehr strings ich rausschreibe, umso langsamer wird dass, > irgendwann schaffe ich das nicht mehr alle variablen innerhalb von 1ms > rauszuschreiben. Dann puffe ich lieber, und schicke ein großes Paket in > den 10 Sekunden danach Dann wechsle doch die Plattform. Ein PIC32MX795F512L kann über sein eingebautes 100 MBit Ethernet und UDP etwa 8 Megabyte pro Sekunde rausblasen (2 Megabyte per TCP) und hat 128k RAM eingebaut. Du darfst alternativ auch ein äquvalentes ÄRMchen verwenden, aber ein PIC32 ist für den Anfang einfacher zu handhaben - Microchip hat alles für Dich vorbereitet. Das sind doch schon ganz andere Dimensionen, oder? fchk
Hallo Schorsch, 64kx8 ist nicht üblich. Verbaue ein 128kx8 und lege A16 auf GND oder für weitergehendes memory mapping auf eine Portpin. z.B: AS7C1025C-12JIN hab ich verwendet auf dem STK503 Borad. Bei RS: 538-227 Gruß Holger
Frank K. schrieb: > Dann wechsle doch die Plattform. Bitte lass deinen Evangelismus in den Threads, in denen er angebracht ist. Niemand hat hier die Frage gestellt, welche alternative Plattform besser geeignet wäre, und 10 Sekunden Pause sollten allemal genug sein, um die Daten an den Mann oder die Frau zu bringen. Wer sagt dir denn, dass Ethernet auf der Gegenseite überhaupt akzeptabel wäre? Holger Sch schrieb: > 64kx8 ist nicht üblich. Dürfte einfach damit zusammenhängen, dass RAMs allgemein jeweils um den Faktor 4 größer wurden von Generation zu Generation. 64 Ki x 8 wären 512 Kibit, eine unübliche Größe. Die übliche Staffelung war 16 Ki, 64 Ki, 256 Ki, 1 Mi. > Verbaue ein 128kx8 Oder eben 32 Ki x 8, falls das auch reicht.
Angehängte Dateien:
-
xmem.png
4,8 KB
Hallo, dem Kommentar mit den Plattformen von Jörg kann ich mich nur anschließen. PICs mögen mich nicht, und die Erfahrung der Vergangenheit hat mir gezeigt, dass man soweit möglich bei den Dingen bleiben sollte, mit denen man sich auskennt. Hab mal eine Schaltskizze angehängt, wo ich einen 32kx8 sram an den atmega64 gehängt habe. Hab ich alles richtig gemacht? In der Doku steht, dass man A15 in der Luft hängen lassen sollte, bzw noch als Portpin benutzen kann. ALE,WR und RE sind die ersten Pins von Port G. Ich hab einfach mal vermutet, dass man !OC vom Latch und !E vom SRAM an GND hängt? Als sram hätte ich den AS7C256A von farnell genommen (1.60 EUR find ich ok). Würde ich mich doch für einen größeren Entscheiden könnte ich einfach die zusätzlichen beinchen an beliebige Pins hängen, und meinen Adressraum erweitern, müsste dann natürlich die bereich "per Hand" umschalten, hätte also unterschiedliche Variableninhalte an der selben Speicherstelle, je nachdem wie die Adressleitungen stehen? Stimmts? Danke Georg
Schorsch schrieb: > Hab mal eine Schaltskizze angehängt, wo ich einen 32kx8 sram an den > atmega64 gehängt habe. Hab ich alles richtig gemacht? Hab' mir jetzt das Datenblatt deines RAMs nicht angesehen, aber sieht erstmal OK aus. > Würde ich mich doch für einen größeren Entscheiden könnte ich einfach > die zusätzlichen beinchen an beliebige Pins hängen, und meinen > Adressraum erweitern, müsste dann natürlich die bereich "per Hand" > umschalten, hätte also unterschiedliche Variableninhalte an der selben > Speicherstelle, je nachdem wie die Adressleitungen stehen? Stimmts? Dann müsstest du dir nochmal genau ansehen, welches Signal man darüber schalten muss.
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.