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
>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...
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
"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
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?
@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
Ich denke auch dass es erstmal reicht. Will nur wissen was "möglich" ist, bevor ich anfange.
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.
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?
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
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?
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
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
"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
aber nicht wenn's um einen ARM geht der externen RAM direkt ansteuern kann, und das verstand ich so bei Andreas Aussage ! Gruß Hagen
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?
>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
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!!!
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.
>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
An alle mit euren super Tipps : Kennt ihr den Unterschied zwischen kBit und kByte ???
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
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.
"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.
> "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
ki, etc. ist das einzig offizielle, normierte Bezeichnungsystem: http://de.wikipedia.org/wiki/Liste_der_Vorsilben_f%C3%BCr_Ma%C3%9Feinheiten
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
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.