Hallo, weiß jemand, ob es einen in C-geschriebene Emulation für einen AVR-Kern gibt? Gruß, chris
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.
1 | klaus@i4a:~ > simulavr --list-devices |
2 | at90s1200 |
3 | at90s2313 |
4 | at90s4414 |
5 | at90s8515 |
6 | atmega8 |
7 | atmega16 |
8 | atmega103 |
9 | atmega128 |
10 | at43usb351 |
11 | at43usb353 |
12 | at43usb355 |
13 | at43usb320 |
14 | at43usb325 |
15 | at43usb326 |
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 ...
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++.
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/simavr/cores/sim_tiny13.c http://gitorious.org/simavr/simavr/blobs/master/simavr/sim/avr_timer.c
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.
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!
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.
@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.
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.
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&file=viewtopic&t=86665
>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.
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.
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.
Wenn's keiner ist, wo steht der Code? Wie ist mit nem BRNE?
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.
>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.
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.
>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?
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.
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.