N Abend...
Ich habe mich mal an der AtmelStudio Simulation versucht. Is ja nicht
soo kompliziert... Aber ist es normal, das 'das' so langsam ist?
Ich hab jetzt zwar nicht auf die Stoppuhr geschaut aber eine Sekunde im
Simulator sind min. 200 Sekunden in 'Echtzeit'. Wenn überhaupt, kann man
an der Sache etwas ändern/beschleunigen? Das Programm ist ein Witz: Es
werden ein paar Ports und zwei Timer initialisiert. Im main loop
passiert nichts. Und eine ISR wartet auf TIMER1_COMPA_vect
(es läuft AtmelStudio_6.2, Prozessor ist ein Atmega328p@16MhZ)
mike schrieb:> Wenn überhaupt, kann man> an der Sache etwas ändern/beschleunigen?
schnellere PC
Es ist zwar nicht so sehr schnell, aber so langsam ist es nun auch
wieder nicht.
mike schrieb:> Schon klar, die Sache mit dem Hubraum...> Nee, also 4GB & 2x2,4GhZ müssen einfach reichen.
jaja, schnell ist anders. Im schlimmsten fall noch ein Celeron.
Das erklärt erst mal das es bei mir schneller ist.
Peter II schrieb:> Im schlimmsten fall noch ein Celeron.
Na immerhin Centrino2.
Echt, das soll 'langsam' sein? Hm, hat mir eigentlich - bis jetzt -
immer gereicht.
mike schrieb:> Echt, das soll 'langsam' sein? Hm, hat mir eigentlich - bis jetzt -> immer gereicht.
ist halt nicht mehr der aktuelle Stand. Es gibt bestimmt viele dinge für
die er noch schnell genug ist, aber hier scheinbar nicht.
Die Frage ist, warum musst du so lange simulieren? Hast du so viele
Delays die du nicht einfach verkürzen kannst?
Peter II schrieb:> Hast du so viele> Delays die du nicht einfach verkürzen kannst?
Nicht's. Keine delay's o.d.g. Wie gesagt nur ein paar Port & TimerInits.
3 if's im main loop, die mom. noch nicht erreicht werden und eine ISR
mike schrieb:> Nicht's. Keine delay's o.d.g. Wie gesagt nur ein paar Port & TimerInits.> 3 if's im main loop, die mom. noch nicht erreicht werden und eine ISR
einfach für die Simulation den Timer beschleunigen oder einfach von Hand
das ISR Flag setzten.
mike schrieb:> Wie gesagt nur ein paar Port & TimerInits.
Die Timer müssen ja auch "getimed" gezählt werden. Das
geht nicht in Echtzeit.
Wenn das Studio das möglicherweise so saudumm löst dass es im
1ms Tick die Zähler laufen läss dann Gute Nacht ....
isidor schrieb:> Wenn das Studio das möglicherweise so saudumm löst dass es im> 1ms Tick die Zähler laufen läss dann Gute Nacht ....
Eine runde main loop mit F10 (StepOver):
6.801,56 µs
Klick
Klick
Klick
Klick
Klick
6.803,25 µs
Tolle Show!
isidor schrieb:> Wenn das Studio das möglicherweise so saudumm löst dass es im> 1ms Tick die Zähler laufen läss dann Gute Nacht ....
Es wird keine Zeit simuliert. Es werden so schnell es geht TAKTE
simuliert. Und in einem Takt alles das gemacht, was auch die Hardware
machen würde.
mike schrieb:> 3.6 µs> nach 10 Sekunden 'Echtzeit'> 41.997,44 µs
Wenn du die Simulation wirklich brauchst, dann brauchst du eine
schnellere CPU.
Oder mal eine alternative Software testen.
https://gitorious.org/simavr/pages/GetStarted#toc_5
Ich kenne sie nur, getestet habe ich sie nie.
Man kann den Timer aber auch per Hand verstellen, damit man nicht zu
lange warten muss, nur wenn man die Zeit stoppen will bringt das halt
nichts. Autostepping ist eh etwas langsam gibt aber noch nie Möglichkeit
das ohne die optischen Aktualisierungen zu machen, beim Breakpoint wird
dann alles auf den aktuellen Stand gebracht.
Diek schrieb:> Wieso ist das überhaupt so langsam?
Hab ich mich auch immer gefragt.
Das wird wohl daran liegen, dass der AVR Simulator zig unterschiedliche
Prozessoren simulieren können muss. Ein Simulator, der nur einen ganz
bestimmten Prozessor simuliert hat es leicht: da ist das Verhalten des
Prozessors einprogrammiert und gut ists. So ein Universalsimulator muss
hingegen ständig in den Konfigurationen nachsehen, was ein spezifischer
Prozessor jetzt eigentlich alles macht. Alleine das abklappern der
richtigen Interrupt Flags nach jedem Befehl und feststellen müssen, ob
eine ISR anzuspringen ist, artet dann schon aus.
Dazu dann die unterschiedlichen Timer in den unterschiedlichen
Prozessoren mit ihren unterschiedlich verfügbaren Modi .....
Karl Heinz schrieb:> Das wird wohl daran liegen, dass der AVR Simulator zig unterschiedliche> Prozessoren simulieren können muss.
Na aber wie dumm wäre das denn??? Schliesslich ist doch festgelegt für
welchen Prozessor das aktuelle Projekt ist.
Thomas O. schrieb:> ohne die optischen Aktualisierungen zu machen, beim Breakpoint wird> dann alles auf den aktuellen Stand gebracht.
So mach ich es auch.
Mh, ganz schön nervig. Dank Euch trozdem
mike schrieb:> Karl Heinz schrieb:>> Das wird wohl daran liegen, dass der AVR Simulator zig unterschiedliche>> Prozessoren simulieren können muss.>> Na aber wie dumm wäre das denn??? Schliesslich ist doch festgelegt für> welchen Prozessor das aktuelle Projekt ist.
Aber es gibt nicht für jeden Prozessor einen eigenen Simulator.
Was es hingegen gibt, sind einen Haufen XML Files (für jeden Prozessor
ein eigenes), in denen die Eigenschaften des jeweiligen Prozessors
beschrieben sind und der Simulator muss mit dem zurecht kommen, was er
in diesen XML Files vorfindet (zumindest im 4-er Studio war das so. Beim
6-er hab ich noch nicht in den Verzeichnissen gestöbert. Aber es wird
wohl nicht anders sein)
