Speicher erweitern AT-MEGA

Hi

Wow. Endlich mal jemand, der vor der ersten Programmzeile weis, wie groß 
sein Programm sein wird.

MfG Spess

Andreas Schwarz schrieb:
> Aber am besten erzählst du erst mal was du eigentlich
> vor hast.

Ich will einen Emulator auf einen AVR bringen.
Den Emulator selbst habe ich schon geschrieben der unter windows läuft.
Es handelt sich dabei um einen NES (Nintendo) emulator.
Die ausgabe über ein PSP-Display funktioniert bereits sowie die ausgabe 
von den guten alten Nintendo-gepiepse.
jetzt will ich nur das ganze NES-system auf nen AVR portieren und die 
ROMS dann per SD-Karte laden.
Natürlich werde ich für dieses projekt nicht nur einen AVR sondern 
mehrere verwenden.
Für den AVR der den CPU darstellen soll will ich eben jetzt die 
funktionen aus einem speicherbaustein laden (nicht der SD-Karte).
Der kompilierte code hat für windows bereits 483 KB (ohne 
Grafikanzeige).
Ich möchte mir aber etwas mehr speicher für spätere updates bereit 
halten, darum etwa 2 MB.

Natuerlich geht's. Alles eine Frage der Anforderungen. Man kann einen 
kleinen Interpreter in einen Mega64 schreiben und den auszufuehrenden 
Code in einem externen Flash halten. Fuer was SPS maesssiges reichts.

Hannes Lux schrieb:
> Vielleicht solltest Du Dich erstmal mit der Architektur des AVRs
> befassen und den Unterschied zwischen Harvard und v.Neumann klären.

Ich habe mich sowohl mit der architetur eines AVRs als auch der eines 
6502 (nicht 6520) der in einem NES verbaut ist befasst. Ansonsten könnte 
ich wohl auch keinen emulator für diesen IC schreiben ;-)

A. K. schrieb:
> Grobe Peilung 3 Mio AVR-Befehle pro Sekunde bei 4MHz Takt. Nur ist ein
> AVR Befehl ein "bischen" weniger mächtig als ein x86-Befehl.

A. K. schrieb:
> So wie ich ihn verstanden habe ist sein Nintendo-Interpreter/Emulator
> doch selber schon 1/2MB gross. Wenn nun dieser Interpreter/Emulator
> selber interpretiert werden muss, dann könnte am Ende die Performance
> etwas leiden.
>
> Das ganze klingt schon sehr bizarr.

Also wenn das mit deiner Peilung stimmt, dann mach ich mir keine sorgen 
um die Performanz, Da ich ja für die Grafikdarstellung, den CPU und den 
Mapper, jeweils extra einen AVR verwenden will.
Immerhin muss das system weder multitasking, noch 3D darstellungen oder 
sonstige schwierige berechnungen ausführen.

Aber die verbindung zwischen 2 AVRs würde aber dennoch 4 MHz betragen, 
oder?

Zacc schrieb:
> Natuerlich geht's. Alles eine Frage der Anforderungen. Man kann einen
> kleinen Interpreter in einen Mega64 schreiben und den auszufuehrenden
> Code in einem externen Flash halten. Fuer was SPS maesssiges reichts.

Genau das meinte ich, dass ich es nicht so machen will. Wenn es aber 
keine andere lösung gibt bleibt mir das wohl auch nicht erspart.

David Madl schrieb:
> Ich schätze einfach mal, dass die 483 KB große Windows-EXE neben
> diversem Header-Gekrempel auch ne Menge Daten drin hat, die keinen
> Programmcode darstellen.

Die 483 KB sind der eigentlich programmcode ohne OpenGL (das ich für die 
windows emulation verwende) und ohne den Windows-Funktionen selbst.
Inkludiert habe ich dann nur noch <cstdlib>. Zudem ist der code noch 
nicht vollständig (im sinne von "zu allen ROMs kompatiebel"), da ich 
erst 3 mapper in das programm eingebaut habe von etwa 150-200 die es 
giebt.
(1 mapper = ca. 100 Zeilen C-code)

Die bessere lösung währe es, ohne zweifel, den AVR-eigenen Speicher zu 
verwenden, aber ich glaube kaum dass der beim portierten NES reichen 
würde.
Zudem würde ich noch gerne ein paar kleine extras einbauen, wie bsp 
GameGenie, Screenshots speichern, etc. und natürlich die mapper 
erweitern.

A. K. schrieb:
> Meinst du die Kommunikation zwischen 2 AVRs? Dessen Schnittstellen sind
> eigentlich nicht für den Aufbau von Parallelrechnern konstruiert.
> Bischen was kann man mit synchroner UART zaubern, aber ein AVR kann in
> diesem Tempo entweder reden oder arbeiten, nicht beides.

Nein, ich meinte eigentlich dass ich eine kommunikation zwischen 2 AVRs 
über die IO-PINS herstellen möchte. Eigentlich wollte ich 8-16 Pins für 
die kommunikation und 1 Pin für einen taktgeber verwenden (falls nötig).
Diese IO-PINS verwenden ja dann die taktfrequenz des Quartz, wenn ich 
das richtig verstanden habe.

A. K. schrieb:
> Mikros mit internen 2MB Flash gibt es. Sind halt viel komplexer im
> Umgang. Und sind keine AVRs.

Naja mitlerweile habe ich mich damit abgefunden, das ich dennoch einen 
externen ROM-baustein verwenden werde und dafür einen Interpreter 
schreiben werde.

Jetzt ist mir nur noch die sache mit der geschwindigkeit der IO-PINS 
unklar.

Was genau soll diese Datenverbindung denn machen?

Du kannst sicher mit fast Quarzgeschwindigkeit einen Pin toggeln lassen. 
Problem ist nur, der Atmega macht dann nichts anderes mehr.

Der Atmega bringt ja mehrere Interfaces mit, UART, SPI, TWI usw.
Natürlich kannst du damit mehrere ICs verbinden und Daten austauschen.
Nur wirst du niemals mit 4MHz die Daten gleichzeitig erzeugen, senden, 
empfangen und verarbeiten können.

So ein Atmega macht jede Operation hintereinander. Sicherlich kannst du 
über Interrupts, Sendepuffer etc. einen quasi-Parallelbetrieb erreichen. 
Dabei geht aber die Geschwindigkeit in den Keller.

Vielleicht solltest du dich doch erstmal mit der Funktionsweise von 
einem Atmega befassen, bevor du das Projekt angehst.
Vor allem wenn man aus der PC-Programmierung kommt wundert man sich doch 
erstmal, was diese kleinen Dinger alles nicht können und wie lange so 
ein Rechenschritt doch dauert.
Das ist eben etwas völlig anderes, als in seinem bequemen Betriebssystem 
nochmal einen neuen Task zu starten, wenn Daten irgendwo hin müssen.

Ein AVR ist für dieses Projekt eine völlig ungeeignete Plattform. 
Mangels Speicher und Geschwindigkeit.

Eher geeignet wäre ein ARM. Genug Speicher, genug Speed.

Also da muss ich jetzt doch auch mal was posten.
Wie "niemand" schon gesagt hat, ist für das Projekt ein ARM vielleicht 
besser geeignet. Beim rumklicken auf dieser Website ist mir da der 
LPC2000 zuerst mal ins Auge gefallen (siehe: 
http://www.mikrocontroller.net/articles/LPC2000).
Der hat bis zu 512kB ROM.
Ich denke mit dem würde man bei sowas besser fahren!

Ok, die Idee ist wirklich Gold wert.
Wusste bis heute leider nicht dass es auch ARM gibt.
Hab schon im internet gestöbert und der beste ARM den ich kriegen kann 
ist
tatsächlich ein LPC2000, weil Conrad leider nix besseres hat als:
>MICROCONTR. ARM7 LPC2378FBD144,551 NXP

Ich habe auch schon eine Idee, wie ich den programmcode unter 512 KB 
halten kann. Dafür muss ich aber dennoch einen externen ROM verwenden, 
sowie einen externen RAM.

Dazu lege ich einfach die Mapper auf den externen ROM, da es ja wie 
gesagt etwa 150-200 Mapper gibt und ich aber nur einen Mapper in der CPU 
benötige, währe das wahrscheinlich die einfachste Lösung. Der Mapper 
wird dann einfach beim laden eines Spieles in die CPU geladen. Danach 
muss nicht mehr auf den externen ROM zugegriffen werden.

Um den externen RAM komme ich sowieso nicht herum, da es sicherlich 
keinen Microcontroller gibt der etwa 1-2 MB RAM bereitstellt. Der RAM 
wird eigentlich nur für die "Memory Maps" des NES benötigt. Dennoch 
mache ich mir um die Performanz keine sorgen, da im RAM nur etwa 50 
KB/sek geschrieben bzw gelesen wird.

Naja, also soweit ist mein problem gelöst.
Ich werde dann wieder posten wenn mein emulator läuft.
Oder, wenn noch probleme auftauchen sollten.

Thomas Burkhart schrieb:
> Sorry, aber war der letzte Post ernst gemeint? Du kennst keinen ARM und
> willst so was bauen???

Jap, der war ernst gemeint.
Ich will nur dazu sagen, dass ich schnell kappiere und bereits mehrere 
Programmiersprachen behersche.
Das Datenblatt habe ich mir angesehen, jetzt noch 2-3 gute Tutorials 
lesen zwischendurch noch ein paar mal einen blick auf das Datenblatt 
werfen, eine testschaltung aufbauen um zu sehen ob ich es verstanden 
habe und wenns funktioniert steht ja nix mehr im weg, oder?

Thomas Burkhart schrieb:
> Es gibt sicherlich jede Menge Prozessoren die Du noch nicht angeschaut
> hast. Außerdem gibt es nicht nur Conrad. Schau mal bei Reichelt oder in
> letzter Zeit von mir immer beliebter wenn auch etwas teuerer (aber
> Conrad ist ja auch ne Apotheke) bei RS-Components, die haben fast alles.

Also das mit dem ARM das reicht mir, ich bin mir ziemlich sicher dass 
die Leistung für dieses Projekt reicht.

Da ich in Österreich wohne und ein Conrad gleich um die ecke ist, ist 
mir Conrad lieber, so spare ich mir dann auch noch die Versandkosten. 
Würde ich bei Reichelt bestellen müsste ich eine mindestbestellmenge von 
150€ zusammenkriegen und das ist ja wohl zuviel Geld wenn ich doch nur 
einen lächerlichen ARM und eine handvoll kleinkram kaufen will.

Thomas Burkhart schrieb:
> ARM ist sicherlich die bessere Alternative Oder schau Dir mal XMOS oder
> den Propeller von Paralax an, die sind beie schon für KOmmunikation von
> mehreren Prozessoren vorbereitet.

Ich denke, dass wenns ein ARM allein schaffen kann, dass es auch die 
beste lösung ist. Aber trotzdem danke für den Tipp, bei gelegenheit 
werde ich es mir genauer ansehen.

>Kuck mal bei RS rein, die liefern zumindest in Deutschland
>evrsandkostenfrei ohne mindestmenge

In Österreich kostet der Versand 3,40 EUR.
http://at.rs-online.com/web/generalDisplay.html?id=aboutRS&file=terms2

Michael G. schrieb:
> Bentschi schrieb:
>> Wollte mal eben fragen ob jemand eine Idee hat wie ich den
>> Prgrammspeicher eines AT-MEGA erweitern kann.
>> Ich habe nähmlich ein größeres projekt vor (etwa 2 MB) und der speicher
>> eines AT-MEGA oder sonstigen ICs wird dazu viel zu wehnig.
>> Also will ich einen externen Speicherchip oä. mit dem AT-MEGA
>> kommunizieren lassen.
>
> Wie schon gesagt: Du verwechselst den Programmspeicher wahrscheinlich
> mit Hintergrundspeicher. Dass Du tatsaechlich 2MB brauchen wirst, halte
> ich fuer mehr als nur etwas unwahrscheinlich.

Ich verwechsle gar nix.
Und wenn ich alle mapper und features einbauen wollte, würde ich schon 
auf 2 MB kommen.
Ich habe mich aber jetzt für einen anderen weg entschieden.

>> So, jetzt zum eigentlichen problem:
>> Wie stellt man es an, dass man jetzt beispielsweise funktionen aus dem
>> externen chip auf dem AT-MEGA ausführen kann.
>
> Geht nicht, da die Architektur das nicht vorsieht. Man kann bei den
> groesseren Megas lediglich den Datenspeicher auf 64KByte erweitern (16MB
> beim Xmega).

Geht ja wohl, und genau so will ich es jetzt auch machen.
Nur eben dass ich funktionen für die Mapper extern speichern will.
Diese funktionen, die in einer Art compilierter form vorliegen, werden 
von einen Interpreter gelesen und der Interpreter führt dann lokale 
funktionen daraus aus.

>> Sollte ich dazu irgendwie die funktionen importieren und dann ausführen?
>
> Geht nicht, da die Architektur Programm- und Datenspeicher trennt. Man
> kann lediglich mit Trickserei den Programmspeicher als Datenspeicher
> missbrauchen.

Und du hältst mich wohl für so blöd dass ich das nicht weis?
Was ich damit sagen wollte ist, dass es vielleicht besser währe so eine 
funktion (compilierte form) zuerst in den RAM -> Random Access Memory 
(oder zu deutsch schreib/lese speicher) zu laden und mit dem Interpreter 
von da aus zu bearbeiten.

>> Wenn ja, wie sollten die funktionen gelesen werden, immerhin will ich ja
>> ein kompiliertes programm laufen lassen
>
> Du solltest Dich erst einmal mit Grundlagen befassen, bevor Du solche
> Mondprojekte anstrebst. Dann wird das vielleicht auch mal irgendwann
> etwas.

Sag mal, kannst du eigentlich lesen?
>> Die ausgabe über ein PSP-Display funktioniert bereits sowie die ausgabe
>> von den guten alten Nintendo-gepiepse.
Also wenn ich soetwas programmieren kann, dann muss ich mich wohl 
bereits mit den grundlagen beschäftigt haben. Und dass ist auch nicht 
alles was ich bereits mit dem AT-MEGA gemacht habe.

>> zudem will ich aber keinen eigenen Kompiler/Decompiler schreiben.
>
> Ja ne, is klar :P

Ok, ich gebe zu die wortwahl ist nicht gerade die beste, dennoch muss 
ich einen Kompiler schreiben. Und was ich mit Decompiler meinte währe 
dann der Interpreter der dann in den Flash des Microcontrollers kommt.

> An die anderen: Auch wenn es Euch Spass macht. Dem Jungen jetzt auch
> noch einen ARM vorzuschlagen, duerfte wohl an Sinnlosigkeit kaum zu
> ueberbieten sein, oder?

An die anderen: Vielen dank für eure hilfe.

Sonst noch fragen?

Bentschi schrieb:
>> An die anderen: Auch wenn es Euch Spass macht. Dem Jungen jetzt auch
>> noch einen ARM vorzuschlagen, duerfte wohl an Sinnlosigkeit kaum zu
>> ueberbieten sein, oder?
Das verstehe ich jetzt auch nicht ganz! Was ist daran so schlimm 
jemanden einen ARM vorzuschlagen!?


> An die anderen: Vielen dank für eure hilfe.
Bitte und viel Erfolg!

... Sonst noch fragen? ...

Nein, aber ich freue mich auf deinen Emulator.

>Man kann lediglich mit Trickserei den Programmspeicher als Datenspeicher
missbrauchen.

Mir geht gerade der Datenspeicher aus, wobei ich noch einiges an 
Programmspeicher frei hätte. Es geht hauptsächlich um Strings für 
Fehlerausgaben, die zur Laufzeit nicht mehr geändert werden.

Wie funktioniert denn die "Trickserei" mit der man den Programmspeicher 
als Datenspeicher missbrauchen kann? Mein Controller ist zwar ein XMega, 
aber eventrzuuell geht da ja da auch.

Vielen Dank
Tobi

Da werden Sie geholfen...

Ich verwende den GCC (glatt vergessen anzugeben).

Das Macro PSTR("Das ist der Teststring") legt den String im 
Programmspeicher ab. Dann gibt es in der LIB alle üblichen 
string-Funktionen (pgmspace.h) mit der Endung _P für den 
Programmspeicher, beispielsweise die sprintf_P(). Einzelne bytes können 
beispielsweise mit gm_read_byte_near(address_short) aus dem 
Programmspeicher ausgelesen werden, wobei das Attribut PROGMEM die 
Variable bei der Definition in dem Programmspeicher ablegt.

Ich hoffe ich habe damit dem ein oder einderen das suchen etwas 
erleichert.

Danke noch mal an Detlev.

Gruß
Tobi