Druckbare Version
Hallo und frohes Neues!
Warum führt Folgendes:
..immer zu dieser Warnung:Code:uint8_t count;
for (count=0; count<=255; count++) {}
Muß ich in einer 8Bit MCU eine 16Bit Variable deklarieren, um den 8BitCode:lcd.c:84: warning: comparison is always true due to limited range of data type
Wertebereich nutzen zu können?
Funktioniern tuts ja wie ich möchte, nur wurmt mich diese Warnung doch ein bischen.
thx,
tholan
Hallo,
wie müsste count den aussehen, um nicht <= 255 zu sein?
Gruß
Jens
Das:
< 255
... gibt keine Warnung, aber dann zählts nur bis 254 => 0xfe.
Für mich ist die Frage, wie der Vergleichsoperator sein muß,
wenn ich den vollen Wertebereich ohne Compilerwarnung nutzen möchte.
Die Sache ist ganz einfach: Das Byte KANN nur <= 255 sein.
Dementsprechend wird das ganze immer Wahr sein.
Du willst ja den Übergang von 255 auf 0 erkennen, wenn ich mich nicht irre, hat der AVR ein entsprechendes Flag dafür.
Evtl. könntest du also prüfen, ob der Null-Flag in SREG gesetzt ist.
mfG
Markus
Das ich in einem Byte nur bis 255 zählen kann, ist mir schon klar,
warum aber die Warnung?
Ist das ein Bug im Compiler?
Die Warnung würde Sinn machen, wenn der Compiler erst addieren ließe und der Atmel
dann überprüft, ob die Bedingung noch wahr ist,
wobei er das nicht müßte, da ich ja sowieso will, daß er nur bis 255 zählt?????
Nein.... der Compiler hat recht mit seiner Warnung.
Wie markusj schon sagte, die einzige Möglichkeit dass der Ausdruck in der for-Schleife false wird, ist wenn count größer als 255 wird. Das ist aber nicht möglich da der Datentyp den du verwendest eben nur werte bis 255 speichern kann.
Dann darf ich das also als Warnung an den dummen Programmierer werten,
daß er auf seinen Wertebereich aufpassen soll, weil er so knapp an die Bereichsgrenze ranzählt?
Dann kann man die Warnung also links liegen lassen.
Du hast offensichtlich immer noch nicht realisiert, dass du da eine Endlosschleife programmiert hast.Zitat:
Zitat von tholan
Der Vergleich ist (wie der Compiler dir sagt) immer wahr, also wird die Schleife nie beendet.
Falsch,
sie zählt brav von 0 bis 255 und beendet sich dann,
die Zahlen werden währenddessen in 3 dezimale Digits zerlegt und auf meinem LCDisplay zur Anzeige gebracht, wie es sein soll.
Ich habe nur eine unnötige Warnung.
Hallo,
kannst du den relevanten Code mal komplett posten. Die Schleife kann so wie oben dargestellt nicht beendet werden. Da muss es noch etwas anderes geben.
Gruß
Jens
Die Schleife oben garantiert nicht.Zitat:
Zitat von tholan
Der Wert 255 entspricht dem binären Wert 11111111.
der paßt Augenscheinlich in 8 Bit!!!
Die Bedingung <=255 ist natürlich immer wahr für den angegebenen Zählbereich.
Sonst würds nicht zählen.
@sternst: Hast Du deinen Mikro denn schonmal bis 255 zählen lassen?
Wahrscheinlich nehmt ihr wohl alle immer uint32 für son' armen 8 Bitter?
Das das mit uint8_t funktioniert, sehe ich an meinem Display.
doch die schleife oben läuft!sie zählt nämlich bis count<=(GLEICH)255 is
deshalb is das ganze bei 255 zuende!
Na, das kann ich aber auch nicht glauben. Ein Byte ist immer kleinergleich 255, für mehr fehlt ihm leider ein Bit ;)Zitat:
Zitat von tholan
Wenn du natürlich die Schleife endlos ausführst wirst du nicht bemerken das sie nach dem ersten Aufruf nicht beendet wird.Zitat:
die Zahlen werden währenddessen in 3 dezimale Digits zerlegt und auf meinem LCDisplay zur Anzeige gebracht, wie es sein soll.
was mir gerade noch einfällt: vlt findet ein impliziter typecast statt?
Tjaaa, ist halt nur die unnötige Warnung... :)
??
Oh mein Gott.Zitat:
Zitat von MSN
Die Schleife läuft solange count<=255 ist, nicht bis.
Es ist und bleibt eine Endlosschleife, da gibt es nichts dran zu rütteln.
Oh Mann
ich hab hinter die for-Schleife extra noch ein paar Buchstaben aufs Display geschrieben,
muß ich jetzt ein .avi machen?
Wenn ich den Code poste, dann glaubt Ihr doch nicht, daß es pfundst?
jap hast recht is mir auch aufgefallen bin heut morgen erst spät nach hause gekommen und nen bisschen verpennt sryZitat:
Zitat von sternst
C ist keine Frage von "Glauben", sondern von Regeln und Standards.Zitat:
Wenn ich den Code poste, dann glaubt Ihr doch nicht, daß es pfundst?
Die von dir oben gepostete Schleife ist eindeutig eine Endlosschleife, da ist kein Spielraum für andere Interpretationen.
Wenn sie sich bei dir anders verhält, dann weicht der tatsächliche Code (poste ihn doch endlich mal) vom obigen ab (z.B "manuelles" Verlassen der Schleife durch ein break), oder es ist ein Compiler-Bug.
Ist leider doch. Wir wissen nicht wie sein uint8_t definiert ist...Zitat:
...da ist kein Spielraum für andere Interpretationen.
(..aber das ist eher theoretisch..)
Doch, wissen wir. Durch die Warnung, denn die orientiert sich natürlich am tatsächlichen Datentyp, und nicht am Typ-Bezeichner.Zitat:
Zitat von radbruch
Dass bei ihm ein uint8_t versehentlich größer ist als 8 Bit, scheidet als Möglichkeit daher aus.
](*,)
Nun ja,
Knieschuß is auchn Treffer?
Ihr habt Recht!
Das lief alles in einer "while(1){}" Schleife.
D.h. die ist wahrscheinlich garnicht zum Zuge gekommen,
da die for Schleife nie beendet wurde.
Ich hatte halt zum Test die Schleife auf <=254 gesetzt und dann noch ein paar Buchstaben
in der while Schleife zur Ausgabe gebracht,
dabei allerdings vergessen, die Schleife wieder zum Testen auf <=255 zu setzen.
Ist mir wirklich unangenehm.
'Tschuldigung.
Gibts denn einen Vergleichsoperator, mit dem ich den vollen Wertebereich
zum Zählen nutzen kann?
==255 ist doch auch Quatsch?
p.s.
Hab mir den Thread nochmal durchgelesen, bin noch ein bischen kleiner geworden
und der Groschen ist laangsam gefallen:
C ist schon vertrakter als Basic.
Es wird also solange addiert, wie <= 255 wahr ist, also auch bei 255.
und das ganze wird dann dank Überlauf zu 0 und wieder wahr.
Was mich nach dieser Logik dann wundert ist, daß <255 halt nur bis 254 geht.
Wenn 254 wahr ist, dann müßte doch auch noch eins addiert werden.
Tuts aber nicht, wenn ich nicht schon wieder geschielt habe.
Wie ich schon in meinem ersten Post geschrieben habe, hat jeder (?) AVR ein sogenanntes Register SREG.
Darin gibt es einen Flag, der dir anzeigt, ob das Ergebnis der letzten Operation Null ist.
Wobei ich noch nie mit diesen Flags direkt gearbeitet habe, demensprechend kann ich dir nicht sagen, ob das ganze funktioniert. Außerdem müsstest du dann den ersten Schleifendurchlauf abfangen.
Am einfachsten ist es vermutlich, 254 durchläufe zu machen und dann den Code nochmal hintendran zu kopieren (auch wenn mir der Gedanke wehtut).
Evtl. hat jemand noch ne bessere Idee.
mfG
Markus
Warum nicht einfach ne ui16_t als Zählvariable? Das eine Byte mehr sollte im Speicher ja noch Platz haben.
Doch, wird es. Da aber 255 die Bedingung nicht mehr erfüllt, wird mit dieser 255 der Inhalt der For-Schleife nicht mehr ausgeführt.Zitat:
Zitat von tholan
Wenn du aber hinter der For-Schleife count testest, wird es dort 255 sein.
Die Lösung deines Problems:
Code:uint8_t count = 0;
do {
// tue etwas mit count von 0 - 255
} while (++count);
Also dieses C hat sich doch bestimmt mal ein Professor auf Pille ausgedacht :) .Zitat:
Doch, wird es. Da aber 255 die Bedingung nicht mehr erfüllt, wird mit dieser 255 der Inhalt der For-Schleife nicht mehr ausgeführt.
Wenn du aber hinter der For-Schleife count testest, wird es dort 255 sein.
Irgendwie hats ja ne Logik. Da muß man aber erstmal drauf kommen.
Ich glaub ich habs kapiert!
Morgen, ähh Heute werd ichs in meinen Mega16 füttern.
Habt vielen Dank,
tholan
Weil 16-Bit Rechenoperationen mehr RAM und Rechenzeit brauchen.Zitat:
Zitat von Jaecko
@tholan: Das ist in den meisten Programmiersprachen so. Und wenn du dir mal in irgend einem C-Buch eine ein Ablaufdiagramm der for-Schleife gesehen hast, stellst du fest, dass eben erst inkrementiert wird und dann geprüft.
Die Lösung von sternst ist tatsächlich die schönste (warum bin ich da eigentlich nicht drauf gekommen???)
mfG
Markus
Nur unwesentlich.Zitat:
Zitat von markusj
Im ASM sinds nur ein paar Anweisungen mehr.
Sternst hat die von Dir gesuchte Lösung bereits gepostet. Und das ist nicht die "schönste" Lösung, sondern die logische Alternative.
Eine Fußschleife und keine Kopfschleife ist hier Deines Problems Lösung.
Na, ich resümier nochmal:
Was nicht in meinen Schädel wollte, ist, daß auf "true" getestet wird.
Ich hab so intuitiv immer mit mir rumgeschleppt, daß in einer Schleife auf
"false" getestet wird, bis "true" oder
"gleich" erreicht wird, um die Abbruchbedingung zu liefern.
Wenn man auf "true" testet, hat man logischerweise dieses Problem,
da mindestens ein Element "false" sein muß um den Abbruch zu gewährleisten.
Warum die "do while" Schleife funktioniert, sie fängt immerhin mit ner "falschen" Null an,
frag ich nicht, weil ichs schon gefunden habe :) .
Beim ersten Durchlauf wird hier wohl vor der ersten Addition nicht auf Wahrheit überprüft
und somit rutscht die erste "0" mit durch, ohne die Schleife abzubrechen.
Ob das nun schön ist, beurteile ich als Anfänger garnicht.
Auf jeden Fall würde ich C nicht unbedingt "intuitiv" nennen.
Ich hab ehrlich gesagt auch noch nicht probiert, was Bascom macht
bei: "FOR N=0 TO 255" mit "DIM N AS BYTE" ..oder so.
Der Thread war für mich wirklich sehr lehrreich.
Ich muß mir mal ein gutes C Buch zulegen.
thx,
tholan
Das klingt ja fast so, als ob du hier irgendein Fehlverhalten witterst. Dabei macht der Compiler nur, was ich ihm im Sourcecode mitgeteilt habe:Code:Beim ersten Durchlauf wird hier wohl vor der ersten Addition nicht auf Wahrheit überprüft und somit rutscht die erste "0" mit durch, ohne die Schleife abzubrechen.
while (++count)
Beachte hierbei, dass das ++ vorne an count steht. Das bedeutet "erhöhe count erst um Eins und teste danach auf True".
Du scheinst auch zu denken, die Addition sei integraler Bestandteil der Schleife (in der Basic-For-Schleife ist sie das auch), dem ist aber nicht so. Man könnte das ganze auch etwas "ausführlicher" schreiben, dann wird der Ablauf für dich vielleicht etwas klarer:
Code:uint8_t count = 0;
do {
// etwas tun
count = count + 1;
} while (count != 0);
pühh..
also noch genauer hingucken.
Vielen Dank für Deine Geduld mit mir!