Verzweigungsdurchlauf, obwohl die Bedingung FALSE ist

[Tobias K. (tobias_k622)]

Hallo! Bin neu hier und habe ein großes Problem: Beim normal Betrieb 
geht das Programm immer in die Verzweigungen, die jedoch FALSE sind. 
Komischerweise beim Debuggen nicht. An was kann das liegen?

Bitte um nützliche Hilfe!
lg Tobias

[Leerer (Gast)]

Tobias K. schrieb:
> Hallo! Bin neu hier

Ja das merkt man.

Lerne erst mal deinen Code richtig zu formatieren (viele Tabs,
Tabs durch Spaces ersetzen) und als *.c Datei zu posten.

So wie das jetzt ist müssen alle die dir helfen wollen erst
mal selbst Hand anlegen.

[Thomas Z. (usbman)]

nun mir fällt auf dass genau 0 Komentare im txt.file sind. Da sinkt 
meine Lust zu helfen gleich mal auf 0.

[Tobias K. (tobias_k622)]

Es geht nicht darum was es macht, sondern warum es genau immer in die 
Verzweigungen geht? Beim Debuggen komischerweise nicht

[Leerer (Gast)]

Thomas Z. schrieb:
> Da sinkt meine Lust zu helfen gleich mal auf 0.

Ich werde jetzt meine Sourcen nach diesem Vorbild der Reihe
nach Peter.c, Jonas.c, Paul.c, Johannes.c, Wilhelm.c etc nennen.

Da macht die Software-Entwicklung so richtig kreativ.

[Wolfgang (Gast)]

Tobias K. schrieb:
> Beim Debuggen komischerweise nicht

Wahrscheinlich tickt es beim Debuggen anders.

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias K. schrieb:
> Komischerweise beim Debuggen nicht. An was kann das liegen?

    static _Bool start = 0;
    ...
    
    if (start)
    {

 Wie wird dein Programm überhaupt abgearbeitet?

[Thomas F. (thomas_f923)]

WAS IST DARAN SO SCHWER ZU VERSTEHEN!

[MaWin (Gast)]

Tobias K. schrieb:
> Beim normal Betrieb geht das Programm immer in die Verzweigungen, die
> jedoch FALSE sind.

Eigentlich geht dieses Programm in gar keine "Verzeigung".
Alle if-Bedingungen sind false und bleiben false, da niemand start 
setzt.

Tobias K. schrieb:
> Komischerweise beim Debuggen nicht. An was kann das liegen?

Manchmal liegt es daran, dass bei debuggen uninitialisierte Variablen 
anders belegt sind als bei release, aber deine Variablen sind alle 
initialisiert.

Bei timing-bezogenen Programmen ist beim debuggen eventuell mehr Zeit 
verstrichen, die in release nicht erreicht wird. Aber da dein Programm 
sowieso nichts tut, ist auch das egal.

Eventuell lädst du einfach das falsche (nicht neu gebuildete) Programm 
hoch.

Leerer schrieb:
Stuss
Thomas Z. schrieb:
Stuss, erwartet Kommentare, kann das Wort aber nichtmal schreiben, und 
welche Fatextension ist file ?

Alles mal wieder Volltrottel in diesem Forum.

[Tobias K. (tobias_k622)]

Nein ich mache immer einen neuen BUILD vor dem Upload. Wie kann ich 
diesen Fehler jetzt asubessern?

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias K. schrieb:
> Nein ich mache immer einen neuen BUILD vor dem Upload. Wie kann ich
> diesen Fehler jetzt asubessern?

Beitrag "Re: Verzweigungsdurchlauf, obwohl die Bedingung FALSE ist"

if (start) entfernen, so schwer zu verstehen?

[Thomas F. (thomas_f923)]

Marc V. schrieb:
> Tobias K. schrieb:
>> Nein ich mache immer einen neuen BUILD vor dem Upload. Wie kann ich
>> diesen Fehler jetzt asubessern?
>
>  if (start) entfernen, so schwer zu verstehen?

Vielleicht ist sein Sinn dass er diesen Code noch weiterentwickeln 
möchte, und später durch eine Tastereingabe die Variable Start setzt.
Der aktuelle Stand ist evtl. nur fürs testen.

Hirn einschalten bevor man postet!

[MaWin (Gast)]

Tobias K. schrieb:
> Nein ich mache immer einen neuen BUILD vor dem Upload. Wie kann
> ich diesen Fehler jetzt asubessern?

Was nützt das builden, wenn man eventuell eine veraltete Datei aus dem 
falschen Directory hochladt.

Es gibt so viele Möglichkeiten, die schief gehen können, man muss von 
vorne mit dem Suchen anfangen (führt er ein blink Beispielprogramm in 
realeade und in debug korrekt aus...)

Neulich hatte ich z.B. einfach den USB-Stecker im falschen Board drin 
stecken.

An fehlerhaftem Compiler dass er in if-Zweige eintaucht deren Bedingung 
false ist liegt es jedenfalls nie.

[Tobias K. (tobias_k622)]

JA! Genau das was ich gesucht habe! Hast du eine Lösung für mich parat?

[Marc V. (Firma: Vescomp) (logarithmus)]

Thomas F. schrieb:
> Hirn einschalten bevor man postet!

 Yep.
 Probiere es mal.

[Tobias K. (tobias_k622)]

Leider funktioniert es immer noch nicht :(

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias K. schrieb:
> Leider funktioniert es immer noch nicht :(

 Arithmetische Operationen die verglichen werden erstmal in Klammern
 schreiben, also anstatt:

    else if(t_ms - mt_ms< 1200) ...;

 so schreiben:

    else if((t_ms - mt_ms) < 1200) ...;

 oder:

    CurTime = t_ms - mt_ms;
    if(CurTime < Phase_1) ...;

vorher Phase_0 bis Phase_n_definieren und man braucht nachher nicht an
x Stellen im Programm Werte zu ändern.
Danach nochmal posten...

[Nick M. (Gast)]

Tobias K. schrieb:
> diesen Fehler jetzt asubessern?

Du hast die Buchstaben 1 und 2 im letzten Wort vertausch!

Ich hab auch im Quältext nach FALSE gesucht, aber nicht gefunden. Welche 
Bedienung meinst du? Die Rosi?

[leo (Gast)]

Marc V. schrieb:
> so schreiben:    else if((t_ms - mt_ms) < 1200) ...;

Schwachsinn ...
https://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit%C3%A4t

leo

[Tobias K. (tobias_k622)]

Ich meine die Bedingung if (start).... wobei start 0 ist (False).

[Stefan F. (Gast)]

Tobias K. schrieb:
> Es geht nicht darum was es macht, sondern warum es genau immer in die
> Verzweigungen geht?

In welche Verzweigungen? Und welche Werte haben die Variablen dann? 
Nutze den Debugger.

[Tobias K. (tobias_k622)]

Beim Debuggen scheint alles normal und richtig zu laufen.

[Stefan F. (Gast)]

Thomas F. schrieb:
> WAS IST DARAN SO SCHWER ZU VERSTEHEN!

Du bist schwer zu verstehen, weil du so laut schreist.

Erkläre, was das Programm tun soll, und was stattdessen passiert. Woran 
hast du das erkannt.

Dein Beispiel sollte compilierbar sein. An solchen Code-Fragmenten kann 
man die Seiteneffekte und Rahmenbedingungen nicht ablesen.

[Stefan F. (Gast)]

Tobias K. schrieb:
> Beim Debuggen scheint alles normal und richtig zu laufen.

Ja, es "scheint". Ist es denn wirklich so? Haben alle Variablen die 
erwarteten Werte?

Ohne Debugger kannst du sie auch untersuchen, indem du Logmeldungen 
(seriell) ausgibst.

[Tobias K. (tobias_k622)]

Es geht grundsätzlich um eine Ampelsteuerung. Diese Version ist jedoch 
nicht vollständig, da es mir nur um dieses eine Problem geht: Die erste 
Verzweigung, die lautet if (start) {...., wird trotz start = 0 
ausgeführt, was mich daran hindert, weiter zu machen und den vorhandenen 
Code zu testen. Meine frage, die ich gestellt habe lautet, an was das 
liegt und wie ich es beheben kann.

mfg Tobias

[Stefan F. (Gast)]

Thomas F. schrieb:
> Hirn einschalten bevor man postet!

Marc V. schrieb:
>  Probiere es mal.

Tobias K. schrieb:
> Leider funktioniert es immer noch nicht :(

Das war jetzt aber ein Eigentor.

[Nick M. (Gast)]

Gibt mal dein ganzes Programm raus, der Fehler ist wo anders.

Salamitaktik! [tm]

[Marc V. (Firma: Vescomp) (logarithmus)]

leo schrieb:
> Marc V. schrieb:
>> so schreiben:    else if((t_ms - mt_ms) < 1200) ...;
>
> Schwachsinn ...
> 
https://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit%C3%A4t
>
> leo

Noch ein Korinthenkacker...
Compiler kennt natürlich die Priorität, aber es ist einfach üblich,
so etwas durch Klammern zu trennen.
Niemand wird dem TO helfen, wenn man sich erst einmal durch 50 solche
Konstrukte durchkämpfen muss - warum denn auch?

Nichts konstruktives beizutragen, aber kluge Bemerkungen ausgoogeln...

[Tobias K. (tobias_k622)]

Oder was meinst du mit gesamter Code?

[You don't need to discuss much (Gast)]

Mein Gott! Ich kann kein C, aber normalerweise müßte das Programm ohne 
jede Reaktion durchrauschen, da der TO ja (mit Absicht) zu Anfang 
sämtliche Bedingungen unwahr gemacht hat, in dem er sie auf Null 
festgeklemmt hat.

Trotzdem werden die Verzweigungen durchlaufen und das ist sein Problem.

Jetzt aber:
Ooh, slip out the back, Jack
Make a new plan, Stan
You don't need to be coy, Roy
Just listen to me
Hop on the bus, Gus

[Nick M. (Gast)]

Tobias K. schrieb:
> Oder was meinst du mit gesamter Code?

Da muss mindestens ein main() stehen. Oder ist das wieder so 
Arduino-Zeug?

[Tobias K. (tobias_k622)]

Ich programmiere in Keil uVision 5

[Stefan F. (Gast)]

Tobias K. schrieb:
> Oder was meinst du mit gesamter Code?

Jetzt gebe mir noch eine Anleitung dazu, wie ich das ganze zur 
Ausführung bringen soll. Dann wird dir klar, wie das gemeint war.

[leo (Gast)]

Marc V. schrieb:
> Noch ein Korinthenkacker...

Du postest ueberfluessiges und hilfst nicht.

leo

[Marc V. (Firma: Vescomp) (logarithmus)]

Tobias K. schrieb:
> Es geht grundsätzlich um eine Ampelsteuerung. Diese Version ist jedoch
> nicht vollständig, da es mir nur um dieses eine Problem geht: Die erste
> Verzweigung, die lautet if (start) {...., wird trotz start = 0
> ausgeführt, was mich daran hindert, weiter zu machen und den vorhandenen
> Code zu testen. Meine frage, die ich gestellt habe lautet, an was das
> liegt und wie ich es beheben kann.

 Adresse im RAM wo sich start befindet, vor dem Start kontrollieren.

[Nick M. (Gast)]

Tobias K. schrieb:
> Ich programmiere in Keil uVision 5

Mir egal.
Kein main(), keine Kekse!

[Tobias K. (tobias_k622)]

Hier main.c

[Marc V. (Firma: Vescomp) (logarithmus)]

leo schrieb:
> Du postest ueberfluessiges und hilfst nicht.

Sicher, du und Thomas F. scheinen den selben IQ zu haben und auch
genauso viel Ahnung...

[Stefan F. (Gast)]

> if (HAL_GPIO_ReadPin(taster_GPIO_Port, taster_Pin) == 1 & flanke == 0)

Da gehört ein && hin. Da auch:

> if (HAL_GPIO_ReadPin(taster_GPIO_Port, taster_Pin) == 0 & flanke == 1)

[Tobias K. (tobias_k622)]

Jetzt hab ich es geschafft nur bleibt das Programm jetzt in Zeile 151 
hängen.

[Nick M. (Gast)]

Na, dann schau dir doch mal das Stück code an:

    if (HAL_GPIO_ReadPin(taster_GPIO_Port, taster_Pin) == 0 & flanke == 1)
    {
      if (t_ms - pressStart >= 2)
      {
        if (start == 0) start = 1;
        else start = 0;
      }
      
      flanke = 0;
    }

[Stefan F. (Gast)]

Sorge mal für korrekte Einrückung.

Aber nicht nur deswegen ist in meinen Augen unlesbar. Die Logik ist 
überhaupt nicht erkennbar, weil du wie zu viel in einen großen Block 
geschrieben hast, Variablen-Namen die nichts aussagen und dann auch auch 
auf Kommentare verzichtet hast.

Wenn du mich jetzt kommerziell beauftragen würdest, da etwas zu ändern, 
würde ich erst einmal 8 Stunden für die Analyse anrechnen, 3 Stunden für 
die Dokumentation des ist-Zustandes und dann können wir über die 
eigentliche Änderung verhandeln.

[Nick M. (Gast)]

Tobias K. schrieb:
> Jetzt hab ich es geschafft nur bleibt das Programm jetzt in Zeile 151
> hängen.

Dann geh in das HAL_GPIO_WritePin rein, wenns da hängt.

[Stefan F. (Gast)]

Tobias K. schrieb:
> Jetzt hab ich es geschafft nur bleibt das Programm jetzt in Zeile 151
> hängen.

Das ist:

else if(t_ms - mt_ms < 8800) HAL_GPIO_WritePin(ampelA_Gelb_GPIO_Port, ampelA_Gelb_Pin, GPIO_PIN_SET);

In dieser Zeile kann das Programm unmöglich hängen blieben, es sei denn 
deine Hardware ist defekt. Dann wärst du aber wahrscheinlich gar nicht 
erst so weit gekommen.

Woran erkennst du, dass es genau dort hängt?

Kleiner Tipp: Beantworte meine Rückfragen, sonst klinke ich mich aus.

[Forist (Gast)]

Tobias K. schrieb:
> fertigerCode.txt (3,34 KB, 0 Downloads)

Leerer schrieb:
> Lerne erst mal deinen Code richtig zu formatieren (viele Tabs,
> Tabs durch Spaces ersetzen) und als *.c Datei zu posten.

Thomas F. schrieb:
> WAS IST DARAN SO SCHWER ZU VERSTEHEN!

[Tobias K. (tobias_k622)]

Die angeschlossene Led wird bleibt HIGH und die anderen Leds bleiben 
LOW, was nicht den Programmablauf entspricht.

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
> In dieser Zeile kann das Programm unmöglich hängen blieben,

Kann ja sein, dass er es selbst geschrieben hat. :-)

@TO:
Jetzt ist es an der Zeit tracing mit printf einzuführen ...

[Nick M. (Gast)]

Tobias K. schrieb:
> Die angeschlossene Led wird bleibt HIGH und die anderen Leds bleiben
> LOW, was nicht den Programmablauf entspricht.

Der macht GENAU das was du ihm sagst. Also liegt der Fehler bei dir.
Oder du hast eine geklaute Verion von Keil. Dann passiert sowas schon 
mal.

[Tobias K. (tobias_k622)]

Alles legal

[Nick M. (Gast)]

Tobias K. schrieb:
> Alles legal

Ich glaub, dir ist alles egal.

Mir jetzt auch ...

[Thomas F. (thomas_f923)]

Marc V. schrieb:

> Sicher, du und Thomas F. scheinen den selben IQ zu haben und auch
> genauso viel Ahnung...

So schwer ist es nun auch wieder nicht ein paar if-schleifen zu deuten 😉

[Tobias K. (tobias_k622)]

Dies ist die richtige Datei, wo es in allen if-Verzweigungen hineingeht, 
obwohl deren Bedingung 0 ist.

[Stefan F. (Gast)]

Tobias K. schrieb:
> Die angeschlossene Led wird bleibt HIGH und die anderen Leds bleiben
> LOW, was nicht den Programmablauf entspricht.

Sorry, aber das wird mir zu doof. Du kannst ja nicht einmal sagen, 
welche LED du meinst.

[Marc V. (Firma: Vescomp) (logarithmus)]

Thomas F. schrieb:
> So schwer ist es nun auch wieder nicht ein paar if-schleifen zu deuten
> 😉

Warum gelingt es dir dann nicht?

[Nick M. (Gast)]

Marc V. schrieb:
> Thomas F. schrieb:
>> So schwer ist es nun auch wieder nicht ein paar if-schleifen zu deuten
>> 😉
>
> Warum gelingt es dir dann nicht?

Reingefallen!

[Nick M. (Gast)]

Dann erklär mal, warum du in der Schleife alles immer wieder 0 setzt,

[Stefan F. (Gast)]

Nick M. schrieb:
> Dann erklär mal, warum du in der Schleife alles immer wieder 0 setzt,

Macht er nicht. Fragen zu beantworten ist überflüssiger Schnickschnack.

[Stefan F. (Gast)]

By the way:

So eine Ampel ist eigentlich das Paradebeispiel für einen 
Zustandsautomaten. Damit könnte man lesbaren Code erstellen.

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
> Macht er nicht.

Wir waren halt zu langsam.

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan ⛄ F. schrieb:
> By the way:
>
> So eine Ampel ist eigentlich das Paradebeispiel für einen
> Zustandsautomaten. Damit könnte man lesbaren Code erstellen.

Natürlich.
Nur müsste man dann (im einfachstem Fall) Ampel_N, Ampel_S, Ampel_E
und Ampel_W definieren mit jeweils 3 Phasen für Rot, Gelb und Grün,
wahrscheinlich überschneidend.
Fussgänger sowie Rechts- und Linksabbieger nicht gerechnet.

Scheint für TO zu viel Arbeit im voraus, also am besten gleich loslegen
und wenn etwas nicht klappt, kann man immer noch im Forum nachfragen...

P.S. So etwas kann man ganz schnell und vor allem übersichtlich in
Excel nachbilden, dauert kaum 20 Minuten...

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
> So eine Ampel ist eigentlich das Paradebeispiel für einen
> Zustandsautomaten. Damit könnte man lesbaren Code erstellen.

Wird aber so nicht gemacht. Bei einer etwas komplizierteren Ampel wird 
das schnell wirr.
Ampelanlagen werden in "Bildern" bescchrieben. Dabei wird die Kreuzung 
von oben betrachtet, mit allen Ampeln eingezeichnet.
Ein1 Ampel wird als grün angenommen, daraus folgt welche Ampeln rot sein 
müssen und welche auch noch Grün sein dürfen. So geht man von Ampel zu 
Ampel weiter die noch kein Grün hatte und ist dann fertig.

Das ist als Statemachine immer noch blöd.
Daher würde ich eine Beschreibungssprache für die Zustäne jedes Bildes 
machen und die dann sequentiell abarbeiten.

Das ganze kann man "invertieren" und damit eine permanente 
Sicherheitsüberprüfung laufen lassen.

[Thomas F. (thomas_f923)]

Marc V. schrieb:
> Scheint für TO zu viel Arbeit im voraus, also am besten gleich loslegen
> und wenn etwas nicht klappt, kann man immer noch im Forum nachfragen...

Das hat jetzt überhaupt nichts mehr mit der Frage von Tobias K. zu tun.

Sein Problem:
Es wird in if-Verzweigungen gesprungen obwohl die Bedingung 
offensichtlich FLASE ist.
Seine Frage:
Woran liegts und wie kann man es lösen?

Deine Auffassung:
Ampel -> Hausübung -> Fauler Schüler -> will das wir seine Hausübung 
machen


Marc V. schrieb:
> Natürlich.
> Nur müsste man dann (im einfachstem Fall) Ampel_N, Ampel_S, Ampel_E
> und Ampel_W definieren mit jeweils 3 Phasen für Rot, Gelb und Grün,
> wahrscheinlich überschneidend.
> Fussgänger sowie Rechts- und Linksabbieger nicht gerechnet.

Dies hat absolut gar nichts mehr mit der Frage von Tobias zu tun, das 
hat er auch nie gefragt und verwirrt ihn wsl. nur noch mehr.
Also vielen Dank für deine Nutzlose Hilfe, ab jetzt ist Tobias wohl 
besser ohne dich dran!

[Thomas F. (thomas_f923)]

Marc V. schrieb im Beitrag #6496380:
> if (start) entfernen, so schwer zu verstehen?

Das ist ja nicht die Lösung des Problems, da er später start durch einen 
Taster setzten möchte. Dies aber nicht möglich ist wenn der uC immer in 
die Verzweigung springt!!!

Auf das Niveau vom Rest der Nachricht möchte ich mich gar nicht erst 
herablassen....

[Manfred (Gast)]

Beitrag "Ampelsteuerung"

[Stefan F. (Gast)]

Tobias, du hast ja nun schon die zweite Variante der Ampelsteuerung, wo 
du nicht nachvollziehen kannst, warum sie tut, was sie tut.

in ernst gemeinter Tipp dazu:

Fange mit einfachen Programmen an, und lerne damit den Debugger sowie 
Logmeldungen (printf) zu benutzen. Danach kannst du deine Ampeln 
untersuchen.

[Peter D. (peda)]

Tobias K. schrieb:
> Dies ist die richtige Datei, wo es in allen if-Verzweigungen hineingeht,
> obwohl deren Bedingung 0 ist.

Netter Versuch, die Fehlersuche anderen zu überlasssen. Aber es wird 
nicht klappen.

Der Trick bei der Fehlersuche ist, man betrachtet Programme nicht als 
großen monolithisch Block, sondern löscht erstmal alles weg, was mit dem 
Fehler (scheinbar) nichts zu tun hat und läßt nur das übrig, was den 
Fehler sichtbar macht.

Also kürze das Programm erstmal sinnvoll ein und dann sehen wir weiter. 
Es kann durchaus sein, daß Du dabei den Fehler schon selber findest.

[Nick M. (Gast)]

Peter D. schrieb:
> Also kürze das Programm erstmal sinnvoll ein und dann sehen wir weiter.

Er braucht nichts kürzen, ich hab ihm schon gesagt, wo der Fehler ist.
Jetzt muss er es nur noch lesen, daran scheitert es.

[Achim S. (Gast)]

Nick M. schrieb:
> Er braucht nichts kürzen, ich hab ihm schon gesagt, wo der Fehler ist.

Du meinst diesen Hinweis?

Nick M. schrieb:
> Dann erklär mal, warum du in der Schleife alles immer wieder 0 setzt,

Und du beziehst dich damit wahrscheinlich auf diese Codezeilen innerhalb 
der Schleife?

    static uint32_t mt_ms = 0;
    static _Bool start = 0;
    static _Bool sm1 = 0;
    static _Bool sm2 = 0;
    static _Bool sm3 = 0;
    static _Bool sm4 = 0;

Nun: da wird nichts "immer wieder auf 0 gesetzt". Die Variablen sind zu 
Beginn auf 0 initialisiert, während des weiteren Schleifendurchlaufs hat 
diese "Zuweisung von 0" bei der static Deklaration keinen Einfluss mehr.

https://de.wikibooks.org/wiki/C-Programmierung:_static_%26_Co.

Falls dein Hinweis sich auf ein "anderes Null-setzen" bezog, wäre eine 
Klärung hilfreich.

Von daher würde ich dem TO ebenfalls zu Peters Hinweis raten:

Peter D. schrieb:
> Also kürze das Programm erstmal sinnvoll ein und dann sehen wir weiter.
> Es kann durchaus sein, daß Du dabei den Fehler schon selber findest.

Und vor allem sollte der TO sich angewöhnen, besser zwischen seiner 
tatsächlichen Beobachtung und seiner (oft falschen) Interpretation zu 
unterscheiden. Er sieht z.B., dass eine LED unerwartet eingeschaltet 
wird. Er interpretiert hinein, dass Code innerhalb eines if-blocks 
ausgeführt wird, obwohl die Bedingung des if-blocks nicht erfüllt ist.

Diese Interpretation ist sicher falsch, denn solche Fehler macht der 
Compiler nicht.

Mögliche Erklärungen für die unerwartete Beobachtung sind:
- die LED wird an einer ganz anderen Codestelle angeschaltet, als vom TO 
vermutet
- die Bedingung der if-Abfrage ist während eines "späteren" 
Schleifendurchlaufs eben doch mal erfüllt, so dass der Code im if-block 
ausgeführt werden muss. Der TO hängt aber beim Durchdenken des Programms 
(bzw. durch durchsteppen des Programms im Debugger) noch in einem 
"früheren" Schleifendurchlauf fest, bei dem die Bedingung noch nicht 
erfüllt ist.

Genau für solche Denkfehler ist das Vereinfachen des Programms der 
sinnvolle Ansatz. Dasselbe gilt für "Debugausgaben" auf der seriellen 
Schnittstelle, die auch schon vorgeschlagen wurden. Anhand derer lässt 
sich erkennen, wie häufig die Schleife schon durchlaufen wurde, welchen 
Wert die Variablen zwischenzeitlich angenommen haben, ob die Bedingung 
der if-Anweisung zwischenzeitlich nicht doch mal erfüllt ist... Hier 
muss man allerdings aufpassen, dass das Versenden der seriellen 
Nachrichten das Timing des Programms nicht so stark verändert, dass es 
zu einem anderen Gesamtablauf führt. Zwischenzeitlich hatte der TO mal 
eine Codevariante gezeigt, wo eine Entprellung im 2ms Raster arbeitet - 
das könnte auf Verzögerungen durch den seriellen Monitor empfindlich 
reagieren.

[Nick M. (Gast)]

Achim S. schrieb:
> Nun: da wird nichts "immer wieder auf 0 gesetzt". Die Variablen sind zu
> Beginn auf 0 initialisiert, während des weiteren Schleifendurchlaufs hat
> diese "Zuweisung von 0" bei der static Deklaration keinen Einfluss mehr.

Da hab ich natürlich dran gedacht. Ich hab aber so meine Zweifel, ob das 
innerhalb dem Block funktioniert. Zumindest ist die Konstruktion -so wie 
in dem Beispiel- extrem ungewöhnlich. Ich habs noch nie gesehen und hab 
es noch nie so selbst verwendet.
Innerhalb des obersten Blocks einer Funktion würde ich dir sofort 
zustimmen. Aber so ... ?

[Achim S. (Gast)]

Nick M. schrieb:
> Ich hab aber so meine Zweifel, ob das
> innerhalb dem Block funktioniert.

Hm: ich sehe gerade, dass meine Verlinkung auf Wikibooks nicht 
funktioniert. Der . am Ende gehört zum Link, wird aber hier als 
Satzzeichen interpretiert, so dass man nicht beim eigentlich gewünschten 
Artiel landet. Bitte einfach den . in der Adressezeile des Browsers 
anhängen, die Beschreibung dort ist imho recht eindeutig.

[Peter D. (peda)]

Nick M. schrieb:
> Ich habs noch nie gesehen und hab
> es noch nie so selbst verwendet.

Das macht nichts. Der Compiler kennt die Regeln und hält sie ein.

[Nick M. (Gast)]

Achim S. schrieb:
> Bitte einfach den . in der Adressezeile des Browsers
> anhängen, die Beschreibung dort ist imho recht eindeutig.

Das mit dem Link hab ich selbstständig geschafft. :-)
Die Beschreibung ist mir durchaus geläufig. :-)
Nur, das Konstrukt vom TO kenn ich nicht. Ich finde es so seltsam, dass 
der Kompiler-Hersteller es möglicherweise übersehen hat.

Das static innerhalb einer Funktion beschränkt die Sichtbarkeit der 
Variablen auf die Funktion. Ansonsten ist es wie eine static-Variable 
mit File scope und kann genauso initialisiert werden. Innerhalb der 
Schleife ist der scope aber nur in der Schleife. Und ob das so 
tatsächlich umgesetzt wurde ... wer weiß.

Klar, ich deklariere Variablen auch innerhalb eines Blocks. Aber 
statische? Kommt mir verquer vor.

[Nick M. (Gast)]

Vergessen:

Noch dazugibt es keinen Grund die als static zu deklarieren. Einfach aus 
der Schleife rausziehen und fertig. Da muss dann niemand die Stirn 
runzeln warum das so geschrieben wurde.
Initialisierung von Variablen für einen Block geschieht normalerweise 
vor dem Block.

[Achim S. (Gast)]

Nick M. schrieb:
> Ich finde es so seltsam, dass
> der Kompiler-Hersteller es möglicherweise übersehen hat.

Denkbar ist vieles, aber an diese Variante glaube ich nicht. Erstens 
halte ich es diesbezüglich mit Peter:

Peter D. schrieb:
> Der Compiler kennt die Regeln und hält sie ein.

(Alle Regeln, die sogar ich kenne, kennt der Programmierer eines 
etablierten C-Compilers mit Sicherheit).

Und wenn es wider aller Erwartung doch anders wäre, dann hätte es 
einfach dazu geführt, dass im Code des TO gar nichts passiert (alle LEDs 
auf dem Initialisierungswert bleiben).

Nick M. schrieb:
> Noch dazugibt es keinen Grund die als static zu deklarieren. Einfach aus
> der Schleife rausziehen und fertig.

viele Wege führen nach Rom.

[Nick M. (Gast)]

Achim S. schrieb:
> (Alle Regeln, die sogar ich kenne, kennt der Programmierer eines
> etablierten C-Compilers mit Sicherheit).

Hihi, OK.
Ich hab jetzt auch nochmal auf Papier nachgeschlagen, da steht es 
deutlicher. Es gilt auch innerhalb eines Blocks innerhalb einer 
Funktion.

> viele Wege führen nach Rom.
Ich fahr lieber über die Brennerautobahn, statt mit 37 Elephanten 
Hannibals Weg nachzuvollziehen. :-)

[Dirk K. (merciless)]

Falls der TO noch mitliest:

Diese Zeilen

  static uint32_t mt_ms = 0;
  static uint32_t pressStart = 0;
  static _Bool durchgang = 0;
  static _Bool flanke = 0;
  static _Bool start = 0;
  static _Bool sm1 = 0;
  static _Bool sm2 = 0;
  static _Bool sm3 = 0;
  static _Bool sm4 = 0;

werden nur EINMAL ausgeführt, beim ersten Durchlauf der 
while-Schleife.

merciless

[Peter D. (peda)]

Tobias K. schrieb:
> Dies ist die richtige Datei, wo es in allen if-Verzweigungen hineingeht,
> obwohl deren Bedingung 0 ist.

Der Code sieht erstmal so aus, als sollte er wirklich nichts tun. Aber 
solche If-Ketten sind der Horror, da kann man schnell den Überblick 
verlieren.
Hat aber lange gedauert, ehe Du endlich das Main zeigst.

Was dann noch fehlt, um welches Target geht es überhaupt, welche 
Toolchain (IDE, Compiler, Debugger).
Ist denn alles richtig eingestellt?
Meintest Du Debugger oder Simulator?

Probier erstmal ein einfacheres Programm, z.B. Blink-LED.

[Achim M. (minifloat)]

Nick M. schrieb:
> Das ist als Statemachine immer noch blöd.
> Daher würde ich eine Beschreibungssprache für die Zustäne jedes Bildes
> machen und die dann sequentiell abarbeiten.

Zustände sequentiell abarbeiten ist übrigens auch eine Statemachine.

[Nick M. (Gast)]

Achim M. schrieb:
> Zustände sequentiell abarbeiten ist übrigens auch eine Statemachine.

Ja, aber die State Machine dazu wurde nicht per Hand erstellt.
Da hilft es nicht wirklich weiter wenn du nur auf den zweiten Teil des 
Satzes eingest.

Dennoch herzlichen Dank für deinen Hinweis.

[Rolf M. (rmagnus)]

Achim S. schrieb:
> Zwischenzeitlich hatte der TO mal
> eine Codevariante gezeigt, wo eine Entprellung im 2ms Raster arbeitet -
> das könnte auf Verzögerungen durch den seriellen Monitor empfindlich
> reagieren.

Die war mir auch aufgefallen, wobei mir 2 ms etwas arg kurz für eine 
Entprellung erscheinen. Vielleicht klappt es deshalb auch beim Debuggen, 
weil das langsamer ist oder gar nur in einem Emulator läuft.

Thomas F. schrieb:
> Sein Problem:
> Es wird in if-Verzweigungen gesprungen obwohl die Bedingung
> offensichtlich FLASE ist.

… obwohl er der Meinung ist, dass sie false sein müsste. Wenn da 
nämlich reingesprungen wird, obwohl sie offensichtlich false ist, ist 
der Compiler oder der µC kaputt.

> Also vielen Dank für deine Nutzlose Hilfe, ab jetzt ist Tobias wohl
> besser ohne dich dran!

Ohne dich auch, denn du hast bisher genau gar nichts beigetragen, außer 
dich über die Antworten anderer zu beschweren.

Nick M. schrieb:
> Achim S. schrieb:
>> Nun: da wird nichts "immer wieder auf 0 gesetzt". Die Variablen sind zu
>> Beginn auf 0 initialisiert, während des weiteren Schleifendurchlaufs hat
>> diese "Zuweisung von 0" bei der static Deklaration keinen Einfluss mehr.
>
> Da hab ich natürlich dran gedacht. Ich hab aber so meine Zweifel, ob das
> innerhalb dem Block funktioniert.

Lokale Variable stehen immer in einem Block. Ob das der einer Funktion 
oder eines if ist, spielt keine Rolle.

> Zumindest ist die Konstruktion -so wie in dem Beispiel- extrem ungewöhnlich.

Finde ich nicht. Ich hab sie schon oft gesehen.

> Ich habs noch nie gesehen und hab es noch nie so selbst verwendet.
> Innerhalb des obersten Blocks einer Funktion würde ich dir sofort
> zustimmen. Aber so ... ?

Warum sollte man das tun, wenn sie dort gar nicht benötigt wird?

Nick M. schrieb:
> Vergessen:
>
> Noch dazugibt es keinen Grund die als static zu deklarieren. Einfach aus
> der Schleife rausziehen und fertig. Da muss dann niemand die Stirn
> runzeln warum das so geschrieben wurde.
> Initialisierung von Variablen für einen Block geschieht normalerweise
> vor dem Block.

Eine gängige Regel lautet, den Scope einer Variable so klein wie möglich 
zu halten, also möglichst nicht irgendwo weit vorher definieren, sondern 
erst da, wo man sie auch braucht.
Andererseits sollte man sich generell die Nutzung von static innerhalb 
von Funktionen gut überlegen, da sie dann nicht mehr reentrant sind. In 
diesem Fall spielt das keine Rolle, weil es eh um main() geht.

[Nick M. (Gast)]

Rolf M. schrieb:
>> Also vielen Dank für deine Nutzlose Hilfe, ab jetzt ist Tobias wohl
>> besser ohne dich dran!
>
> Ohne dich auch, denn du hast bisher genau gar nichts beigetragen, außer
> dich über die Antworten anderer zu beschweren.

Na, immerhin hab ich den TO dazu gebracht die komplette Version 
rauszurücken weil einfach Teile fehlten.

Dein Beitrag bisher bestand genau aus NULL. Also, hau weiterhin 
unberechtigt aufs Blech, du hast dein Publikum auf deiner Seite.

Rolf M. schrieb:
> Warum sollte man das tun, wenn sie dort gar nicht benötigt wird?

Man benötigt überhaupt keine static dafür, das ist der Punkt. Und eine 
static in einem tieferen Block ist einfach schlechter Stil. Erst recht 
wenn es sinnlos ist.

> Andererseits sollte man sich generell die Nutzung von static innerhalb
> von Funktionen gut überlegen,

Komisch, bei mir bemängelst du die von dir postulierten Regeln.
Also, bis jetzt lediglich rumgestänkert.
Für den ersten Beitrag nicht schlecht.
Dann warte ich auf weitere "Beiträge" von dir.

[Rolf M. (rmagnus)]

Nick M. schrieb:
> Rolf M. schrieb:
>>> Also vielen Dank für deine Nutzlose Hilfe, ab jetzt ist Tobias wohl
>>> besser ohne dich dran!
>>
>> Ohne dich auch, denn du hast bisher genau gar nichts beigetragen, außer
>> dich über die Antworten anderer zu beschweren.
>
> Na, immerhin hab ich den TO dazu gebracht die komplette Version
> rauszurücken weil einfach Teile fehlten.

Schreibst du hier auch unter dem Namen Thomas F. mit, oder warum fühlst 
du dich angesprochen?

> Dein Beitrag bisher bestand genau aus NULL. Also, hau weiterhin
> unberechtigt aufs Blech, du hast dein Publikum auf deiner Seite.

Wenn du mein Posting nicht verstehst, halt dich doch einfach zurück.

[c-hater (Gast)]

Achim S. schrieb:

> Und vor allem sollte der TO sich angewöhnen, besser zwischen seiner
> tatsächlichen Beobachtung und seiner (oft falschen) Interpretation zu
> unterscheiden.

Das auf jeden Fall.

> Er sieht z.B., dass eine LED unerwartet eingeschaltet
> wird. Er interpretiert hinein, dass Code innerhalb eines if-blocks
> ausgeführt wird, obwohl die Bedingung des if-blocks nicht erfüllt ist.
>
> Diese Interpretation ist sicher falsch, denn solche Fehler macht der
> Compiler nicht.

Das stimmt so leider nicht. Als Ausrede für den Compiler gibt es nämlich 
die Erfindung "UB" (undefined behaviour). D.h.: wenn der Programmierer 
irgendwo irgendwas hinschreibt, was "UB" ist, kann das gesamte 
Programm im Prinzip machen, was es will und es wäre immer noch formal 
korrekt. So jedenfalls die Auffassung der Compilerbauer...

Und nein, wenn man was hinschreibt, was "UB" ist, gibt es meistens keine 
Fehlermeldung, und leider nur allzu oft nichtmal eine Warnung. Es sei 
denn, man schaltet spezielle Warnungen explizit ein. Dann wird man aber 
wiederum mit Warnungen oft vollkommen zugetextet. Je nachdem, was man an 
fremden Quellen benutzt...

Das ist natürlich vollkommen krank, aber absolut typisch für diese 
Bullshit-Sprachen C und C++ und deren wahnwitzige Benutzer.

[Nick M. (Gast)]

Rolf M. schrieb:
> Wenn du mein Posting nicht verstehst, halt dich doch einfach zurück.

Ob deine Postings verständlich sind, dafür bist allein du 
verantwortlich.