Servus, ich baue immer mal wieder an einen kleinen Atmel-Rechner herrum. Diesen habe ich an eine "traditionelle PC-Architektur" anlehnen wollen und für meine Verhältnisse mal etwas "Oversized" gebaut, also mit sehr vielen Modularen Komponenten auf Atmel-Basis zum zusammenstecken, die ich immer wieder mal "erweitern" oder erneuern kann. Der Rechner soll "zukunftsorientiert" sein, und ich erhoffe mir, weiterhin sehr lange Spaß damit zu haben, zum austoben und lernen. Bin gerade dabei zu überlegen, wie ich mehr Ram auf die Kiste bringe, und versuche gerade Hardware dafür zusammenzustellen. Habe in einer Geraffel-Kiste zwei alte Notebook-Rams gefunden (SO-DIMM, 72 pin 16MB, D-Ram) und ich überlege diese dafür zu verwenden. Hab die damals sammt Sockel aus nem uhralt Notebook rausgerupft, und für "Irgendwann wirste es vielleicht noch brauchen" aufgehoben. Jetzt fällt mir da z.B. ein simples "D-Ram Modul" oder Display-Cache ein, und die Frage ob sich diese Riegel überhaupt mit einem Atmel benutzen lassen wüden? Hier ist das Pinout von den Riegeln: http://pinouts.ru/Memory/DimmSo72_pinout.shtml Mit diesen Rams Bestückt (8 Stück / 4 pro Seite): http://pdf1.alldatasheet.com/datasheet-pdf/view/37289/SAMSUNG/KM48C2100B.html Weiß jemand zufällig, wie diese Notebook-Riegel intern verschalten sind??? Ich frage lieber, bevor ich selber anfange das ganze durchzupiepsen, ich will ja auch nichts kaputt-messen. Im Internet habe ich komischerweise nichts aussagekräftiges gefunden. Das ist doch mit Sicherheit auch irgend ein IEEE / Etc - Standard??? Erstmal wollte ich wissen ob von der Verschaltung her die Steuersignale von jeweils "zwei" Chips immer direkt miteinander verbunden und herausgeführt sind? Und ist der Adress-Bus überall Parallel? Von der "Einteilung" am Pinout würde es etwa passen. Also dass man immer 16-Bits am Datenbus ansprechen kann?? (oder 32 Bits parallel, wenn man "zwei" Steuersignale gleichzeitig verwendet ??) Und falls es so ist, kann man die 16-Bit Daten dann runter auf 8 Bit bringen? Mit Bustreibern / Latches oder ähnlichem und einfach einen weiteren AdressBus-Pin zum ansprechen der "zweiten Daten-hälfte" dafür verwenden? Oder wie könnte man die Einteilung regeln? Dann noch die Frage, ob diese "Presence Detect"-Pins zum erkennen von der Anzahl verbauter Ram-Chips gut sein soll? Wenn ja, dann hätte ich mir eine "Adapter-Platine" mit entsprechenden 74HC-Teilen geätzt, die das ganze dann auf 8-Bit "drosseln" würden, damit man es "komfortabel" an einen Atmel packen kann, der dann das Stroben + Refreshen und das Bank-Switching erledigt - sowie ein "Index + Handler" für die "Adress-Bereiche" von Daten(-Typen) und Files bereitstellt, und sich von extern ansprechen lässt. Geschwindigkeit ist dabei erstmal zweitrangig. Voraussetzung ist, dass der Atmel mit 32MB - oder vorerst nur 16MB Refreshen hinterher kommt. (Hab das noch nicht ausgerechnet) Mir fällt gerade keine gute Lösung ein, die Riegel an nem Atmel zu verdrahten. Muss ja kein X-Ram sein, das geht mit Drams, dieser Anzahl an MB + so vielen benötigten Latches [soweit ich weiß] ja eh nicht. Der eigentliche Hintergrund ist nur, dass ich mit Hilfe der Riegel etwas "Platz sparen möchte", und auch mit "relativ" wenig Aufwand wirklich sehr viel Ram für´s Steckbrett oder Lochraster hätte... Meine Frage ist nun, ob es eine geschickte Möglichkeit gibt, diese Riegel an einem Atmel zu benutzen. Oder kennt jemand eine ganz andere oder bessere Methode für möglichst viel Ram auf Lochraster ??
user schrieb: > Was haste denn für nen "Atmel" Wahrscheinlich wäre es in dem Fall ein ATmega16 oder irgendwas auf 20Mhz getaktetes. Jedenfalls ein 8 Bit AVR. Genaueres ist noch alles offen. Am liebsten DIP. Netiquette: Sorry, ich hatte es nicht erwähnt. Edit: Könnte auch was anderes sein, wenn ich eh anfangen muss zu Ätzen. Hab aber noch keine Erfahrung mit z.B. 8/16-Bit XMega oder diesem UC3 gemacht, desshalb bleibt es wohl beim AVR.
PUSH ^^ ____ Habe gerade noch ein bisschen nach dem Thema "AVR + RAM" gesucht, und bin dabei zufällig auf eine Seite gestoßen, bei der jemand einen "32-Bit ARM Core" auf einem "8-Bit AVR" emuliert. Er hängt einen RAM dazu, um dann ein Linux zu booten. Auszug: > Ein Bootvorgang, der lediglich eine Shell startet, dauert zwei Stunden. > Etwas länger dauert es, die vollständigen Init-Skripte auszuführen: > Sechs Stunden. Hab so eine "Kombination" noch nicht gesehen - ist aber bestimmt nicht das erste mal, das so etwas versucht wird. Eigentlich interessant, wie weit einige mit den AVR´s gehen - irgendwie krank. http://www.pro-linux.de/news/1/18217/linux-auf-8-bit-prozessor.html http://www.youtube.com/watch?feature=player_embedded&v=nm0POwEtiqE Gruß
An die AVRs, die einen externen Daten-Adress-Bus haben, kann man ein SRAM anschließen. Ich hab vor Ewigkeiten mal ein 32kB SRAM an einen Mega161 gehängt... der inzwischen gar nicht mehr unterstützt wird :-( Zum Thema "traditionelle PC-Architektur": Bedenke, daß Du beim AVR Harvard-Architektur hast, Du kannst also nur Daten ins RAM legen, aber keinen Programmcode. Du hast also keine Möglichkeit, Programme zu laden o.ä.
Bronco schrieb: > Zum Thema "traditionelle PC-Architektur": > Bedenke, daß Du beim AVR Harvard-Architektur hast, Du kannst also nur > Daten ins RAM legen, aber keinen Programmcode. Du hast also keine > Möglichkeit, Programme zu laden o.ä. Gehen tut das schon, also mit etwas Aufwand \ Umstand im AVR + viel Ram. Habe vor einiger Zeit mal begonnen einen "Standard" für mich zu schaffen, bei dem solch eine "Runtime" möglich ist. Ich versuche es mal recht einfach zu beschreiben. Es ist vom Prinzip eine AVR-Software \ Betriebssystem mit einem "Interpreter" und einem "Parser", die eine andere Software von SD-Karte \ RAM \ ROM ausführen kann. - Datentypen, und dessen Eigenschafen sind fest im Controller drinnen implementiert. Jeder "Content" hat Flag-Bytes für Datenlänge, Ort, Funktion, etc. zugewiesen und diese landen in einem "Ram-Index-Table", was etwa mit einem File-System zu vergleichen wäre, und am Anfang des externen Rams liegt, und sich dynamisch aufbaut. - Der Content bzw. die Nutzdaten werden an die nächste freie Adresse, im hinteren Bereich des Rams geladen. Die Adresse rechnet der AVR über die Flags, und dem "Ram-Index-Table" aus. Damit lassen sich dann Daten als "Files" Laden, auch zwischen Adressen verschieben, und wieder löschen, etc. - Diverse "Befehle des AVR´s", und eigene Funktionen sind einem Integer zugeordnet. Also das eigentliche "Befehl aufrufen" läuft über Switches im AVR. Einer Funktionen kann als Parameter bis zu 8 Adressen des "Ram-Index-Tables" übergeben, die dann die "Werte" abholen. Zusätzlich gibt es einen Parameter für die Ziel-Adresse des Rams, wo der Return-Wert landet. Immer schön mit Datentyp, Länge, und Paar Status-Flags von der Funktion, die diesen Wert erzeugt haben. (für Return-Messages bzw. Error-Codes) Ich nenne das Teil mittlerweile "Boot-Loader". Gleich nach dem Einschalten versucht der AVR von einer SD-Karte oder einem EEPROM ein "Init-Script" aus einer festen Adresse zu laden. Dieses "Init-Script" ist bereits Bytecode, der die Funktionen des AVR-Parsers aufrufen kann. In der Regel werden damit zuerst diverse Daten von der SD-Karte oder dem ROM in das externe RAM geladen, und das "Ram-Index-Table" nebenher mitgeführt, bzw. statisch aus der Init übernommen. Deshalb auch der Name "Boot-Loader". Da sollen (einfach beschrieben) diverse Dienste geladen werden, die hintereinander ausgeführt werden. Versuche gerade das ganze um Threadring + Prioritäten zu erweitern. Nach dem Laden hab ich quasi ne Eingabeaufforderung, und kann damit direkt ein neues Proggi am AVR schreiben \ laden \ speichern, Parameter ändern, oder direkt den nächsten Befehl eintippen. Das Ganze ist ziemlich verzwickt, für mich schon viel zu komplex geworden, weil der AVR wirklich immer zu guggen hat, was er als nächstes machen darf. Das ist wirklich blöd zu beschreiben und total auf massig RAM und vielen statischen \ teilweise dynamischen Tabellen angewiesen. Der AVR werkelt da rein als CPU umher. Irgendwie hat das der Typ mit seinem 32-Bit Unbuntu auf´m AVR ja auch umgesetzt. Hatte ich das vorher gesehen, dann hätte ich wahrscheinlich auch einen anderen Prozzi emuliert, oder daran angelehnt. Kann mir noch jemand bitte bitte diverse Fragen vom ersten Post beantworten??? Habe leider immer noch nichts anständiges gefunden, was diese RAM-Riegel-Verschaltung angeht.
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.