Zu blöd für if-Anweisungen?

[Beda (Gast)]

Was habe ich übersehen? Welche unergründlichen Geheimnisse verbirgt der
uC hier, welche ich nicht kenne? Liegt ein Compilerfehler vor?
Problem:
Ich schaff es nicht diese einfache if-Anweisung zum laufen zu bringen.
Die Funktionsblöcke werden nicht ausgeführt, egal welchen Wert ich für
usiValue eingebe. Ich verwende AVR-GCC und AVR-Studio 3.56 zum
simulieren. Es kann davon ausgegangen werden, dass alle verwendeten
Variablen deklariert und richtig initialisiert worden sind.

  if (usiValue > 2)
       {
          /* Anweisungen */
       }
  if (usiValue == 0)
       {
          /* Anweisungen */
       }

Ich hoffe die Frage ist für Euch nicht zu blöd und es ist ein triviales
Problem.
Gruß
BEDA

[Joerg Wunsch (Gast)]

> Es kann davon ausgegangen werden, dass alle verwendeten Variablen
> deklariert und richtig initialisiert worden sind.

Wenn etwas nicht funktioniert, sollte man halt auch solche Dinge
verdächtigen, die ,,garantiert unverdächtig'' sind. ;-)

Was genau tust Du denn?  Simulieren oder real device?  Wie
programmierst Du den Chip?  Handelt es sich bei den Initialisierungen
zufällig um statische (also »unsigned int usiValue = 3;«) oder um
Zuweisungen?

Wenn eine so einfache Anweisung nicht funktioniert, muß der Haken
logischwerweise woanders sein.

[Peter D. (peda)]

Füge doch einfach mal else-Zweige mit ein, ob die wenigstens richtig
abgearbeitet werden (für Werte <0 bzw. 1 oder 2).

Sieh Dir auch mal das Assemblerlisting an, was für Code da erzeugt
wird.

Vielleicht werden ja Deine  /* Anweisungen */  wegoptimiert, der WINAVR
ist da ziemlich rigide.


Peter

[Beda (Gast)]

Hi,

> Simulieren oder real device?
Simulieren

> Wie programmierst Du den Chip?
C mit GNU-Compiler (siehe oben)

> Handelt es sich bei den Initialisierungen zufällig um statische
>(also »unsigned int usiValue = 3;«) oder um Zuweisungen?
Ich habs sowohl als auch versucht, als auch in der Simulation den Wert
von Hand geändert. Bei keiner Simulation wurde der Anweisungsblock
durchgeführt.

> Wenn eine so einfache Anweisung nicht funktioniert, muß der Haken
> logischwerweise woanders sein.
Und den such ich nun schon ewig :(

Ich hab jetzt weiter gesucht. Es scheint sich "nur" um einen
Simulationsfehler handeln, denn wenn man den Assemblercode anscheut,
dann macht der, was ich will. "Nur" die Anzeige im Watch-Window wird
nicht aktualisiert, da dieses die Werte aus dem SRAM liest, aber nur
das Register verändert wird (verfolgt man nämlich den Assemblercode und
die Register, dann arbeitet das Programm ).
Wie kann ich nun dafür sorgen, dass die Werte aus dem Register auch in
das SRAM geschrieben werden?

Zur kurzen Demo hab ich einen kleinen Mehrzeiler geschrieben. (AT2313,
4MHz)

Gespannt auf Antworten und beruhigt, dass ich doch nicht so doof bin
wie ich dachte
BEDA

[Joerg Wunsch (Gast)]

>> Wie programmierst Du den Chip?
> C mit GNU-Compiler (siehe oben)

Falsche Antwort. :-)  Du programmierst ihn gar nicht, weil Du ja nur
simulierst...  Sorry, mit ,,programmieren'' meinte ich hier, mit
welcher Methode die Daten in den Flash kommen.

Traue keiner Simulation, die Du nicht selbst verbrochen hast. ;-)

Könnte sein, daß Du ,,nur'' über die fehlende Initialisierung von
.data im AVR Studio in Verbindung mit avr-gcc generierten COFF-Files
stolperst.  Nerve Atmel, daß sie endlich eine neue Version
rausbringen, das ist schon ewig in deren Quellen repariert.  Aber
eigentlich müßte es dann mit der manuellen Zuweisung funktionieren.

Keine Ahnung, ich benutze kein AVR Studio (und kein Windows überhaupt
;-).

> "Nur" die Anzeige im Watch-Window wird nicht aktualisiert, da
dieses
> die Werte aus dem SRAM liest, aber nur das Register verändert wird
> (verfolgt man nämlich den Assemblercode und die Register, dann
> arbeitet das Programm ).

Ach so, dann ist das natürlich ganz normales Verhalten für optimierten
Code.  Damit mußt Du einfach leben bzw. Dir eben in der Zwischenzeit
solange das Register mit ansehen.

> Wie kann ich nun dafür sorgen, dass die Werte aus dem Register auch
> in das SRAM geschrieben werden?

Du könntest die Optimierung abschalten, aber das willst Du nicht
wirklich.  Du würdest ein Programm generieren, das Du zwar schön in
der Simulation verfolgen kannst, aber das in der Praxis nicht sinnvoll
wäre.  Ob die damit erfolgte Simulation noch realitätsnah ist, bleibt
auch anzuzweifeln, da sich durch (nachträgliches) Einschalten der
Optimierung ja z. B. das Timing des Programmflusses ändern würde.

Du könntest die Variable `volatile' deklarieren und damit den
Compiler
anweisen, auf diese Variable keine Optimierung durchzuführen.  Aber
wieder wie oben: warum willst Du das tun?  Ist Dein Ziel eine gute
Simulation oder eine gut (und schnell) funktionierende Applikation?

[Beda (Gast)]

Hallo Jörg und Peter,
danke für Eure Hilfe. So langsam kommt wieder die Erinnerung an die
verschiedenen Feinheiten, um wieder an so Anweisungen wie volatile usw.
zu denken. (Ist halt doch ein bisschen her als ich es das letzte mal
gebraucht hatte).
Allerdings hätte ich nicht geglaubt, dass der gnu-Compiler so hart den
Code effektiver gestaltet und dass man dies doch so stark kontrollieren
muss. In diesem Fall hatte es nämlich nicht so funktioniert wie ICH es
wollte. Also muss ich mir eine andere Strategie einfallen lassen um das
Ziel zu erreichen.

Gruß
BEDA