Verzweigungsdurchlauf, obwohl die Bedingung FALSE ist

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. 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.

Tobias K. schrieb:
> Beim Debuggen komischerweise nicht

Wahrscheinlich tickt es beim Debuggen anders.

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. 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?

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. 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.

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.

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.

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.

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

Salamitaktik! [tm]

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

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. 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.

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

Du postest ueberfluessiges und hilfst nicht.

leo

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

Mir egal.
Kein main(), keine Kekse!

> 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)

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

1

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

2

    {

3

      if (t_ms - pressStart >= 2)

4

      {

5

        if (start == 0) start = 1;

6

        else start = 0;

7

      }

8

9

      flanke = 0;

10

    }

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.

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.

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

Das ist:

1

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.

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!

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 ...

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. schrieb:
> Alles legal

Ich glaub, dir ist alles egal.

Mir jetzt auch ...

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. 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!

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

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.

By the way:

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

Stefan ⛄ F. schrieb:
> Macht er nicht.

Wir waren halt zu langsam.

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.

Beitrag "Ampelsteuerung"

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. 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.

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.

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 ... ?

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.

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.

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.

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.

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. :-)

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. 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.

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.

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.