Probleme beim Simulieren

[GCC-ling (Gast)]

Hallo

ich habe Probleme beim Simulieren mit AVRStudio. Es erscheint diese 
Zeile:

Debugger: 'Break at line default\c:\program 
files\winavr\avr\include\util\delay_basic.h:21' has been disabled. 
Unable to bind line 21 in file "default\c:\program 
files\winavr\avr\include\util\delay_basic.h" to a program memory 
address.


Was könnte da das Problem sein.

Ebenso wird beim Simulieren wenn das Programm läuft der Ausgang nicht 
richtig nach 100ms getogglet. Nur wenn ich zwei Breakpoints setze kann 
ich erkennen dass der Ausgang togglet.

Ist das normal beim AVRStudio.

#include <avr/io.h>
#include <util/delay.h>


int main(void)
{

DDRB = 0xFF; 
PORTB = 0xFF;

while(1) 
{
PORTB=PORTB & (~(1<<0));
_delay_ms(100); 
PORTB=PORTB|(1<<0);
_delay_ms(100); 
}
}

Mfg

[Karl H. (kbuchegg)]

GCC-ling schrieb:

> Debugger: 'Break at line default\c:\program
> files\winavr\avr\include\util\delay_basic.h:21' has been disabled.
> Unable to bind line 21 in file "default\c:\program
> files\winavr\avr\include\util\delay_basic.h" to a program memory
> address.
>
>
> Was könnte da das Problem sein.

Das sieht alles noch einem altbekannten 'Problem' aus.
Die delay Funktionen funktionieren nur dann richtig, wenn sie sich der 
Optimizer vornimmt und so gut wie alles davon wegoptimiert (konstante 
Ausdrücke ausrechnet und darauf basierend fällt dann das meiste aus den 
delay Funktionen raus). Das ist auch gewollt so und die delay Routinen 
sind so gebaut, dass das so sein muss, damit am Ende die richtigen 
Zeiten rauskommen.
Nur: Wie soll der Debugger einen Breakpoint auf Code setzen, der gar 
nicht vorhanden ist, weil ihn der Optimizer rausgeschmissen hat?

Schaltet man aber den Optimizer aus, damit der Debugger korrekt arbeiten 
kann, dann stimmen die delay Zeiten hinten und vorne nicht mehr.

Es ist daher relativ sinnlos, die delays im Debugger kontrollieren zu 
wollen. Du musst einfach daran glauben, dass die Zeiten in der Realität 
schon stimmen werden, wenn die angegebene F_CPU korrekt ist. Glauben ist 
vielleicht etwas zu pessimistisch ausgedrückt. Solange F_CPU die 
Realität wiederspiegelt, stimmen die Zeiten auch. Nicht unbedingt auf 
die Nanosekunde genau, aber genau genug für die meisten Zwecke in denen 
man delays einsetzt.

[GCC-ling (Gast)]

>Nicht unbedingt auf
>die Nanosekunde genau, aber genau genug für die meisten Zwecke in denen
>man delays einsetzt.

Naja bei mir kommts ja auch nicht auf die Nanosekunde an. Bei mir sind 
ms eingestellt aber blinken tut es im Minutenbereich. Das ist für mich 
keine Simulation mehr d.h. die Software könnte ich nur mit einer 
Hardware testen.


>Nur: Wie soll der Debugger einen Breakpoint auf Code setzen, der gar
>nicht vorhanden ist, weil ihn der Optimizer rausgeschmissen hat?

Setze ich zwei Breakpoints kann ich das blinken sehen jedoch wenn ich 
keine Breakpoints setze und das Programm laufen lassen kann ich bis ca 4 
Minuten warten bis es umschaltet.

Was mich wundert ist, dass die Simulation bei anderen Leuten halbwegs 
nachvollziehbar ist.

[cm (christian mock) (Gast)]

dein PC ist zu langsam - wie kommst du auf die idee, daß der simulator 
in echtzeit läuft?

es gibt dort aber eine stopwatch-funktion, dh. du kannst einen 
breakpoint vor dem delay setzen und einen nachher und die zeiten 
vergleichen, da sollten ca. deine 100ms rauskommen...

cm.

[GCC-ling (Gast)]

>dein PC ist zu langsam - wie kommst du auf die idee, daß der simulator
>in echtzeit läuft?

Vor Jahren hatte ich einen viel älteren PC und mit Keil lief das 
Simulationsprogramm ca. in Echtzeit. => Es muss etwas mit dem AVRStudio 
und den Einstellungen sein (Vermutung).

Wenn der PC bzw. das AVRStudio nicht einmal ein ganz normales blinken 
simulieren kann dann bräuchte ich einen PC von der Rüstungsindustrie um 
etwas anderes zu simulieren.

Außerdem habe ich gesehen dass eine ähnliche Simulation bei anderen 
Leuten ohne Probleme funktioniert.

[Oliver (Gast)]

>Wenn der PC bzw. das AVRStudio nicht einmal ein ganz normales blinken
>simulieren kann dann bräuchte ich einen PC von der Rüstungsindustrie um
>etwas anderes zu simulieren.

Dann brauchst du einen JTAG und einen AVR, damit debuggst du dann in 
Echtzeit. Die Softwarelösungen (egal, welche) sind immer um mehrere 
Größenordnungen langsamer. Egal, wie du die einstellst.

>Außerdem habe ich gesehen dass eine ähnliche Simulation bei anderen
>Leuten ohne Probleme funktioniert.

Na ja, vermutlich bist du dir nicht ganz sicher, was du da wirklich 
gesehen hast. Es soll Leute geben (ich z.B.), die bei sowas in der 
Simulation alle delays weglassen. Dann läuft es tatsächlich schneller.


Oliver

[GCC-ling (Gast)]

>Na ja, vermutlich bist du dir nicht ganz sicher, was du da wirklich
>gesehen hast. Es soll Leute geben (ich z.B.), die bei sowas in der
>Simulation alle delays weglassen. Dann läuft es tatsächlich schneller.

Ich habe gesehen dass bei der Software AVRStudio das selbe Programm bei 
einer anderen Person am Port_x bzw. Pin_x -Kästchen ca. jede 0,5 Sekunde 
blinkt aber bei mir alle 2 Minuten.

Aber ist egal das war bestimmt weil .....