kopr schrieb:> da hier grade die Diskussion war:>> A. S. schrieb:>>> if ((P2IN & 0x02) == 1)>> oder>> A. S. schrieb:>> if ((P2IN & 0x02))>> wo ist der Unterschied?
P2IN & 0x02 ist entweder 0 oder 2. Die erste Abfrage ist deshalb nie
wahr.
Im zweiten Fall ist die Abfrage wahr, wenn der Ausdruck ungleich Null
ist.
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.
Matthias S. schrieb:> Nö. das doppelte & steht nun für eine logische Verknüpfung. 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.
ich meinte 0x02
und die hexa geben doch nur an, welcher Pin an aktiv ist. Also ein Pin
7.4 wäre entsprechend 0x10 und nicht 0x01
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.
kopr schrieb:> P1IFG & 0x10
so prüfe ich ja, ob der Interrupt von 0x01 kommt. dabei dachte ich
früher, es müsste && sein, da ja beide Seiten "wahr" sein müssen.
Verstehst du was ich meine?
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
A=7 b=10
If (a =b)
Ist immer erfüllt
P1ifg =0x00
Tastee = 0x02
If (P1Ifg= 0x02) warum ist das nicht immer erfüllt
Ich glaube das war die Frage von kopr
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:> 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.
kopr schrieb:> okay, mein fehler. wenn> if ((P2IN && 0x01) == 1)> dann könnte die Aussage doch wahr werden? deswegen die verwechslung
Du blickst es nicht
Lies dir nach mal die Kapitel Bitoperationen und logische Operationen in
den C-Grundlagen durch. Beliebige willkürliche Mischungen funktionieren
nicht.
Wenn du ein Bitmuster auf irgendeinen bestimmten Wert prüfen willst,
solltest du auch mit einem Bitmuster vergleichen.
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 - halt ein Hack aus den 70er-Jahren des vorigen
Jahrhunderts, der sich bis heute erhalten hat.
Und dann solltest du dir gut überlegen, an solchen Stellen wild
dahergekommene Zahlen zu verwenden. Wehe du hast einen längeren
Quelltext und willst ein Signal auf einen anderen Pin legen. Viel Spaß
beim Suchen.
kopr schrieb:> wo ist der Unterschied?
Das ist ein sch..ß Titel
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.
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.
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, weil ein Wert von z.B. 2 genauso als
true gelten, aber bei dem "== 1" Vergleich ein false liefern würde.
Axel S. schrieb:> Also nichtif (x == 42) ... sondern besserif (42 == x) ... Wenn man dann> nämlich statt "==" versehentlich "=" schreibt, wird aus> der zweiten Varianteif (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 es dir genauso gut passieren kann einfach = statt == zu
verwenden wieso sollte es dir dann nicht auch passieren diese Verdrehung
zu vergessen...
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:> Korrekt. Aber warum beginnst du den Satz mit "Eben"?
Weil genau das Problem des TO war, dass ein Vergleich "== 1" nicht einem
true des davor stehenden Ausdrucks entspricht.
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.
Axel S. schrieb:> 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.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? 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).
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).
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.
Thread beobachten
Seitenaufteilung abschalten