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
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.
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.
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.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.