mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR Core Emulation Source Code in C?


Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

weiß jemand, ob es einen in C-geschriebene Emulation für einen AVR-Kern 
gibt?

Gruß,
chris

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Linux gibt es z.B.:
       simulavr is free software, covered by the GNU General
       Public License, and you are welcome  to  change  it
       and/or  distribute copies of it under the conditions
       of the GNU General Public License.

Ob er in C geschrieben ist, weiß ich nicht, aber die Chancen stehen gut.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klaus@i4a:~ > simulavr --list-devices
  at90s1200
  at90s2313
  at90s4414
  at90s8515
  atmega8
  atmega16
  atmega103
  atmega128
  at43usb351
  at43usb353
  at43usb355
  at43usb320
  at43usb325
  at43usb326

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

habe ich auch gerade hier entdeckt: http://gitorious.org/simavr#more
Ich würde gerne einen Blick auf die Sourcen werfen, aber irgendwie 
scheint das nicht so ganz einfach ....

Ich probiere weiter ...

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR-Simulation

SimulAVR started out as a C based project written by Theodore Roth in 
2001. Klaus Rudolph started then in 2004 to rewrite the hardware 
simulation part in C++.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Hallo Klaus,
>
> habe ich auch gerade hier entdeckt: http://gitorious.org/simavr#more
> Ich würde gerne einen Blick auf die Sourcen werfen, aber irgendwie
> scheint das nicht so ganz einfach ....
>
> Ich probiere weiter ...

why?
http://gitorious.org/simavr/simavr/blobs/master/si...
http://gitorious.org/simavr/simavr/blobs/master/si...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke.
SimulAVR scheint doch schon etwas größeres zu sein.

Meine spontane Idee war folgende: Ich simuliere einen Attiny13 auf einem 
Atmega32. Wird vermutlich ein wenig langsam ( wie langsam? vielleicht 
Faktor 20? ). Das schöne daran: Man kann mehrere Attiny13 auf einem 
Atmega32 laufen lassen.
Der Nachteil des Codes von SimulAVR für das Projekt: Der Code ist zu 
fett und nicht auf Geschwindigkeit optimiert.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ok, danke.
> SimulAVR scheint doch schon etwas größeres zu sein.
>
> Meine spontane Idee war folgende: Ich simuliere einen Attiny13 auf einem
> Atmega32. Wird vermutlich ein wenig langsam ( wie langsam? vielleicht
> Faktor 20? ). Das schöne daran: Man kann mehrere Attiny13 auf einem
> Atmega32 laufen lassen.
> Der Nachteil des Codes von SimulAVR für das Projekt: Der Code ist zu
> fett und nicht auf Geschwindigkeit optimiert.

WTF???
Schreib dir nen Scheduler!

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schreib dir nen Scheduler!
Nein, darum geht es nicht.

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
>>Schreib dir nen Scheduler!
> Nein, darum geht es nicht.

Ich geb dir nen Tipp:
Schnapp dir dafür nen ARM11 oder nen Cortex-R, mach ne C++ Klasse draus 
und instantiiere die für jeden emulierten AVR.

Ich glaub, der C64 Emulator lief erst ab dem Pentium einigermaßen fix.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Random
Schau, nicht jedes Projekt in diesem Forum macht Sinn, aber vielleicht 
trotzdem Spaß:
Beitrag "KIM-1 in AVR?"
Beitrag "CP/M auf ATmega88"

Und da ich nun einmal gerne Projekte verwirkliche, die sonst noch 
niemand so gemacht hat, will ich einen AVR auf einem AVR emulieren.

Tu mir den Gefallen und zerbrich Dir nicht meinen Kopf.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:

und warum brauchst du dafür die c-Quellen? Sich alles aus dem netz 
landen, compiliern zählt für mich nich als
> einmal gerne Projekte verwirkliche, die sonst noch
> niemand so gemacht hat

Spannender ist doch ein Intel I7 auf einem Atmel zu simlieren.

Autor: Max christian P. (_maya_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den AVRFreaks bin ich mal über ein recht junges SimulationsProjekt 
gestolpert. Die sourcen gab's dort auch. Ah ja- gefunden:
http://www.avrfreaks.net/index.php?name=PNphpBB2&f...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Spannender ist doch ein Intel I7 auf einem Atmel zu simlieren.

An so was ähnliches habe ich schon gedacht. Den Propeller ( 32 Bit , 8 
Core) habe ich spasseshalber schon mal auf einem Atmega32 emuliert ( Den 
COG Speicher habe ich auf 512Bytes begrenzt und nur 2 COGs implementiert 
).

Interessant wäre eine ARM-Emulation auf einem AVR.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich könntest du deinen Prozessor doch emulieren (statt ihn
zu simulieren), d. h. du nutzt dir aus, dass dein tatsächlicher
Prozessorkern ja dem des Zielsystems entspricht...

Ansonsten kannst du noch avrsim angucken (ich glaube, so heißt es),
ein minimalistischer CPU-Simulator, der (im Gegensatz zu simulavr)
keinen Anspruch auf eine komplette Simulation des Kerns legt, dafür
aber schnell sein will.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Joerg
>Eigentlich könntest du deinen Prozessor doch emulieren (statt ihn
>zu simulieren), d. h. du nutzt dir aus, dass dein tatsächlicher
>Prozessorkern ja dem des Zielsystems entspricht...
Das wäre ein Idee. Wahrscheinlich wär's gut für die Geschwindigkeit.
Ich würde den Code gern auf unterschiedlichen Zielsystemen laufen 
lassen. Deshalb sollte das ganze "pure C" sein.

>Ansonsten kannst du noch avrsim angucken (ich glaube, so heißt es),
>ein minimalistischer CPU-Simulator, der (im Gegensatz zu simulavr)
>keinen Anspruch auf eine komplette Simulation des Kerns legt, dafür
>aber schnell sein will.

Hab gerade mal drauf geschaut.
http://code.google.com/p/avr-sim/source/checkout

Leider ist alles C++. Die Struktur ist meiner Meinung nach nicht gut für 
die Geschwindigigkeit. Wenn ich es richtig sehe, sollten sich in der 
Klasse
"CoreOperation" in "operations.cpp"

alle Befehle des Cores befinden. Beim schnellen Überfliegen vermisse ich 
schon gleich die "Jumps". Deshalb vermute ich, dass das Projekt sich 
noch in einem ziemlich rudimentären Zustand befindet.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ein jump denn eine operation ist...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn's keiner ist, wo steht der Code?
Wie ist mit nem BRNE?

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hoffe, ich nehme den Thread hier nicht ernster als er gemeint ist, 
aber als ich gerade einen 6502-Emulator für Atmega geschrieben habe kam 
mir auch spontan in den Sinn, das Ganze doch einfach auch für den AVR 
selbst zu machen. Sollte sogar Sinn machen damit man dynamischen Code im 
SRAM ausführen kann(manchmal stört die Harvard-Architektur). Bevor ich 
mich mal praktisch darin eingarbeitet hatte, dachte ich, es wäre 
einfacher als eine fremde CPU zu emulieren, da die Befehle ja identisch 
sind.

Aber mal aus der (versuchten) Umsetzung betrachtet: vergess den Faktor 
20 selbst mit Assembler. Das Hauptproblem an dem ganzen ist die 
Bit-Struktur der AVR-Befehle. Vielleicht ist das nur ein großes 
Logikrätsel, das ich bisher nicht gelöst habe oder eine Analyse der 
Logikstruktur des AVR-Kerns würde die Idee bringen. Aber die ganzen 
Bitschiebereien, die nötig sind, aus den 16-bit den Opcode, Register und 
Werte zu extrahieren plus notwendige Sprünge und Verarbeitung halte ich 
für ausgeschlossen in 20 Takten, unter 32 bis 40 ist da nix zu machen. 
IO kann dabei keiner emuliert, höchstens genutzt werden und ohne 
Assembler kann man da noch einige Takte draufrechnen.

Ich verfolge das derzeit nicht groß weiter da ich mir die 
1MHz@20Mhz-Emulation als Ziel gesetzt hatte, aber wäre neugierig, 
wieviele kHz da jemand hinbekommt.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich hoffe, ich nehme den Thread hier nicht ernster als er gemeint ist,
Hallo Mark,
es ist schon irgendwie ernst gemeint. Man kann ja mal über das Thema 
diskutieren und schauen, welche kreativen Ideen so entstehen.

>aber als ich gerade einen 6502-Emulator für Atmega geschrieben habe kam
>mir auch spontan in den Sinn, das Ganze doch einfach auch für den AVR
>selbst zu machen. Sollte sogar Sinn machen damit man dynamischen Code im
>SRAM ausführen kann(manchmal stört die Harvard-Architektur).

Ja, es ist eine Virtualisierung. Vielleicht wie eine JVM. Um den 
Speicher zu vergrößern könnte man vielleicht ein serielles SRAM oder 
EEPROM oder SD-Karte dran hängen.
Ich glaube nach diesem Prinzip haben die ersten BASIC-Stamps gearbeitet.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:

> Leider ist alles C++.

Was wäre daran nun unbedingt tragisch?

> Die Struktur ist meiner Meinung nach nicht gut für
> die Geschwindigigkeit.

Das würde mich wundern, denn Geschwindigkeit war das primäre
Entwicklungsziel dieser Implementierung.  Es war explizit gewünscht,
dass das Teil, wenn es auf einem PC läuft, möglichst viel schneller
als ein realer AVR ist.

> Deshalb vermute ich, dass das Projekt sich
> noch in einem ziemlich rudimentären Zustand befindet.

Das sollte mich wundern.  Das wesentliche Ziel dieses Projekts war
oder ist es, einen Simulator anzubieten, auf dem man während der
GCC-Entwicklung den vom Compiler generierten Code (automatisiert)
möglichst schnell simulieren kann, sodass man damit Qualitätsanalysen
am generierten Code vornehmen kann.  Dafür muss der CPU-Kern natürlich
komplett implementiert sein, während man vom IO-Subsystem außer dem
Stackpointer und den erweiterten Zeigerregistern (RAMPZ und sowas)
praktisch nichts braucht.

Vorstellbar wäre es natürlich, dass Features des CPU-Kerns, die vom
GCC nie angefasst werden, auch nicht implementiert sind.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das wesentliche Ziel dieses Projekts war
>oder ist es, einen Simulator anzubieten, auf dem man während der
>GCC-Entwicklung den vom Compiler generierten Code (automatisiert)
>möglichst schnell simulieren kann, sodass man damit Qualitätsanalysen
>am generierten Code vornehmen kann.

Hast Du den Simulator für Deine Projekte schon einmal verwendet?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Hast Du den Simulator für Deine Projekte schon einmal verwendet?

Nein, aber Eric Weddington meines Wissens.

Ich simuliere eher selten, ich gehe lieber auf's fertige Zielgerät
und debugge mit dem JTAG ICE.  Allerdings ist der Großteil meiner
zu debuggenden Probleme ohnehin eher an die Peripherie und dessen
Interaktionen mit der Umwelt gebunden, da ist eine Simulation dann
ziemlich schnell am Ende mit ihrem Latein.

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.