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. 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. Sollte ich dazu irgendwie die funktionen importieren und dann ausführen? Wenn ja, wie sollten die funktionen gelesen werden, immerhin will ich ja ein kompiliertes programm laufen lassen, zudem will ich aber keinen eigenen Kompiler/Decompiler schreiben. BTW: eine andere Frage noch: Wie wird die geschwindigkeit eines AT-MEGA berechnet? Angenommen ich verwende einen 4MHz Quarz, würde der IC dann 4.000.000 ASM-Befehle in einer Sekunde schaffen oder sind es doch mehr?
Bentschi schrieb: > Ich habe nähmlich ein größeres projekt vor (etwa 2 MB) Wie kommst du auf diese Zahl? Die AVRs können keinen Code aus externem Speicher ausführen. Was man machen kann ist Daten von einem externen Speicher zu laden, z.B. von einer SD-Karte. Aber am besten erzählst du erst mal was du eigentlich vor hast. Bentschi schrieb: > Angenommen ich verwende einen 4MHz Quarz, würde der IC dann 4.000.000 > ASM-Befehle in einer Sekunde schaffen Maximal, allerdings dauern viele Befehle länger als einen Takt, entsprechend reduziert sich der Befehlsdurchsatz.
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.
Vielleicht solltest Du Dich erstmal mit der Architektur des AVRs befassen und den Unterschied zwischen Harvard und v.Neumann klären. Der AVR ist nämlich kein "Prozessor" im Sinne von Z80, 6520, 68000 oder x'86, sondern ein Controller, also ein fertiges Komplettsystem mit ein paar I/O-Ports, das man so benutzt, wie es ist. ...
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.
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.
Bentschi schrieb: > Wie wird die geschwindigkeit eines AT-MEGA berechnet? > Angenommen ich verwende einen 4MHz Quarz, würde der IC dann 4.000.000 > ASM-Befehle in einer Sekunde schaffen oder sind es doch mehr? 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.
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.
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. Du könntest sicher versuchen, den Code auf 256 KB runter zu quetschen, dann passt er in einen Atmega2560. Ansonsten ginge noch ATxmega, die gehen bis 384 KB Code und sind mehr oder minder kompatibel zu den ATmegas. Nachtrag: okay, die scheinen aber offensichtlich (noch) nicht am Markt zu sein. Eine Lösung, Code von extern auszuführen, gibt es so nicht. Entweder muss man interpretieren, oder den Code in den Flash-Speicher laden (und der verträgt nur 10.000 Schreibzyklen - und ist außerdem etwas langsam). Gruß David
Bentschi schrieb: > Aber die verbindung zwischen 2 AVRs würde aber dennoch 4 MHz betragen, > oder? 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. Mir scheint ein AVR einer der für diese Aufgabe am schlechtesten geeigneten Lösungen zu sein, die sich finden lässt. Warum ausgerechnet? Mikros mit internen 2MB Flash gibt es. Sind halt viel komplexer im Umgang. Und sind keine AVRs.
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.
Sorry, aber war der letzte Post ernst gemeint? Du kennst keinen ARM und willst so was bauen??? 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. 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. Gruß Tom
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 Gruß Tom
Es gibt etliche grosse Lieferanten, die preislich weit günstiger als Conrad liegen, und die keine Strafsteuer für Österreicher erheben. elpro.org und tme.eu beispielsweise.
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. > 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). > 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. > 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. > zudem will ich aber keinen eigenen Kompiler/Decompiler schreiben. Ja ne, is klar :P 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?
>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
Was ja auch ziemlich Human ist und die haben wirklich fast alles. Tom
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!
Bentschi schrieb:
> Und du hältst mich wohl für so blöd dass ich das nicht weis?
Ruhig Blut!
Anhand von kompakten und ausgesprochen verwirrend klingenden
Fragestellungen das Kenntnisniveau des Fragestellers einzuschätzen ist
eine höchst unsichere Sache.
Mal kommt auf Antworten dann "Hä? Bahnhof!" zurück (er klang besser als
er ist), mal "für was hältst du mich, du ..." (andersrum).
Über die Jahre erlebt man in Foren die seltsamsten Ideen. Da kommt schon
mal jemand auf den Gedanken, ein Handy (eigentlich ein GSM-Modem) selbst
zu bauen, um es durch Weglassen überflüssiger Software-Funktionen
deutlich kleiner bauen zu können.
... 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
Hallo Tobi, es würde mich wundern, wenn der XMega etwas nicht könnte, was die "einfachen" Megas können. Wie das genau geht, hängt davon ab, womit du programmierst. Bei Assembler gibt es spezielle Befehle, um Daten aus dem Flash zu holen, GCC hat spezielle LIB-Funktionen (finden sich in pgmspace.h), Codevision macht das AFAIK von selbst und transparent, wenn man Daten den Modifier "const" voran setzt.
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
Tobi schrieb: > Ich hoffe ich habe damit dem ein oder einderen das suchen etwas > erleichert. Und für diejenigen, die dann noch übrig bleiben. Das alles und noch viel mehr findet sich auch um AVR-GCC-Tutorial, welches diese Website zur freundlichen Kentnisnahme bereithält.
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.