AVR Studio 6 - Simulator braucht ewig für delay's

[bjoern (Gast)]

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

[Oliver (Gast)]

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

[Oliver (Gast)]

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

[Karl H. (kbuchegg)]

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.

[bjoern (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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:

#ifdef SIMULATE
#  define _delay_us(x) __asm("nop")
#  define _delay_ms(x) __asm("nop")
#else // the real thing
#  include <util/delay.h>
#endif

und dann irgendwo das #define SIMULATE zu setzen, solange man nur
simulieren will.

[Sauger (Gast)]

Nabend,

oder du tauscht deinen i7 gegen einen aus dieser Liga:

http://de.wikipedia.org/wiki/Titan_%28Computer%29

JTAG dürfte aber günstiger zu bekommen sen.

MfG