Unterschied?

kopr schrieb:
> if ((P2IN & 0x02) == 1)

Diese Bedingung wird nie wahr.
Diese könnte wahr werden:

1

 if ((P2IN & 0x01) == 1)

2

// oder diese

3

 if ((P2IN & 0x02) == 2)

Edit : Doppelpost - HildeK hats erklärt.

kopr schrieb:
> if ((P2IN && 0x01) == 1)

Nö. das doppelte & steht nun für eine logische Verknüpfung und nicht für 
eine Bitmaske. Damit ist der Ausdruck wahr, wenn P2IN wahr ist und 0x01 
wahr ist. Ist also nur ein Bit in P2IN high, ist der ganze Ausdruck 
(P2IN && 0x01) wahr, denn 0x01 ist ja immer wahr.

Nochmal: Das && steht für eine logische UND Verküpfung. Das & bildet 
hingegen eine Bitmaskierung.

kopr schrieb:
>> P1IFG & 0x10
>
> so prüfe ich ja, ob der Interrupt von 0x01 kommt.

Es ist schon spät und es schleichen sich immer mehr Fehler bei dir ein.
Mit 'P1FG & 0x10' kannst du nur Bit 4 abfragen und nicht etwa, ob ein 
Bit 0 gesetzt ist.

Aber ich habe den Entprellkram bei dir verfolgt und verstehe immer noch 
nicht, warum die die kleinen Anpassungen in PeDas Original Code auf den 
MSP430 nicht machst und dann mit der Routine glücklich bist. Stattdessen 
schickst du im Interrupt immer noch serielle Meldungen ab und bremst 
dadurch alles aus. Von delays etc. ganz zu schweigen. Ich glaube nicht, 
das ich mich da reinziehen lassen will.

kopr schrieb:
> Matthias S. schrieb:
>> chmal: Das && steht für eine logische UND Verküpfung. Das & bildet
>> hingegen eine Bitmaskierung.
>
> ja okay. Bin da noch unsicher was so eine Abfrage angeht.

Nein, nein, nein.

Das ist nicht "Unsicherheit", sondern Unwissen. Fehlende Grundlagen in 
der Programmiersprache C. Die Operatoren "&" und "&&" mögen auf den 
ersten Blick ähnlich sein, tun aber ganz verschiedene Dinge!

Das ist Handwerkszeug, das mußt du lernen. Oder du läßt das mit dem 
Programmieren. Lies den Abschnitt über C Operatoren in deinem 
bevorzugten C-Buch (oder 
https://de.wikibooks.org/wiki/C-Programmierung:_Ausdrücke_und_Operatoren). 
Speziell zu den Bit-Operatoren, die hier gebraucht werden, hat auch das 
hiesige Wiki einen Artikel: Bitmanipulation

Ikl schrieb:
> If (P1Ifg= 0x02) warum ist das nicht immer erfüllt
>
> Ich glaube das war die Frage von kopr

weil ein = kein Vergleich in C ist sondern eine Zuweisung!

hier  mit If? oder if oder IF ? wollte er eine boolsche Bedingung prüfen
mit einem = klappt das z.B. in BASIC

Axel S. schrieb:
> Das ist nicht "Unsicherheit", sondern Unwissen. Fehlende Grundlagen in
> der Programmiersprache C.

auch das oder er war müde.

Joachim B. schrieb:
>> If (P1Ifg= 0x02) warum ist das nicht immer erfüllt
>>
>> Ich glaube das war die Frage von kopr
>
> weil ein = kein Vergleich in C ist sondern eine Zuweisung!

Da müsste sogar der Kompiler meckern mit 'Probably unwanted assignment 
in line 42' oder so ähnlich. Als Flüchtigkeitsfehler ist das sicher uns 
allen schon mal passiert, aber gewollt haben es nur die wenigsten. Es 
hilft immer, sich die Warnungen genau anzusehen und sie auch nicht 
abzuschalten.

So wird das nichts schrieb:
>

1

if ((P2IN & 0x02) == 0x02)

 oder

1

if (P2IN & 0x02)

wären
> funktionierende Möglichkeit, wobei letztere auch nur funktioniert, weil
> C nicht vernünftig zwischen Ganzzahlen und Boolschen Werten
> unterscheidet

Vollkommen überzogene Rhetorik. In der Tat hat C erst vor 
verhältnismäßig kurzer Zeit einen eigenen Typ bool bekommen. Aber es 
gab schon immer Regeln, wie Standardtypen in Wahrheitswerte konvertiert 
werden. Und diese Regeln sind eindeutig und vernünftig. Was einem 
numerischen Wert 0 entspricht, ist falsch; alle anderen Werte ergeben 
wahr. Das ist im Prinzip genau das gleiche, was man in Assembler machen 
würde: der ALU den Wert zur Begutachtung vorlegen und dann auf das 
Z-Flag schauen.

> ein Hack aus den 70er-Jahren des vorigen
> Jahrhunderts, der sich bis heute erhalten hat.

Es gibt gar keinen Grund, etwas an diesem Verhalten zu ändern. Schon gar 
nicht, wenn es existierenden (funktionierenden) Code kaputt machen 
würde.

Matthias S. schrieb:
> Joachim B. schrieb:
>>
>> weil ein = kein Vergleich in C ist sondern eine Zuweisung!
>
> Da müsste sogar der Kompiler meckern mit 'Probably unwanted assignment
> in line 42' oder so ähnlich.

Es wird aber nur eine Warnung geben. Schließlich ist der Code ja 
syntaktisch korrekt. Und wie du selber sagst: viele Leute lesen die 
Warnungen nicht bzw. schalten sie gleich ganz ab.

> Als Flüchtigkeitsfehler ist das sicher uns
> allen schon mal passiert, aber gewollt haben es nur die wenigsten.

Ein guter Trick, wie man diesen Flüchtigkeitsfehler für den Compiler 
erkennbar macht, besteht darin, Vergleiche zwischen Variablen und 
Konstanten immer so herum zu schreiben daß die Konstante links steht. 
Also nicht

1

if (x == 42) ...

 sondern besser

1

if (42 == x) ...

 Wenn man dann nämlich statt "==" versehentlich "=" schreibt, wird aus 
der zweiten Variante

1

if (42 = x) ...

 und dann gibt es nicht nur eine Warnung, sondern einen harten Fehler.

Wolfgang schrieb:
> Axel S. schrieb:
>> Aber es gab schon immer Regeln, wie Standardtypen in Wahrheitswerte
>> konvertiert werden. Und diese Regeln sind eindeutig und vernünftig.
>> Was einem numerischen Wert 0 entspricht, ist falsch; alle anderen
>> Werte ergeben wahr.

> Eben - ein direkter Vergleich eines Wertes mit 1 ("== 1") entspricht
> dann nicht unbedingt einem wahr

Korrekt. Aber warum beginnst du den Satz mit "Eben"? Ich habe nirgendwo 
behauptet, der Vergleich mit 1 wäre korrekt (oder sinnvoll).

Was der Compiler implizit macht, wenn er einen Ausdruck (x) in einen 
Wahrheitswert umwandelt ist das hier:

1

 !((x) == 0)

Er vergleicht mit 0 und negiert das Ergebnis.

Msd schrieb:
> Axel S. schrieb:
>> nicht

1

 if (x == 42) ...

>> sondern besser

1

 if (42 == x) ...

>> Wenn man dann nämlich statt "==" versehentlich "=" schreibt, wird aus
>> der zweiten Variante if (42 = x) ... und dann gibt es nicht nur eine
>> Warnung, sondern einen harten Fehler.
>
> In dem Moment wo du darüber nachdenkst, dass du beides umdrehst wird dir
> wohl kaum der Fehler passieren fälschlicherweise eine Zuweisung zu
> platzieren.

Wenn man sich das fest angewöhnt, bei Vergleichen immer die Konstante 
auf die linke Seite zu schreiben, dann muß man ja gerade nicht mehr 
darüber nachdenken. Die Operatoren "=" und "==" braucht man beide, da 
kann man sich keine feste Routine angewöhnen.

Axel S. schrieb:
> Also nicht
> if (x == 42) ... sondern besser
> if (42 == x) ...

Gefällt mir - obwohl ich zu den Typen gehöre, die Warnungen anschalten 
und sie dann sogar lesen :-P Aber die Idee tue ich in meine Sammlung - 
Danke.

Ikl schrieb:
> Joachim B. schrieb:
>> weil ein = kein Vergleich in C ist sondern eine Zuweisung!
>
> Aber das ist doch der Punkt. Durch die zuweisung ist es doch immer
> erfüllt.

Was soll denn dieses "es" sein, das da erfüllt ist?

Msd schrieb:
> In dem Moment wo du darüber nachdenkst, dass du beides umdrehst wird dir
> wohl kaum der Fehler passieren fälschlicherweise eine Zuweisung zu
> platzieren. Wenn es dir genauso gut passieren kann einfach = statt == zu
> verwenden wieso sollte es dir dann nicht auch passieren diese Verdrehung
> zu vergessen...

Man denkt natürlich nicht jedes einzelne Mal darüber nach, sondern 
gewöhnt sich das an. Dann nimmt man es irgendwann gar nicht als 
Verdrehung war und macht das ganz automatisch so.

Msd schrieb:
> Wenn man sich an etwas neues gewöhnt, wieso kann man sich dann nicht
> gleich an das Grundproblem gewöhnen?

Weil ein = anstelle eines == durchaus auch ein Tippfehler sein kann, den 
man nicht bemerkt. ;)

Msd schrieb:
> Der Ursprüngliche Fehler ist sogar zweistufig und sollte daher erstmal
> auf persönlicher Ebene behoben werden: 1. = und == zu verschludern (kann
> passieren) und nicht auf Warnungen zu reagieren/auszuschalten (kann
> nicht passieren).

Was meinst du wieviele Programme mit Warnings compiliert und benutzt 
werden? Das ist leider nicht sehr ungewöhnlich.

Msd schrieb:
> Rolf M. schrieb:
>> Man denkt natürlich nicht jedes einzelne Mal darüber nach, sondern
>> gewöhnt sich das an. Dann nimmt man es irgendwann gar nicht als
>> Verdrehung war und macht das ganz automatisch so.
>
> Wenn man sich an etwas neues gewöhnt, wieso kann man sich dann nicht
> gleich an das Grundproblem gewöhnen?

Ich habe das getan. Mir passiert es eigentlich extrem selten, dass ich 
das zweite = vergesse, aber es ist schon vorgekommen - vielleicht auch 
nur, weil ich beim zweiten Druck auf die Taste etwas zu zaghaft war und 
es nicht angekommen ist. Ich hatte übrigens in der Firma mal eine 
Tastatur, die, wenn man die selbe Taste zweimal schnell hintereinander 
gedrückt hat, gerne mal den zweiten Tastendruck verschluckt hat. Ich 
vermute, die Entprellung war etwas zu "aggressiv" eingestellt.

> Warum sich etwas neues ausdenken, wenn das das Problem noch nicht mal
> behebt. (Ja der Fehler ist zwar behoben wenn man auf den Compiler-Fehler
> reagiert aber das ist ja noch eine zweite Ebene).

Es behebt den Fehler nicht, aber vermeidet ihn.

> Der Ursprüngliche Fehler ist sogar zweistufig und sollte daher erstmal
> auf persönlicher Ebene behoben werden: 1. = und == zu verschludern (kann
> passieren) und nicht auf Warnungen zu reagieren/auszuschalten (kann
> nicht passieren).

Die Regel mit dem Tausch der Operanden stammt noch aus einer Zeit, als 
Compiler bei so was noch nicht gewarnt haben.