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.
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.
