mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RAM-Erweiterung


Autor: Michael Stather (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe vor Kurzem diese Seite entdeckt und will jetzt auch mal in die
Mikrocontroller-Programmierung einsteigen.
Ich habe gesehen dass die Controller zwar relativ gute Leistung haben,
aber nur einige KB an RAM. Ist es möglich hier normale kleine
RAM-Bausteine zB von Conrad anzuschliessen. Habe gehört dass es zum
Teil Sockel auf den Starterboards gibt, ich würde jedoch gerne ein
selbstgebautes/Bausatz Board nehmen.
Wie ist dann die Ansteuerung des Speichers, gibt es Compiler die
"externen" Speicher unterstützen oder muss ich da selbst die
Speicherverwaltung programmieren?
Vielen Danke für Eure Hilfe :) Habe schon im Wiki gesucht aber leider
dazu nichts gefunden.

Michael

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie ist dann die Ansteuerung des Speichers, gibt es Compiler die
"externen" Speicher unterstützen oder muss ich da selbst die
Speicherverwaltung programmieren?

Ja, geht.
Für die ersten Projekte wirst du das vermutlich aber eher nicht
brauchen...Und wie immer kommt es darauf an, was man mit der Mühle
machen will...

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für 'kleine RAM-Bausteine' meinst Du? Generell kannst Du an
praktisch jeden µC serielle Speicherbausteine anschließen. Einige der
'größeren' AVRs unterstützen parallele SRAMs (Mega8515, Mega64/128
und größer). Anschlussart steht im jeweiligen Datenblatt. Die
Speicherverwaltung sollte eigentlich automatisch über den Compiler
gehen, wenn in den Einstellungen bzw. im Makefile das korrekte
Speichermodell eingestellt wird. Der Zugriff unterscheidet sich dann im
Prinzip nicht vom Zugriff auf das interne RAM. Bei parallelem SRAM gehen
aber je nach Größe bis zu 2 komplette I/O-Ports für allgemeine Zwecke
'verloren'.

Gruß

Johnny

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich habe gesehen dass die Controller zwar relativ gute Leistung haben,
aber nur einige KB an RAM."


Das wurde mit Absicht so gemacht, damit die Programme klein und schnell
sind.

Wenn man einfach mal überlegt, welche Variablen global sein müssen und
welches Format sie wirklich brauchen, nimmt man der CPU ne ganze Menge
unnütze Arbeit ab.

Zusätzlich hat man die Gewähr, daß der Speicher immer ausreichend ist
und man nicht, wie bei PC-Programmen, ständig mit Speicherfehlern
vollgenölt wird, weil der Speicher Pi mal Daumen ohne Sinn und Verstand
zugewiesen wurde.


Ob ein MC externen Speicher direkt unterstützt, steht im Datenblatt,
z.B. fast alle 8051 (z.B. AT89C51CC03) und einige AVRs (z.B. ATMega162)
tun das.


Peter

Autor: Michael Stather (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für Eure Antworten :)
Es stimmt dass ich das am Anfang nicht brauche, aber da ich was mit
Grafik machen möchte bräuchte ich irgendwann schon mehr RAM. Außerdem
würde mich schon interessieren wie leistungsfähig das Ganze ist, wenn
ich mich da richtig reinhänge.

@johnny.m

Das ist sehr interessant. Dh ich kann einfach bei avr-gcc angeben dass
ich externen RAM nutzen will? Und wie groß kann der Speicher maximal
sein? Wegen den 2 Ports, der Controller hat ja bis zu 32 davon, das
macht ja IMHO nix aus. Oder meinst du 2x8 Ports?

Autor: Andreas Dörr (ADoerr) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter: Ich glaube (nicht wissen ;)), daß die Hersteller den RAM aus
anderen Gründen klein halten. Statischer Ram hat einen hohen
Flächenverbrauch und macht daher den Die schnell groß, was wiederrum
die Ausbeute drückt und die Kosten pro Chip steigen lässt.
Die Hersteller suchen daher einen Kompromiß aus RAM-Größe und
Nutzbarkeit bei erwarteten Programmen/Anwendungen/Algorhytmen.

Da man einen Algorhytmus ziemlich direkt implementiert (ohne viel
Schnickschnack wie anständiges Betriebsystem oder sonstigen
"Spielereien") kommt man mit nur wenig RAM für die normalerweise
wenig nötigen Variablen aus. Das Meiste ist nämlich statisch
(Programmcode, konstante Werte/Texte) bzw verändert man selten
(Konfigurationsdaten). Das landet dann im EEPROM bzw. Dataflash.

Du hast natürlich Recht damit, daß diese "Einschränkungen" einen zu
einem effizienteren und kompakteren Code zwingen, aber ich bezweifel,
daß dies die Motivation der Hersteller für kleine RAM-Speicherblöcke
sind. Sonst gäbe es kaum nur minimal abweichende Typen innerhalb einer
Familie, die sich teils in grade mal 256Byte RAM unterscheiden (ok,
dann normal auch beim EEPROM und eventuell bei der integrierten
Peripherie).

@Michael: Also, wenn Du nicht grade ein Projekt umsetzen willst, bei
dem Du "große" Datenmengen quasi parallel bearbeiten mußt, ist der
kleine interne RAM in der Regel ausreichend. Ist er es nicht, dann
gibt's meist nen uC in der Familie, der etwas mehr RAM besitzt oder Du
wechselt gleich zu einer Familie, die von vornerein relativ viel RAM hat
(z.B. welche mit nem ARM-Core).
Mit "quasi parallel" meine ich, daß dein Algorhytmus deine Daten im
Block bearbeiten muß und nicht sequentiell nacheinander.

Bis denne Andreas

Autor: Michael Stather (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke auch dass es erstmal reicht.
Will nur wissen was "möglich" ist, bevor ich anfange.

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

noch ein kleiner Tipp:
Das mit dem wenigen RAM bei den µC's (insbesondere AVR) ist wirklich
ein Übel. Du wirst schnell merken, dass du 80%-90% der Zeit deiner
Projekte mit dem schreiben der Software verbringst. Wenn man dann auch
noch dauernd mit RAM Beschränkungen zu kämpfen hat (z.B. integrier mal
eben ein FAT-Dateisystem...) ist das sehr sehr ärgerlich.

Ich würde daher immer zu µC's mit viel internen RAM raten z.B. ARM7
Derivate.

Du kannst besser mal 2EUR mehr für den µC ausgeben - dafür aber viel
schneller die SW fertig stellen.

Autor: Michael Stather (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja ich bin halt Anfänger, und ich hab gesehen dass ARM erstens nicht
so billig ist und zweitens nicht so einfach *ggg
Wenn ich da RAM-Module anschliessen kann müsste es doch gehen.
Interessiert mich nur noch wieviel. 64kb wegen 16-Bit addressbus?

Autor: Andreas Dörr (ADoerr) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So teuer sind die ARM's auch nicht. Als Anfänger wirst Du wohl kaum in
eine Massenproduktion einsteigen ;), erst da werden Stückkosten
wirklich relevant. Höchstens Du "zerlegst" am laufenden Band einen,
aber dann machst Du was grundlegendes falsch. Die wirklich großen
Kosten entstehen eher durch das sonstige nötige Equipment, das man in
seinem Labor so braucht (Netzteile, Lötstation usw.). Aber ich geh mal
davon aus, daß das schon bei Dir vorhanden ist.
Vielleicht wär es zu Anfang besser, Du kaufst Dir ein fertiges
Entwicklerboard. Solche für ARM's gibt's schon für wenig Geld. Da
drauf lässt es sich in Ruhe entwickeln und testen.
Zusätzlicher externer RAM kostet auch Geld und Du kommst da bestimmt
auf in etwa das gleiche als wenn Du Dir gleich einen uC anschaffst, der
über genug internen RAM verfügt. Solltest zusätzlich bedenken, daß der
RAM mittels Adress-, Daten- und Steuerleitungen angebunden werden will.
Bei einem 64kbit RAM kommst Du da schon auf 27 I/O-Ports, die Du beim uC
belegen mußt (parallele Variante). Die fehlen Dir bei deinen Projekten
und schränken deine Auswahl eines passenden uC schon mal ein. Machbar
ist es aber ;).

Hast Du überhaupt schon konkrete Projektideen, die Du umsetzen willst?
Wenn ja, dann nenne uns die mal, dann kann man Dir besser sagen, was
ausreicht.

Bis denne, Andreas

Autor: Michael Stather (kyromaster)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also schonmal Danke für Eure vielen Ratschläge :)
Habe mit ein paar Kommilitonen vor, ein Projekt für "Technische
Informatik" zu entwickeln. Was genau steht noch nicht fest, deswegen
hab ich auch nach den Möglichkeiten gefragt. Wird vllt ein MP3-Player
oder eine Art Gameboy mit TFT-Display, irgend sowas.
Ich habe halt zu den AVR-yCs viele Artikel und Schaltpläne gefunden,
und auch die gcc-toolchain finde ich sehr gut. Auch habe ich gelesen
dass ARM schwieriger sind zu programmieren. Wir haben aber noch nicht
entgültig entschieden ob AVR oder ARM.
Ich will aber auch so mal was mit Mikrocontrollern machen, und will
dann halt möglichst bei einem Typ bleiben, wenn ich mit dem schon
Erfahrungen gemacht hab.
Du hast geschrieben ein 64 kBit RAM hat 27 ports. So viele ham die AVRs
ja zum Teil gar nicht.
Mich würde es wirklich interessieren was genau möglich ist, da es blöd
wäre später an die Grenzen zu stoßen. Dir megaX Serie von AVR, wieviel
externes RAM unterstützt diese denn? Also sowohl seriell als auch
parallel, so dass man den Heap (und eventuell noch den Stack) einfach
aufs externe RAM legen kann?

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind nicht 27 weil die unteren 8 address bits gelatcht sind

Autor: Michael Stather (kyromaster)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also 27 - 8 = 19?

Autor: Kai Riek (kairiek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, Ein externer RAM am AVR benötigt 19 Pins. 16 Stück für die Adresse,
wobei A0 bis A7 in einem Latch gespeichert werden (siehe Lupin) und
somit auch als Datenleitungen verwendet werden können. Die drei übrigen
sind Steuerleitungen. Eine fürs Lesen, eine fürs Schreiben und die
dritte fürs Latch.

MFG

Kai

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am µC brauchst Du zwei Ports, wobei einer (Addressbus High-Byte) je nach
Größe des verwendeten RAM evtl. nur teilweise genutzt wird. Der
Addressbus ist 16 Bit breit und der Datenbus 8 Bit. Die 8 LSB des
Addressbus werden auch als Datenbus genutzt, weshalb man das Address
Latch braucht. Zusätzlich zu den Daten- und Addressleitungen braucht
man noch die Signale ALE (Address Latch Enable), RD (Read) und WR
(Write). Das macht dann nominell 16 + 8 + 3 = 27 Signale, von denen
aber 8 am µC doppelt belegt sind. Die Beschaltung für die externen RAMs
(z.B. Address Latch) ist in den Datenblättern der entsprechenden
Controller enthalten. Als Address Latch kann man z.B. einen HCT373 o.ä.
nehmen.

Gruß

Johnny

Autor: Andreas Dörr (ADoerr) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte halt eines ohne "latchen". Das macht dafür den Zugriff
langsamer ;).

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schneller ;) meinst du wohl.

Gruß Hagen

Autor: Andreas Dörr (ADoerr) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, ich meinte natürlich "mit latchen langsamer".

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich hatte halt eines ohne "latchen". Das macht dafür den Zugriff
langsamer ;)."


Stimmt !

Die LD- und ST-Befehle latchen immer, wenn man extern zugreift.

Will man das Latch einsparen, kann man sie nicht nutzen und muß alles
zu Fuß machen (Lesen = 4*OUT+NOP+IN) und das ist erheblich langsamer.


Peter

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber nicht wenn's um einen ARM geht der externen RAM direkt ansteuern
kann, und das verstand ich so bei Andreas Aussage !

Gruß Hagen

Autor: Michael Stather (kyromaster)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich also 64 kBit an einen AVR anschliessen würde, hätte ich mit dem
integrierten SRAM ja zB 68 kb, was mit 16-Bit Addressierung ja nicht
geht. Werden dann die letzten 4 kb des externen Speichers
"abgeschnitten?
Und diese seriellen RAMS, gibt es die auch bis 64kB, und werden die
auch vom Compiler/Linker unterstützt?

Autor: Kai Riek (kairiek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Werden dann die letzten 4 kb des externen Speichers
"abgeschnitten?

Jupp is leider so. Wenn du den oberen Speicherbereich (restliche 4KB)
auch nutzen möchtest, kannst du dies aber "manuell" machen, indem du
u.a. A15 per Software schaltest und nicht vom RAM Interface. Dann mußt
du leider immer zwischen zwei 32KB Bänken hin und her schalten. Wie's
genau geht steht z.B. im Mega64 Datasheet (S. 34)...

MFG

Kai

Autor: Ludwig Wagner (lordludwig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also...

ich habe an einen Mega162 nen externen 32kb RAM angeschlossen und habe
damit keine probleme. Sie lassen sich wie der interne RAM ansprechen,
das is sehr praktisch.

Das mit den vielen Pins habe ich folgendermasen gelöst:

Für Ram-Bearbeitung:
  ldi temp, 0b01001000
  out SFIOR, temp

Für LCD-Daten:
  ldi temp, 0b01111000
  out SFIOR, temp

So lassen sich die pins nutzen solange du nicht auf das RAm
zugreifst!!! Das funktioniert problemlos wenn das was man an die Pins
anschließt einen Enable Pin hat, sonst stören die anliegenden pegel das
RAM. Ich habe z.b. ein 16x4 display drann und das geht ohne probleme!!!

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein externes ram braucht immer einen takt waitstate zum latchen ist also
langsamer als das interne. Außerdem haben hier einige das CS signal
übersehen, wenn man das nicht verbindet gibt es chaos im externen RAM
denn die address signale beim zugriff auf das interne RAM werden
solange das memory interface aktiv ist auf die externen Ports
geleitet.

Das steht ja auch alles im Datenblatt...

Serielle Speicherbausteine lassen sich logischerweise nicht an einen
AVR zur Codeausführung an binden.

Autor: Kai Riek (kairiek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Außerdem haben hier einige das CS signal
übersehen, wenn man das nicht verbindet gibt es chaos im externen RAM
denn die address signale beim zugriff auf das interne RAM werden
solange das memory interface aktiv ist auf die externen Ports
geleitet.

Das mit dem Chaos versteh ich leider nur halb...

Aber der Vollständigkeit halber:
Beim Anschluß des RAMs an den AVR, nCS <-> GND, nWE <-> nWR und nOE <->
nRD (RAM <-> AVR).

MFG

Kai

Autor: .... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An alle mit euren super Tipps : Kennt ihr den Unterschied zwischen kBit
und kByte ???

Autor: Kai Riek (kairiek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Unterschied zwischen Bit und Byte ist doch wohl klar? 8 Bit -> 1
Byte. Und das k ist dann der Faktor 1024. Also: 8*1024 = 8192 Bit ->
1024 Byte.

MFG

Kai

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pedantische Anmerkung:

k steht für den Faktor 1000 (kilo)

ki steht für den Faktor 1024 (kilo-binary)

... bevor sich das durchsetzt, wird wohl die Lebensmittelwerbeindustrie
freiwillig davon abkommen, eine Kilokalorie als Kalorie zu bezeichnen.

Autor: .... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"ki" ist aber auch nix offizielles. Teilweise wird das auch durch ein
großes bzw. kleines "k" verdeutlicht.

Warum wird dann oben aber immer von 64kBIT gesprochen ??? Das sind nur
8kByte und dafür braucht man keine 16 Adressleitungen.

Autor: André Kronfeldt (freakazoid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "ki" ist aber auch nix offizielles. Teilweise wird das auch durch
ein
> großes bzw. kleines "k" verdeutlicht.
Das ist dann aber bei 'Mega' auch keine Lösung (m = Milli). Okay by
Bit/Byte macht Milli keinen Sinn, aber bei anderen Einheiten schon.

Grüße, Freakazoid

Autor: Ingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ki, etc. ist das einzig offizielle, normierte Bezeichnungsystem:

http://de.wikipedia.org/wiki/Liste_der_Vorsilben_f...

Autor: Andreas Dörr (ADoerr) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ist ja interessant. Nicht mal die c't hat auf diese offiziellen
Vorsiblen hingewiesen, obwohl sie immer wieder auf die unterschiedliche
Verwendung von (meist) Mega- und Giga- durch die Industrie hinweist.
Ich hör hier zum ersten mal davon (obwohl ich schon seit 21 Jahren mit
Computer rumhantier).
Naja, wird sich wohl nicht mehr durchsetzen, wenn es nicht mal nach 6
Jahren so gut wie keiner kennt ;). Auch wenn es vielleicht nicht dumm
wär.

Bis denne, Andreas

Autor: .... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dann nehmen wir halt Ki und Mi aber nicht 64KiBit statt 64KiByte.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.