Hallo Leute,
ich ärger mich schon längere Zeit mit dem AVR Studio Simulator rum.
(Habe die neueste Version installiert)
Immer wenn der Simulator auf ein _delay_xx() stößt,
dauert die Simulation ein paar Sekunden.
Wenn ich eine Sekunde im Programm warten will braucht der Simulator ca.
4 Minuten (auf einem i7 Prozessor!) und ich kann mir in der Zwischenzeit
einen neuen Kaffee holen....
Natürlich kann ich mit Makros, etc _delay_xx ausblenden, aber
das ist keine Lösung für mich.
(Auf dem uC funktioniert es wunderbar...)
Normalerweise muss sowas doch flott gehen.
Gibt es da irgendwelche Einstellungen, die ich übersehen haben könnte?
Gruß
Björn
bjoern schrieb:> Normalerweise muss sowas doch flott gehen.
Tja, normal ist halt für jeden anders.
Die Simulationsgeschwindigkeit im Studio ist nunmal schnarch-langsam,
und das konsequent für alle Befehle.
Dir wird nichts anderes übrigbleiben, als die Delays in der Simulation
per define o.ä. auszublenden.
Oliver
Nachtrag:
Wer allerdings mit einem delay EINE GANZE SEKUNDE im Programm verbraten
will, ist selber schuld.
Vermutlich hat Atmel dafür extra noch eine Bremse eingebaut, umd dem
Benutzer deutlich zu machen, daß man so nicht programmiert...
Oliver
Oliver schrieb:> Nachtrag:>> Wer allerdings mit einem delay EINE GANZE SEKUNDE im Programm verbraten> will, ist selber schuld.>> Vermutlich hat Atmel dafür extra noch eine Bremse eingebaut, umd dem> Benutzer deutlich zu machen, daß man so nicht programmiert...
:-)
Wobei man der Fairness halber sagen muss, es dauert auch entsprechend
lange, wenn der Timer auf 1 Sekunde hochzählen soll.
Ich weiß zwar nicht, wie der Simulator programmiert ist, aber der hat
nun mal heftig damit zu tun, einen AVR in allen Aspekten möglichst gut
zu simulieren. 1 Sekunde ist nun mal für einen µC eine lange Zeit. Bei
16Mhz Taktfrequenz sind das über den Daumen rund 14 Millionen Befehle.
Die wollen erst mal mit allen Nebeneffekten und Konsequenzen
durchsimuliert werden. bjoern kann ja mal probieren, wie lange er dazu
braucht 14 Millionen Befehle auf dem Papier zu simulieren und nach jedem
Befehl die 'Peripheriemodule' durchgehen, ob irgendwo Arbeit ansteht wie
zb Timer hochzählen, Compare Register vergleichen, entsprechende
Aktionen auslösen, etc. etc.
Oliver schrieb:> Wer allerdings mit einem delay EINE GANZE SEKUNDE im Programm verbraten> will, ist selber schuld.>> Vermutlich hat Atmel dafür extra noch eine Bremse eingebaut, umd dem> Benutzer deutlich zu machen, daß man so nicht programmiert...
Vielleicht muss ich eine Sekunde warten, bis sich der Scheinprüfer
initalisiert hat. (Transportbandtest etc.)
Klar kann ich das mit Timern etc lösen - aber wozu der Aufwand, wenn eh
bei nem Reset die ganze Kiste neu initalisiert werden muss.
Das bei 16MHz ne menge nop's generiert werden - ist mir klar, aber
meiner Ansicht nach sollte das ein neuerer Prozessor problemlos in
Echtzeit schaffen einen kleinen uC zu simulieren.
Deswegen fragte ich auch nach Einstellungsmöglichkeiten.
Wenn der Simulator so oder so "schnarch-langsam" ist, muss ich halt
damit leben.
bjoern schrieb:> Normalerweise muss sowas doch flott gehen.
Warum sollte es?
So ein Delay ist eine aufwändige Zählschleife, die weiter nichts
tut, als sinnlos Register herunter zu zählen, damit die Zeit
vergeht.
Wenn man sowas halt simulieren will, muss man warten.
Eine Alternative ist es natürlich, während der Simulation die
Delays ganz auszublenden, bspw. mit sowas:
1
#ifdef SIMULATE
2
# define _delay_us(x) __asm("nop")
3
# define _delay_ms(x) __asm("nop")
4
#else // the real thing
5
# include <util/delay.h>
6
#endif
und dann irgendwo das #define SIMULATE zu setzen, solange man nur
simulieren will.
Eine eigene Frage?
Dieser Thread ist über 13 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
