Simulavr und Interrupts

Ich glaube, da mußt Du mal die simulavr-Doku studieren.  Wenn
überhaupt, dann wohl eher nur sehr spärlich, vielleicht auch gar
nicht, aber ein bißchen Bewegung ist in simulavr auch drin.

Du solltest zumindest den aktuellen Port nutzen, ich habe den vor paar
Wochen mal aktualisiert.

Ich hab den neusten Port (simulavr-0.1.2_1) installiert.

Danke
Gruß
Manuel

P.S.
Gäbe es noch eine Alternative (ausser JTAG) zur Simulation unter
FreeBSD? (bzw. Wie machst du das ?)

> Gäbe es noch eine Alternative (ausser JTAG) zur Simulation unter
> FreeBSD? (bzw. Wie machst du das ?)

Gerade dann, wenn es um die Hardware geht, führt meist nichts am
realen Chip vorbei.  ,,printf-Debugging'' hilft dort u. U. noch ein
Stück, eine RS-232 plane ich wenigstens fürs Debuggen eigentlich immer
mit ein.

Außerdem entwickelt sich halt ein Prototyp am besten auf einem
möglichst großen Prozessor, also ATmega128.  Dort hast Du immer
genügend Portpins (selbst dann, wenn Dir das JTAG-Interface 4 bits
klaut), immer genügend ROM für noch ein Dutzend printf-Strings,
usw. usf.  Wenn die Applikation erstmal grundsätzlich ,,rund'' ist,
kann man die endgültige Platine entwerfen und sie auf den
Zielprozessor runterskalieren.

Das JTAG ICE ist in der Tat durchaus von Nutzen, wenngleich Du
natürlich trotzdem das Problem hast, daß nicht jeder beliebige
Echtzeitvorgang wirklich debugfähig ist.  (Das Problem hat man auch
woanders, eine Serie von 10 aufeinanderfolgenden Interrupts im
FreeBSD-Floppytreiber kann ich auch nicht ohne weiteres mit einem
Breakpoint versehen.)  Es gibt mittlerweile auch preiswerte Varianten
von JTAG ICE, es muß also nicht immer die EUR 300 Option von Atmel
sein.  (Leider waren die Olimex-Teile wohl teilweise etwas
problembehaftet, so daß Andreas sie aus shop.mikrocontroller.net
wieder rausgenommen hat.)

Schließlich wäre noch VMLAB.  Eine wirklich gute Simulation, die unter
Wine auch brauchbar läuft (und deren Autor durchaus Wert auf diese
Option legt).  Hat paar kleine Probleme, die Icons oder zwei, drei
Fensterinhalte werden zuweilen nicht ordentlich neu gezeichnet, aber
da kann man sich mit kleinen Tricks helfen.  Ansonsten tut das im
Gegensatz zu AVR Studio 4 wirklich brauchbar unter Wine.  Ist
kostenpflichtig, aber die EUR 100 können sich schon lohnen.
Vorteilhaft ist, daß der Simulator auch eine Art ,,lint'' darstellt:
Zustände, die zwar nicht verboten sind, aber auch nicht
empfehlenswert, werden erkannt.  Einerseits werden alle Register
intern nicht nur als 0 und 1 dargestellt, sondern auch als `not set',
und bei Zugriff auf einen solchen Wert gibt's eine Warnung.  Auch
wird
erkannt, wenn eine UART benutzt wird, aber der Teiler noch nicht
gesetzt, etc. pp.  Schließlich kann noch ein bißchen Peripherie
simuliert werden.  Aber s. o., meiner Meinung nach hat jede Simulation
halt ihre Grenzen.

Simulavr nehme ich selbst auch, vorwiegend aber für die Überprüfung
von Algorithmen.  Die printf + scanf Familie beispielsweise ist
ausgiebig durch Simulation getestet worden, bevor dann die endgültigen
Tests auf der Bastelhardwar gelaufen sind.

Mit dem GDB kann man Signale an den Simulator senden. Ein Timer0
Overflow auf einem Mega8 kann man z.B. mit "signal SIG90" auslösen.
Die 90 solltest Du mal variieren und bei 80 beginnen. Der Simulavr
schmeißt auch eine Meldung raus, welcher Interrupt ausgelöst wurde.
Wenn Du einen Interrupt simulieren möchtest, dann solltest Du dort auch
einen Breakpoint setzen.

Dokumentiert ist das ganze leider nicht wirklich, ich habe das aus dem
Skript misc/irq.py im Release 0.1.2.1.

Hat eigentlich schonmal jemand ein Tutorial zum Simulavr mit GDB
geschrieben? Ansonsten würde ich mich da mal dransetzen.

ciao, Stefan.

Das wäre toll, wenn du das schreiben könntest.

Und schön wäre auch, wenn am simulavr noch weiterentwickelt werden
würden, ich vermisse z.B. den Timer2 bei den Megas.