comparison is always true

[radbruch]

...da ist kein Spielraum für andere Interpretationen.

Ist leider doch. Wir wissen nicht wie sein uint8_t definiert ist...

(..aber das ist eher theoretisch..)

[sternst]

...da ist kein Spielraum für andere Interpretationen.

Ist leider doch. Wir wissen nicht wie sein uint8_t definiert ist...

Doch, wissen wir. Durch die Warnung, denn die orientiert sich natürlich am tatsächlichen Datentyp, und nicht am Typ-Bezeichner.
Dass bei ihm ein uint8_t versehentlich größer ist als 8 Bit, scheidet als Möglichkeit daher aus.

[tholan]

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.

[markusj]

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

[Jaecko]

Warum nicht einfach ne ui16_t als Zählvariable? Das eine Byte mehr sollte im Speicher ja noch Platz haben.

[sternst]

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.

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.

Die Lösung deines Problems:

uint8_t count = 0;
do {
    // tue etwas mit count von 0 - 255
} while (++count);

[tholan]

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.

Also dieses C hat sich doch bestimmt mal ein Professor auf Pille ausgedacht .
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

[markusj]

Warum nicht einfach ne ui16_t als Zählvariable? Das eine Byte mehr sollte im Speicher ja noch Platz haben.

Weil 16-Bit Rechenoperationen mehr RAM und Rechenzeit brauchen.

@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

[thewulf00]

Warum nicht einfach ne ui16_t als Zählvariable? Das eine Byte mehr sollte im Speicher ja noch Platz haben.

Weil 16-Bit Rechenoperationen mehr RAM und Rechenzeit brauchen.

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

[tholan]

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