AVR Studio: Eingestellter Takt EInfluss auf SimSpeed ?

[Torsten B. (torty)]

Hallo Gemeinde

Kann mir jemand sagen, ob die im AVR Studio (SimOptions) eingestellte 
Taktrate einen Einfluss auf die Simulationsgeschwindigkeit hat ?

Komme ich beim Debuggen (zB mit "GoToCursor") schneller ans Ziel, wenn 
ich beim eingestellten Takt Vollgas gebe ? zB 4MHz vs 20MHz

Oder macht der Simulator immer so schnell der Rechner es erlaubt ?

Anders: Wie kann ich die SimSpeed beeinflussen ?
          Es nervt, dass er für "20 Zeilen" immer 4 Minuten braucht.

Grüße
Torsten

[Karl H. (kbuchegg)]

Torsten B. schrieb:
> Hallo Gemeinde
>
> Kann mir jemand sagen, ob die im AVR Studio (SimOptions) eingestellte
> Taktrate einen Einfluss auf die Simulationsgeschwindigkeit hat ?

Nein, hat sie nicht.
Wäre auch sinnlos. Dazu gibt es in der Simulation eine simulierte 
Taktzählung und eine simulierte Uhr. Die sind deine einzigen Werkzeuge, 
um das Timing deines Programms zu kontrollieren. Und sie zählen.
Dein AVR legt ja auch kein Päuschen ein, wenn Windows zur Auffassung 
gelangt es sollte mal wieder den Hauptspeicher aufräumen.


> Anders: Wie kann ich die SimSpeed beeinflussen ?
>           Es nervt, dass er für "20 Zeilen" immer 4 Minuten braucht.

Kommentiere deine _delay_ms aus und alles wird gut.
Noch besser: formuliere dein Programm ohne _delay_ms. Delays sind 
sowieso meistens nicht die Lösung, sondern das Problem.

[Martin K. (maart)]

Da taucht auch wieder die Frage auf: WARUM ist die Simulation sooo 
langsam? Ist das softwaremäßig wirklich so schwierig, dass der PC 
tatsächlich immense Dinge zu berechnen hat, oder nur schlecht 
programmiert?
Ich habe leider keinen Vergleich zu MPLAB.

[Karl H. (kbuchegg)]

Martin Kreiner schrieb:
> Da taucht auch wieder die Frage auf: WARUM ist die Simulation sooo
> langsam? Ist das softwaremäßig wirklich so schwierig, dass der PC
> tatsächlich immense Dinge zu berechnen hat, oder nur schlecht
> programmiert?

Kann ich nicht sagen.
Mir kommt die Simulation auch eher lahm vor.
Auf der anderen Seite muss dieser Simulator natürlich auch eher 
allgemein gehalten sein, weil er ja alle AVR-Typen können muss. D.h. da 
muss jeder Pfurz im simulierten µC durch entsprechende 
Konfigurationsdateien konfigurierbar sein. Und wenn man das ein wenig 
ungeschickt macht, dann landet man schnell bei einem Programm, das 30% 
seiner Zeit nur dadurch vertrödelt, herauszufinden ob der µC das 
überhaupt kann bzw. wie die Reaktion ausfallen muss, welche Interrupt 
Flags nach jedem simulierten Befehl zu checken sind, etc ...

Und das andere Thema ist natürlich: Bildschirmupdate.
Jeder der schon mal WIndows-Programmiert hat kennt das: Der Algorithmus 
an sich ist pfeilschnell. Ausgebremst wirst du dadurch, dass das 
dauernde Neuzeichnen und Befüllen der unterschiedlichsten Edit-Boxen, 
List-Felder, List-Controls etc. eine Menge Zeit verbrutzelt.
Bei einem Einzelschritt fällt das nicht besonders auf, wenn aber der 
Simulator 20-tausend Schritte machen muss UND das alles ein wenig 
ungeschickt gemacht wurde, dann läppert sich das alles zusammen.

[Martin K. (maart)]

Bildschirmupdate fällt im "Run-Modus" weg, da ist alles deaktiviert.
Was ich mir heute abend aber mal ansehen muss ist, wie hoch die 
Prozessorauslastung während der Simulation ist.