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: > (es läuft AtmelStudio_6.2, Prozessor ist ein Atmega328p@16MhZ) Probier mal zum Vergleich AVRStudio 4.19
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.
Peter II schrieb: > schnellere PC Schon klar, die Sache mit dem Hubraum... Nee, also 4GB & 2x2,4GhZ müssen einfach reichen.
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.
Wieso ist das überhaupt so langsam? Die uVision Simulation vom 8051 läuft sehr Echtzeitnah würde ich sagen
Man sollte natuerlich nur etwas simulieren,das Sinn macht. Auf einen Timer zu warten ist eher sinnlos...
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)
:
Bearbeitet durch User
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.